Hi pt_list users and developers,
I've spent some time doing some minor changes to the pt_list code. I'd like to give you some news of what has changes:
I'm trying to let pt_list generate cached content whereever this is possible. To do so pt_list should/can not rely on data from session anymore. That's why I've introduced (some time ago) the new configuration paramters
plugin.tx_ptlist.controller.list.doNotUseSession = 1 and plugin.tx_ptlist.controller.list.appendFilterValuesToUrls = 1
The first parameter prevents data from being stored to and read from the session. And the second parameter lets pt_list create a get-parameter string from the current list's status and append that to all links. (You need to add this configuration to all filter configurations aswell).
I did not touch all filters to support this feature, but it is easy to update them. Have a look at the group filters.
Then I introduced a new cached pt_list controller class (tx_ptlist_controller_clist). This basically inherits everything from the uncached one. The only difference is how this is included into TYPO3. Be sure to create chashes to all links when creating cached content by:
lib.tx_ptlist.typolinks.options_links.useCacheHash = 1 lib.tx_ptlist.typolinks.pagerLink.useCacheHash = 1 lib.tx_ptlist.typolinks.string.useCacheHash = 1 lib.tx_ptlist.typolinks.filterResetLink.useCacheHash = 1 ...
Then I added a new configuration parameter for the string filter:
filters.defaultFilterbox.10 < plugin.tx_ptlist.alias.filter_string filters.defaultFilterbox.10.useGet = 1
This forced to string search form to post its data via get instead of posts.
For advanced USER/USER_INT switching you could add this snippet in order to half non-cached content based on string search filter values (for group filter we want cached content, only for dynamic content we don't)
[globalVar = GP:tx_ptlist_controller_filter_string_yourList_searchFilter|value = ] # do nothing as the clist is cached by default [else] # switch to USER_INT plugin.tx_ptlist_controller_clist = USER_INT [end]
One lack in design is that reset links for filter will be generated in the filter box. This is absolute ok when running pt_list in the session mode, because all reset links look the same. But when running pt_list in the "url" mode we need individual reset links that should be rendered from within the filter template.
To realize this (in a completely backwards compatible way) I added the parameter:
renderResetLinkWithinFilter = 1
This parameter prevents the link from being rendered within the filterbox. The link should be rendered from within the filter itself. I did not change all filters. But again: This is easy. Please have a look at the link group filter or the search box.
Maybe it's time for a rewrite of this extension keeping in mind that most use cases will be cached content (at least this is what I think).
Even if it is not backwards compatible I'd really like to clean up the way reset links are handled. And remove them completely from the filterbox. In most cases you need them in your filter anyways for styling them in your interface.
Bye, and have a nice day,