Feedback to: Textpattern CMS 4.8.1 Released

whocarez · 2020-06-23 15:34:53

Updated the fourth site, which uses the tru_tags plugin and the problem described here is IMHO solved.

But I recognized another problem.

I used to build my own hover title for article lists with the following line:

<txp:php>echo htmlspecialchars_decode(html_entity_decode(trim(strip_tags(category1(array('title'=>'1')) . ": " . title(array("no_widow"=>"0")) . " - " . excerpt())), ENT_HTML5));</txp:php>

Somehow category1 is not usable. I got an "Call to undefined function category1" error.

If I use category1 directly, I’ll get at least one category with "&" in hover title and that’s not really beautiful.

Last edited by whocarez (2020-06-23 15:42:35)

Bloke · 2020-06-23 15:59:51

whocarez wrote #323947:

category1 is not usable. I got an "Call to undefined function category1" error.

Yes, that function is no more, and this unfortunately highlights the dangers of relying on PHP function calls as we gradually move away from a function-based to OO core.

The slightly more future-proof way of doing it (assuming we keep parse() around!) is:

<txp:php>
echo htmlspecialchars_decode(
    html_entity_decode(
        trim(
            strip_tags(
                parse('<txp:category1 title />: <txp:title no_widow="0" />  - <txp:excerpt />')
            ))
    , ENT_HTML5)
);
</txp:php>

or even (untested) since we have escape attributes that can do strip_tags() and trim():

<txp:php>
echo htmlspecialchars_decode(
    html_entity_decode(
        parse('<txp:category1 title escape="tidy,tags" />: <txp:title no_widow="0"  escape="tidy,tags" />  - <txp:excerpt escape="tidy,tags" />')
    , ENT_HTML5)
);
</txp:php>

whocarez · 2020-06-23 16:08:02

Thanks for your quick response. Both variants are working. So I have to go through the old code and “modernize” direct php calls.

Bloke · 2020-06-23 16:22:45

whocarez wrote #323949:

So I have to go through the old code and “modernize” direct php calls.

Yes, unfortunately. General rule of thumb is that if you’re using any Txp public tags as function calls, replace them with a call to parse() and pass a string of actual tags into it.

Another option, which is even more future proof might be to create a shortcode:

(optional) Register a new Form type called something like ‘shortcode’ so you can collect all of the codes together in your own group.
Write your tag template / HTML / PHP code in a Form. Name it (e.g. ‘hover’).
1. Use <txp:yield name="some_att" default="default value" /> to get access to attributes passed into the shortcode.
2. Use <txp:yield /> to get access to the container (note: you’ll need 4.8.2 for this as there’s a bug in 4.8.1 related to this).
3. Use <txp:yield else /> to get access to the ‘false’ part of any container tag.
In your article or template code, call your new function: <txp::hover />. Note the double colon. If you elected to use attributes, pass them in too: <txp::hover some_att="my value" />.

Thus, any time you need to make such a change in future or want to expand the scope of your function, you can just do it once in your shortcode.

P.S. smd_where_used might be able to help you find all instances of where you’ve used your code :)

Last edited by Bloke (2020-06-23 16:25:56)

etc · 2020-06-24 09:29:27

whocarez wrote #323947:

Somehow category1 is not usable. I got an "Call to undefined function category1" error.

You also should be able to replace category1(...) with

Txp::get('\Textpattern\Tag\Registry')->process('category1', ...)

DragonBard · 2020-07-03 16:48:03

I’m seeing some odd issues around front end Themes. I recently updated to 4.8.1, and sorry to say, I don’t remember which version I was on previously (definitely a 4.x release, as it was probably two years or so old).

I created a new, empty theme (named Empty), along with my previous theme (named Default). Often when attempting to switch between forms and pages with identical names in the two themes, I end up in the wrong Theme. When I switch back to the correct theme, I end up on a different form or page from the one I selected. This repeats quite often.

I did a quick look in the GitHub issues list, but didn’t see anything.

Thanks.

Bloke · 2020-07-03 17:00:01

Sorry if you’re having trouble with it. A quick explanation:

When editing a Form/Page/Style, the selector above the list of assets indicates which Theme you’re using. Txp will try and remember the last Page/Form/Style that you saved. If you switch theme using the selector then it’ll ‘jump’ to the last saved asset of that type. (if it can and it has the same name as one you last saved).

If that’s the not behaviour you’re experiencing, there maybe some odd caching going on. If so, please would you let us have your Diagnostics info and we’ll look into it.

DragonBard · 2020-07-03 17:07:07

Bloke wrote #324247:

Sorry if you’re having trouble with it. A quick explanation:

When editing a Form/Page/Style, the selector above the list of assets indicates which Theme you’re using. Txp will try and remember the last Page/Form/Style that you saved. If you switch theme using the selector then it’ll ‘jump’ to the last saved asset of that type. (if it can and it has the same name as one you last saved).

Okay, the above explains some of what is going on, but what I am seeing is not using the Theme selector, but simply switching between the forms within a theme, I will end up switching Themes, rather than the Form.

For example, I was on Empty theme, looking at the article default form. Then I clicked on the Comments comments form, and instead of seeing the Empty version, I now see the Default theme version.

DragonBard · 2020-07-03 17:46:46

Okay, this happens if I am trying to compare the content between two different versions of the same form. It flips back to the last form viewed in the other theme, then when I click on the form I wanted, it again flips back to the last version viewed in the other theme. I’d prefer for the view to stay locked to the selected theme in the Theme drop down. Right now it is near impossible for me to compare the contents of two forms between the themes.

Thanks.

Bloke · 2020-07-03 18:49:26

DragonBard wrote #324250:

It flips back to the last form viewed in the other theme, then when I click on the form I wanted, it again flips back to the last version viewed in the other theme.

Yes, it goes back to the last saved form in any theme. Not the last viewed form. We don’t track views.

I’d prefer for the view to stay locked to the selected theme in the Theme drop down.

It will (should!) if you save a form first:

Visit Theme A and look at the form you want to compare.
CTRL/CMD-S.
Flip theme. The form loaded will be the same one you just saved (assuming it exists in the target theme you just flipped to, otherwise it’ll show the first Form in the list and set that as your new base).

If it’s not doing that, then you may have some aggressive caching going on.

Bloke · 2020-07-03 18:54:25

DragonBard wrote #324248:

For example, I was on Empty theme, looking at the article default form. Then I clicked on the Comments comments form, and instead of seeing the Empty version, I now see the Default theme version.

That’s definitely not right. The theme should stick.

Just try this to humour me please:

Open your web browser’s Inspector.
Browse to its Network panel.
Check the ‘Disable Cache’ option.
Now navigate your Forms. Does it behave more logically, staying on the theme you were last using when clicking around the forms within it?
Enable the cache again, and close the inspector.
Navigate your forms this time. Does the behaviour change from when you had the cache disabled? If so, there’s something in your server setup that’s getting in the way of Txp’s normal operation and we need to figure out what.

DragonBard · 2020-07-03 21:01:44

Bloke wrote #324252:

Just try this to humour me please:

Open your web browser’s Inspector.

Browse to its Network panel.

Check the ‘Disable Cache’ option.

Now navigate your Forms. Does it behave more logically, staying on the theme you were last using when clicking around the forms within it?

Enable the cache again, and close the inspector.

Navigate your forms this time. Does the behaviour change from when you had the cache disabled? If so, there’s something in your server setup that’s getting in the way of Txp’s normal operation and we need to figure out what.

Disabling the cache on the network panel behaves as I expect. Re-enabling it and I get the weird flipping behaviour again. I’m hosted on DreamHost. I take it I should post the diagnostics. Detail Low or High?

Last edited by DragonBard (2020-07-03 21:03:23)

DragonBard · 2020-07-03 21:30:11

Solved the mystery. I was running the site under PHP 7.3.12 w/Fast CGI. Switched to PHP 7.3.12 CGI and the weird flip flopping with editing Forms went away. Is Textpattern not Fast CGI compatible? It’s fine with me, just good to know that was what was causing the weirdness.

Thanks!

Bloke · 2020-07-03 21:51:25

Glad you got it sorted.

Weird about FastCGI, though. I’ve not heard of anyone specifically complaining about Txp not running under it, and I’m pretty sure our demo servers run PHP-FPM.

You are, however, the second person in as many weeks mentioning weird cache issues on Dreamhost. I wonder if they have some particular settings in their FastCGI implementation that aggressively caches things and causes odd behaviour in Textpattern.

I’d love to find out what’s going on under the hood in such situations so we could see if there was anything we can do to stop it.

DragonBard · 2020-07-03 22:28:01

Bloke wrote #324257:

Glad you got it sorted.

Weird about FastCGI, though. I’ve not heard of anyone specifically complaining about Txp not running under it, and I’m pretty sure our demo servers run PHP-FPM.

You are, however, the second person in as many weeks mentioning weird cache issues on Dreamhost. I wonder if they have some particular settings in their FastCGI implementation that aggressively caches things and causes odd behaviour in Textpattern.

I’d love to find out what’s going on under the hood in such situations so we could see if there was anything we can do to stop it.

If there is any diagnostic data you want me to collect, let me know and I am happy to provide it.

Textpattern CMS support forum

#16 2020-06-23 15:34:53

Re: Feedback to: Textpattern CMS 4.8.1 Released

#17 2020-06-23 15:59:51

Re: Feedback to: Textpattern CMS 4.8.1 Released

whocarez wrote #323947:

#18 2020-06-23 16:08:02

Re: Feedback to: Textpattern CMS 4.8.1 Released

#19 2020-06-23 16:22:45

Re: Feedback to: Textpattern CMS 4.8.1 Released

whocarez wrote #323949:

#20 2020-06-24 09:29:27

Re: Feedback to: Textpattern CMS 4.8.1 Released

whocarez wrote #323947:

#21 2020-07-03 16:48:03

Re: Feedback to: Textpattern CMS 4.8.1 Released

#22 2020-07-03 17:00:01

Re: Feedback to: Textpattern CMS 4.8.1 Released

#23 2020-07-03 17:07:07

Re: Feedback to: Textpattern CMS 4.8.1 Released

Bloke wrote #324247:

#24 2020-07-03 17:46:46

Re: Feedback to: Textpattern CMS 4.8.1 Released

#25 2020-07-03 18:49:26

Re: Feedback to: Textpattern CMS 4.8.1 Released

DragonBard wrote #324250:

#26 2020-07-03 18:54:25

Re: Feedback to: Textpattern CMS 4.8.1 Released

DragonBard wrote #324248:

#27 2020-07-03 21:01:44

Re: Feedback to: Textpattern CMS 4.8.1 Released

Bloke wrote #324252:

#28 2020-07-03 21:30:11

Re: Feedback to: Textpattern CMS 4.8.1 Released

#29 2020-07-03 21:51:25

Re: Feedback to: Textpattern CMS 4.8.1 Released

#30 2020-07-03 22:28:01

Re: Feedback to: Textpattern CMS 4.8.1 Released

Bloke wrote #324257:

Board footer