Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: wet_quickopen: Open recent (and not so recent) articles quickly
Offline
Re: wet_quickopen: Open recent (and not so recent) articles quickly
wet wrote #339987:
This sentence is a subtle riddle which I fail to solve ;)
Yeah, maybe a little cryptic… I was talking about another if{}/else{} actually.
If you look a Jakobs example (bot_wtc.php) the code for loading the styles/scripts is called this way:
if (class_exists('\Textpattern\UI\Style')) {
echo Txp::get('\Textpattern\UI\Style')->setContent($styles);
} else {
echo '<style>' . $styles . '</style>';
}the first if{} detects Textpattern 4.9, then the else part is the “old fashioned” way for older versions of Textpattern. If the plugin only supports Textpattern 4.9, that detection switch is not needed.
–^–
Textpattern 4.9 has a builtin method to use a strictish, nonce based CSP, activated through config.php, sample here. When included, Textpattern send the appropriate CSP header and applies a nonce to all scripts and style blocks on the admin side. See also how conforming admin themes load their script and style resources, e.g. theme Hive.
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
phiw13 on Codeberg
Offline
Re: wet_quickopen: Open recent (and not so recent) articles quickly
phiw13 wrote #339983:
…perhaps you can make the plugin CSP aware, following the steps Jakob outlined in this thread. (other example, smd_thumbnails).
Thanks for the guidance! It gave us wet_quickopen v1.7.0.
Offline
Re: wet_quickopen: Open recent (and not so recent) articles quickly
I was stupid enough to load the plugin without wet_peex and was rewarded with a series of error messages when using PHP 8.4. It would seem that the old way of passing an error message is deprecated in PHP 8.4. It doesn’t seem to be related to your plugin, rather to Textpattern’s error handling. I filed an issue to this effect.
With wet_peex it, of course, works just fine.
TXP Builders – finely-crafted code, design and txp
Offline
Re: wet_quickopen: Open recent (and not so recent) articles quickly
wet wrote #339989:
Thanks for the guidance! It gave us wet_quickopen v1.7.0.
Works lovely on this (strict-)CSP protected site. Thank you.
jakob wrote #339990:
I was stupid enough to load the plugin without wet_peex and was rewarded with a series of error messages when using PHP 8.4. (…)
Despite having seen the GH issue report and read your quoted post I of course forgot it all the moment I wanted to test the plugin and forgot to enable wet_peex… I’ll blame the weather gods.
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
phiw13 on Codeberg
Offline
Re: wet_quickopen: Open recent (and not so recent) articles quickly
Just a general thought: what do you / people in general think about also including the next/prev buttons, which were also dropped alongside “Recent articles” in the update to v4.9, in your plugin?
“My” plugin jcr_writenav_buttons (I just turned a code snippet by Oleg and the core code into a plugin) restores both of them for users who would still like them, but your “Recent articles” search box adds a meaningful improvement. I would happily drop jcr_writenav_buttons and point to your altogether much more useful implementation.
TXP Builders – finely-crafted code, design and txp
Offline
Re: wet_quickopen: Open recent (and not so recent) articles quickly
I am not sure having a next/prev button set adds much.
You search something within the plugin, a list of 10 or less recent articles with your search keyword appear, click one of them, the search query is essentially lost. And unfortunately, the “back” button does not bring you back to your original article, where you initiated the search.
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
phiw13 on Codeberg
Offline
Offline
Re: wet_quickopen: Open recent (and not so recent) articles quickly
wet_quickopen v1.8.0 has landed. It now persists its search string across time and space as a user preference.
Offline
Re: wet_quickopen: Open recent (and not so recent) articles quickly
(in light testing) Nice work: now the search terms persist (with list) and the back button works too. Great.
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
phiw13 on Codeberg
Offline
Re: wet_quickopen: Open recent (and not so recent) articles quickly
Just got to testing this and the persistent query is perfect. Makes it even more usable. Thank you!
Two really minor things…
- When I clear the search term with the (x) Button in the search box, the search results are not cleared until I press enter (as if doing a search for nothing). Maybe that was on purpose, though, as it’s not really a live search.
- The Admin › Preferences panel shows as “wet_quickopen” menu item plus “wet_quickopen_search_term” prefs item. I’m guessing you might have intended to make that a PREF_HIDDEN on this line so that it doesn’t appear in the preferences.
TXP Builders – finely-crafted code, design and txp
Offline
Re: wet_quickopen: Open recent (and not so recent) articles quickly
jakob wrote #340001:
When I clear the search term with the (x) Button in the search box, the search results are not cleared until I press enter (as if doing a search for nothing). Maybe that was on purpose, though, as it’s not really a live search.
As I see it, after deleting the $search-term, no new search is performed, so the “old” search results are displayed. Or is it? In Firefox and Safari, I empty the field and a new list of articles is displayed but it is certainly not the list of most recent articles.
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
phiw13 on Codeberg
Offline
Re: wet_quickopen: Open recent (and not so recent) articles quickly
phiw13 wrote #340002:
As I see it, after deleting the
$search-term, no new search is performed, so the “old” search results are displayed. Or is it? In Firefox and Safari, I empty the field and a new list of articles is displayed but it is certainly not the list of most recent articles.
Thanks for clarifying. I was referring to the fact that when you click the “clear search” button within the search input, it clears the value in the input box but doesn’t revert the search matches. If you re-navigate to another page, your previous search term (as saved to the pref) still exists.
When you press enter with an empty search input, the article list expands again and the search term is removed. Presumably that’s a search for nothing (= all results) rather than the recently visited articles.
TXP Builders – finely-crafted code, design and txp
Offline
Re: wet_quickopen: Open recent (and not so recent) articles quickly
jakob wrote #340003:
[…] I was referring to the fact that when you click the “clear search” button within the search input, it clears the value in the input box but doesn’t revert the search matches. […]
Firefox does not have a “clear search” button (that is a Webkit feature, inherited by Chromium) so simply deleting the string without pressing enter is the closest behaviour I can think. But the result is slightly different
- using the “clear search” button (Webkit & Chromium) keeps the search result list, but does not remove the search string from the pref. Navigating away from the present article to another panel and opening an article for editing shows the same result list and the search string in the search field.
- deleting the string – delete key – shows (Firefox/Safari/Chromium) a list, always the same, of articles at random, old and less old
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
phiw13 on Codeberg
Offline
Re: wet_quickopen: Open recent (and not so recent) articles quickly
BTW, on the “clear search” button – I don’t think it was ever intended to be anything other that a direct action within the present (web) view, something like “quickly remove that string”, and I don’t think it should have any persistence.
Try this as exercise: open Safari, press Command-F, the in-page search field opens. Type a string.
Open a decent Mac OS compatible application (BBEdit, Textedit, Coda…), press Command-F. Your above search string should be pre-filled. (Close the search box). Go back to Safari and press the “clear search” button , return to that other application and open or view the search box: the search string should still be there.
The HTML search field inserted inside webpages behaves differently (doesn’t percolate throughout the OS) for obvious reasons.
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
phiw13 on Codeberg
Offline