The "website" property fo the plugin bag used
to contain a link to external documentation,
but there is none left. So in future it may
point to a plugin website (or the website
of the plugin's author, if there is no
special page about the plugin).
Change language and translations accordingly.
Signed-off-by: Thomas Hochstein <thh@inter.net>
If serendipity_event_unstrip_tags is active, we
don't want to strip HTML tags from comments; we
want to keep and encode them with entities. So
we should do that here, too.
As the frontend_display hook - that is catched by
serendipity_event_unstrip_tags - is called quite
late, we have to skip the strip_tags() call
before truncatin the entry.
(I'm not sure why we first strip _all_ tags and
later on keep _some_ tags (that have already
been removed), but that's maybe because the
frontend_display hook may have re-added some
tags? Be it as it may, we do that for 14
years, so I don't want to change that now.)
Signed-off-by: Thomas Hochstein <thh@inter.net>
Was mostly fixed by 8b51c37b98 (see #261),
but which missed 03cc73d77e and the other
older code before the foreach() loop.
Later on, 7fe8d91bc2 did the check for
'propertyform' the wrong way around.
Signed-off-by: Thomas Hochstein <thh@inter.net>
Since merging #665 `serendipity_plugin_history`
breaks with a SQL error message on every archive
page but the first one; see #693 for reason
and context.
Unset `$serendipity['GET']['page']` before
calling `serendipity_fetchEntries(`)` (and
reset afterwards) to fix that. That's the
correct way, I think, as
`serendipity_fetchEntries()` is not called
in page context here.
Signed-off-by: Thomas Hochstein <thh@inter.net>
This restores the behaviour from before the move to utf8mb4 and should help legacy blogs not having charset issues, that went from latin1 to utf8 to now utf8mb4
See #655.
I don't understand the code either (I don't even see
where this code path belongs to - do we have a
facitlity to show comments "from ... to"?), but
the current regexp is obviously wrong, and the
one suggested by @hannob is obviously
(syntactically) correct, so it should be no
problem to change that.
Fixes#655.
Signed-off-by: Thomas Hochstein <thh@inter.net>
The old query will fail with ONLY_FULL_GROUP_BY set which is default from
MySQL 5.7.5 onwards. This results in the .htaccess file not being updated.
Also adding some fencing to the foreach to prevent php error messages.
We don't need to check against the filename
without extension, because it's only the
extension that may be problematic.
Signed-off-by: Thomas Hochstein <thh@inter.net>
Steps to reproduce:
1) Upload a PHP script to the Media Libray,
naming it "test" (or any other name
without extension).
2) Rename it to "exploit.php." (trailing dot!)
On Linux, the file will be renamed to
"exploit.php..", which is safe and
cannot be exploited.
On Windows though, the file will be
renemad to "exploit.php" and is then
remotely executable by calling it
from "/uploads/exploit.php".
Thanks to Junyu Zhang <rgdz.eye@gmail.com>
for spotting this!
Signed-off-by: Thomas Hochstein <thh@inter.net>
After fixing the other ML file renaming bugs,
it was now possible to rename a file without
extension into a file that *does* have an
extension - so we need to check against
active content.
Signed-off-by: Thomas Hochstein <thh@inter.net>
The renaming code added a dot '.' to the
filename on disk even if the file hat no
extension. Therefore, the file name on disk was
different from the name in the database,
triggering the database purging code on the
next ML display.
(serendipity_displayImageList() will delete
files from the database that don't exist
any longer on disk.)
This code won't add spurious dots for
empty extensions, keeping disk and
database in sync.
Signed-off-by: Thomas Hochstein <thh@inter.net>
