If $limit is empty(), no limit is set, so we can
set the LIMIT statement to "" to achieve the same.
But an empty() $limit can be "0", so the
generated SQL statement could end with "0"
instead of the LIMIT statement. We catch this
with forcing an empty() $limit to "".
Fixes#636.
(No matter that this shouldn't even happen.)
Signed-off-by: Thomas Hochstein <thh@inter.net>
* Fix core pagination for "stable archives".
The current page will always be the current page,
regardless of archive sorting order. Page 76 of
86 pages will remain page 76, even if the archive
sorting is changed; it won't become page 10.
* Fix pagination for "stable archives" in themes.
Timeline and Bulletproof have pagination.
Both need to swap the prev/next links for
stable archives, as the sorting order has
been reversed.
* Fix prev/next page links for stable archives.
We shouldn't swap prev/next links for archive
pages. With stable archives, the title page is
the last page of the archive, not the first, so
all other pages are "previos", and we should
display it like that.
Cherry-picked from master.
Signed-off-by: Thomas Hochstein <thh@inter.net>
The freetags plugin sets this->displaytag in the frontend_fetchentries hook, and only sets clean_page if it sees that variable in the entry_display hook. The result is that wrong entries are shown on tag pages. Adding the smartyvars allows caching the correct $entries the plugin would have returned, working around that limitation without simulatign the frontend_fetchentries hook.
fetchEntries is heaviliy realient on glboal state variables, and that was missed initially. The last commit c8bbb35aacee7af8527820f3d3d5fd47d1dbf340 fixed that partially, but did not catch all global state variables. Additionally, this fixed the clean_page mode as used by staticpage by adding the logic and event hook to printEntriesCached
Needs some testing, I am not sure how to solve the case now where "no category" shall be used. It will always fall back to the default category.
Probably if someone uses a default category, that's the intended behaviour?
PHP 5.4 sets UTF-8 as the default for htmlspecialchars, htmlentities and html_entity_decode. The first two will echo an empty string when given a string with umlauts. This commits introduces serendipity_specialchar-wrapper that are meant to be a temporary solution for the s9y-core until PHP 5.6 fixed the bug, so the native charset option of s9y continues to work.
Some plugins make use of additional entry properties (title, body, extended, author) after being called by the 'backend_publish' hook, e.g.
* serendipity_event_forum
* serendipity_event_freetag
* serendipity_event_ljupdate
* serendipity_event_trackback
* serendipity_event_versioning
* serendipity_event_entryproperties
* serendipity_event_mailer
* serendipity_event_twitter
Thus we need to set these properties in the serendipity_updertEntry() method to make sure the plugins get the required data. Of course, we could fetch the entry either in overview.inc.php or again in each plugin, but that would mean an additional query to the DB.
When no categories are delivered to serendipity_updertEntry this can mean two things:
- categories need to be un-assigned
- categories where not addressed/fetched/passed to the function [see include/admin/overview.inc.php for publishing a post! Or plugins like freetag, using serendipity_updertEntry]
To address this a new serendipity[had_categories] is added to the backend template, which can be checked for.
Feedback appreciated!
Draft previews threw:
Fatal error: Call to a member function assignByRef() on a non-object in /fullpath/include/functions_entries.inc.php on line 1235, which is the $serendipity['smarty']->assignByRef('entries', $dategroup); line.
Please double check if that is gone now.
