Both options have grave security implications and novice users seem to
ignore advice about them. In the last decades I never came across a wiki
that had legitimate use of these options.
If someone needs the functionality, it can easily be added back using a
plugin. But I prefer to give users one less option to shoot themselves
in the foot.
Removal of the translations for the config strings can follow after this
has been merged.
This introduces an error handler that will log warnings, including a
stack trace in the error log. This should help plugin and core authors with
identifying cases of uninitilized variables in PHP8+ environments.
A feature flag (default off) will let users temporarily disable the
display of warnings in the frontend. This should allow the usage of not
yet upgraded plugins in many cases. In the future the flag can be
removed again.
* logging:
added JavaScript based filter mechanism
added logging configuration
replaced out calls to dbglog with new Logger calls
added convenience methods to log to our default facilities
added logviwer admin plugin
added log dir to git
central logging mechanism
This patch replaces our old gif based smileys by SVG based ones from the
Twemoji project. This allows for scaling the emojis with the text
they're used in.
Log facitlities can now be disabled. By default only debug is disabled.
It might make sense to by default disable deprecated as well?
Debug logging is now independend of the allowdebug method. allowdebug
was often used in two ways: for displaying errors directly to the user
and for logging to the debug log. Now it only controls the former.
This adds a feature flag for the jQuery and main-js requests added in
#2786 and #2958. This adds only a single feature flag since deferring
jQuery without deferring the main javascript request is likely to cause
errors and confusion.
The feature flag defaults to "on" as this should be unproblematic except
for a few plugins. Also, with this flag being on by default, it should
see more usage and is more likely to uncover existing issues.
This feature flag should be removed once this feature is deemed safe.
This fixes#2828, where malicious clients passed in customized HTTP header to keep its IP address off records.
This is inspired by Sympony's Request::setTrustedProxies, but I don't want to implement everything including IP CIDR matching (IPv4 + IPv6), so I decided to reuse the local IP checker in place powered by regexp. Now admins can customize this "local" (trusted) proxy list using $conf['trustedproxy'], and by default it will allow any local IPs.
If in the future there is a need to implement array-based CIDR matching, $conf['trustedproxies'] can be used for the new config name.
Refer to module by suitable file name (mod_*.c).
Test for mod_authz_core.c (instead of mod_authz_host.c) to properly
detect Apache 2.4 and avoid false positive for Apache 2.2.
shorter names are more in line with what we already use, makes less
layout problems in the documentation and is easier to type when telling
people about it.
This adds two new config options:
`search_limit_to_first_ns`:
Limit the search to the current X namespaces. When a search is executed
from a page within a deeper namespace, the first X namespaces will be
added as filter.
Possible use case could be with language namespaces to ensure that the
default search is initially within the current language.
`search_default_fragment_behaviour`:
Option to specify the default fragment search behavior
jQuery (and UI and Migrate) are now loaded separately from the rest of
the JavaScript. This adds at least one HTTP request more but has some
advantages:
* browsers can cache it independently
* the cache is only invalidated when versions update
* we do not apply any transformations (replacements, minimizing, etc) on
this code anymore which makes our dispatcher faster for the other JS
* browsers seem to load (not execut) both (jquery and other) parallel,
which might increase download speed a bit
This split allowed for the introduction of a new config: jquerycdn. When
enabled the 3 jquery files are loaded from jQueries CDN. This adds
another two HTTP requests but:
* since it's another host those files do not apply to the 4 request per
host limit and can be loaded (not executed) in paralell which might
increase download speeds a bit
* the CDN is distributed worldwide which means files are requested from
the closest location, increasing the download speeds
* since these files/CDN are very popular, chances are high that people
already have them cached in their browsers, reducing the download time
to 0 and effectiely halving the javascript needed to download
The option currently defaults to 'off', but I would argue 'on' would be
the better default.
Since we no longer support old IE 8 and below we can enable data uris
by default now. The picked size here is open for discussion.
A typical HTTP header for a static image ressource is about 200 to 250
bytes at dokuwiki.org. I picked twice of that as the cutoff for inlining
images.
Andreas Gohr