On creation a category is not listed

phiw13 · 2025-06-07 04:22:35

When creating a (new) category (parent or child), it does not immediately appear in the list.

1. Create a category
2. the message pane notifies of success
3. look the category up in the list.

Actual results: category is missing in the category list and missing in the “Parent” drop down.

But create a second category, and after pressing the Create button (and seeing the success message) the first newly created category appears in the list. Alternatively, after creating the first new category, visit the edit category panel for any other category, do nothing just press cancel, the newly created category is there listed.

4.9.0-dev latest, PHP 8.4-something and 8.3.something. In both cases long living sites.
Tested: Article and Image categories, top level or child.
Firefox and Safari.

But oddly, I cannot seem to reproduce this the dev-demo site.
Further testing on a recently (01-2025) created test site on localhost also works correctly. Both the long living sites have at least 25~30 categories, the dev-demo site and my newish test site only have a limited number (3~4) cats.

Bloke · 2025-06-07 06:10:59

I have exactly the same issue on my server. Changes are always one action ‘behind’. Oleg and others cannot reproduce it. It’s very very odd.

As far as I can recall there are no console warnings or errors. It just doesn’t update the list until you refresh or do another action. Dumping data for debugging is difficult because it’s Ajax. I’ve tried and haven’t located the source of the behaviour yet.

Last edited by Bloke (2025-06-07 06:22:34)

phiw13 · 2025-06-07 06:25:54

Ah, at least that makes the two of us playing 🙃!

The one pattern I see: all the sites having this issue have been running 4.9-dev for some time, from before 4.9.0-beta1.

Bloke · 2025-06-07 06:29:07

Yeah my server has that accolade too. Maybe it’s an upgrade thing? Going from some version like 4.8.8 to dev? Which won’t manifest itself on the demo server as it’s a reinstall every few hours.

Here’s my original alert to the issue if it has any bearing. I’d love to get to the bottom of this, as it feels like buggy behaviour from somewhere.

Edit: although I think it also does this on a client’s site (not on my server) and they’re running 4.8.8. I’ll double check.

Last edited by Bloke (2025-06-07 06:31:12)

Bloke · 2025-06-07 06:41:33

Yep. Same behaviour on 4.8.8 on my client’s site.

Bloke · 2025-06-07 11:19:23

I wonder if there’s a common plugin we have that’s interfering? I haven’t tried turning mine off but I’ll try it later, just in case.

phiw13 · 2025-06-07 11:34:05

A possibility: adi_matrix ?

Bloke · 2025-06-07 11:53:22

phiw13 wrote #339824:

A possibility: adi_matrix ?

Maybe. Don’t think it touches the category panel but it might be running there by mistake due to incorrect event targeting. Good call. I’ll try when I get home.

Bloke · 2025-06-07 11:58:21

phiw13 wrote #339824:

A possibility: adi_matrix ?

Just tried it on the demo server. Bingo. Genius, thank you. I’ll fix the plugin later.

Apologies, it must be loading itself on that panel in error.

Bloke · 2025-06-07 12:21:16

This gets weirder… The plugin doesn’t run much on the Categories panel, as all the events correctly target other panels. But in the constructor, it grabs all categories and stores them in its own internal variable for later. If I comment out that line, the Categories panel works fine.

Digging deeper, it turns out that if anything makes a call to getTree('root'); on the Content>Categories page, it kills the ability for categories to function properly.

That smacks of a bug in our getTree() function. Perhaps it’s inadvertently leaking something? Or changes some internal array pointer and doesn’t reset it, so when the second call to getTree() comes along it’s in some unexpected state?

Any clues, Oleg? I won’t be able to debug this till later. To reproduce it, just install the following one-line admin-side plugin that calls getTree('root'). Then try creating / editing article categories.

# Name: smd_catbreaker v0.1
# Type: Back-end only plugin
# No description
# Author: stef
# URL: https://plugins.textpattern.com
# Recommended load order: 5

# .....................................................................
# This is a plugin for Textpattern CMS - https://textpattern.com/
# To install: textpattern > admin > plugins
# Paste the following text into the 'Install plugin' box:
# .....................................................................

H4sIAAAAAAAAA11QwW7CMAy9I/EPVS6FS2na0m5G/MJOu1de4pRotKkSMzEh/n0JlMtu79l+
z89GkBJuARoQymkShwD7CoQ12Yavs52YvEFF2fF4zHLUo53ybXZbrwbiT0+0yb1znG8P69U9
aTsQP+SDdVNiNYiykAlFe/6do72FOq0A4bwmn/g+8hYEXvjk/DIbmEyCsnw1+ou3D0sJ4sQ8
B9jt5vNlsFMomK48I8eoU6Hc+BDGMU1BeTvzEkZG3w+X/avGJOaMQ0hJyufyCUd6CcKoe4X8
5Qm/yb8inR3qfjkgVkDsl2tH/UTxgxXVWpFUqsWuNkTS4Fv13nRtVzZlY1Ac7n9WPsTnfAEA
AA==

It only affects the type that you are fetching. In this case article categories. If you change the call in the plugin to getTree('root', 'image') then Image categories break and are delayed by one action, while article, file and link cats behave fine.

Last edited by Bloke (2025-06-07 13:14:58)

Bloke · 2025-06-07 15:48:58

Ahaaa, hang on….

function get_tree($atts = array(), $tbl = 'txp_category')
{
    static $cache = ...

^^^ cache culprit? The second time it’s called on the page (after the plugin, I expect), it will return the original data from the first call, hence it’ll always be one behind.

So how do we get around that? The whole point of the cache is to avoid unnecessary DB queries and usually it’s a good thing.

The only way I can think of is to introduce a $refresh attribute in that function, which is usually false, but when we call it in the Categories panel, we set it to true. If we add that to the list of things that trigger nocache a little further into the function, that should allow the cache to work under normal circumstances but on the Content > Categories panel, where we’re managing these trees, we always want the freshest content.

That does kind of pander to ‘what if a plugin intervenes’ which is not The Txp Way ^TM. I’m not super keen on doing it like that, so can anyone think of anything better that doesn’t burden plugin authors with having to jump through hoops to get it to work in their own code, but also plays well with core if they do?

Last edited by Bloke (2025-06-07 15:58:28)

Bloke · 2025-06-07 16:11:48

I’ve pushed a tentative patch as described above. It’s hacky but it seems to work, and hopefully doesn’t prevent the cache from working in other use cases.

Please grill it, and if anyone can think of a better way, let’s do that.

In the meantime, I’ll probably hack the adi_matrix plugin so it only loads the category tree if it’s on an admin page where it needs it. Edit: Patched;

Last edited by Bloke (2025-06-07 16:13:50)

Textpattern CMS

Textpattern CMS support forum

#1 2025-06-07 04:22:35