0 - call_user_func_array(): Argument #1 ($callback) must be a valid callback

[cmirnow]

No. Your supposition is wrong. It was an attempt at sarcasm, but I failed to translate my irony into English. 😊

The problem is that I am sorely lacking rspec tests and the like in the cms framework of (seemingly) Joomla. I use different browsers, Chrome and Chromium on my linux, also Opera and Chrome on Android. But manually testing this bug is extremely time-consuming: the bug rarely appears.

And I really don't know what to do. I've had big problems with Joomla caching before, we even tried to write alternative caching, earning Michel Babker's praise. Now I don't understand if this is a component problem or a Joomla cache problem. That's why I kept silent: I was hoping you would say something wise and make a decision yourself.

OK, let's close the issue.

[eworkers]

You mean that the issue still exist in your case?

[cmirnow]

I mean, I don't know that. I stopped testing. If in the future I see a bug manifesting itself, I will tell you about it.

You don't understand. Joomla caching is my psychological problem, my complex. 😰
Please take a look at this screenshot.

Some time ago I saw this on my site instead of a template. This collision happened irregularly, once a month, only with cache enabled. I will add, other Joomla users were also getting a similar error.

This problem has not been able to be logged. This problem has not been resolved, it hangs in the air.

I don't understand what is going on with the development and support for caching in Joomla. It is incomprehensible to me how Joomla developers can work in such a strange way.

[cmirnow]

@eworkers, that's just to give you an example. My blog has never created that much cache in 12 hours of work:

I couldn't clear the cache from Joomla admin panel: "gateway timeout".
I had to ssh to the server and clear the cache manually.
Immediately after clearing the cache I got this error. After the second click on the link, the problem disappeared. Trust me, the Chrome cache was cleared.

The problem remained. Fortunately, it shows itself rarely.

[cmirnow]

Thank you "added option to disable com_k2_extended cache container". I think it will be useful for many K2forJ4 users.

But I already solved the problem of large cache size this way:

0 0,12 * * * php /var/www/public_html/cli/joomla.php cache:clean

And the error "0 - call_user_func_array():" is no longer displayed. Anyway, I can't see it now.

P.S. My blog with K2forJ4 component works fine under Joomla 5.0.2. What do you think, maybe this line should be rewritten? -

unofficial version of K2 for J39+ & Joomla4

& Joomla5 ?

[eworkers]

0 0,12 * * * php /var/www/public_html/cli/joomla.php cache:clean
this seems like a cron tab to clear cache. However, it does not address the root problem but rather masks it by consistently emptying the cache.

However, we conducted several tests (and plan to conduct more) and it appears that the com_k2_extended container has no impact on serving cached content. It would have been immensely helpful to have information from the original developer regarding the introduction and purpose of this container, as it seems that the use case is no longer valid (or perhaps we misunderstood it). Unfortunately, we hesitate to seek an explanation due to a previous unfriendly communication experience, where our contribution was unwelcome and the entire forum thread on JW was deleted. Consequently, we find ourselves navigating this situation independently.

Regarding the J5 thing, we will do some extensive tests (worth noting that writing automated test for component in joomla is not that easy especially when you are writing that to something that you didn't originally developed) with backward compatibility plugin disabled before deceiving anyone by falsely claiming so. We deeply appreciate that contribution you made so far, perhaps you can share with us your experience on J5 in case you already have backward compatibility plugin disabled.

[cmirnow]

It would have been immensely helpful to have information from the original developer regarding the introduction and purpose of this container, as it seems that the use case is no longer valid (or perhaps we misunderstood it).

Today I couldn't get rid of this error by reloading the page. It was the first time.
I installed the latest revision of K2ForJ4 and kept the com_k2_extended cache disabled setting. I hope this helps to get rid of this strange error, which manifests itself very rarely....

Unfortunately, we hesitate to seek an explanation due to a previous unfriendly communication experience, where our contribution was unwelcome and the entire forum thread on JW was deleted.

Perhaps you can try asking on the JoomlaWorks forum again. K2ForJ4 developers are not doing anything wrong, K2 license allows them to create this fork. This work is for the benefit of the many K2 users who have been left without updates to the component, which poses a security risk to their websites. Thus, if Fotis does not respond, it will be a problem of his conscience.

[nimouldy]

but this looks exactly like a callback with key from com_k2_extended

[cmirnow]

this seems like a cron tab to clear cache.

Yes, of course it's cron.

All I can say now is that if Behaviour - Backward Compatibility -> Classes Aliases -> No, the "K2 Quick Icons (admin)" module causes the error "0 Class "JURI" not found". It seems that under a similar condition, the "K2 Stats (admin)" module causes the error 0 Class "JHTML" not found.

The K2 material page when disabling the "Behaviour - Backward Compatibility" plugin returns the error "500 - Whoops, looks like something went wrong". I will also add that if all K2 extensions are enabled and the Behaviour - Backward Compatibility plugin is disabled, it fails to enable it: "0 Class "FinderIndexerAdapter" not found".

[cmirnow]

but this looks exactly like a callback with key from com_k2_extended

I disabled the com_k2_extended container cache only after seeing this error once again.

[eworkers]

Ah, ok, got lost in translation, so you mean the problem disappeared after disabling com_k2_extended and never appeared again, right?
We think that com_k2_extended container has no effect what so ever in joomla 4 at least, it is just duplicated data that will never be served, just increasing cache storage and causing callback problems, but we plan to study this further before deciding to completely remove this container

[cmirnow]

Ah, ok, got lost in translation, so you mean the problem disappeared after disabling com_k2_extended and never appeared again, right?

Looks like it. I don't see this problem after disabling the cache via the new K2ForJ4 option in the latest revision. If this problem reappears, I will let you know.

We think that com_k2_extended container has no effect what so ever in joomla 4 at least, it is just duplicated data that will never be served, just increasing cache storage and causing callback problems, but we plan to study this further before deciding to completely remove this container

Yes, I understand. Unfortunately, this may trigger an increase in resource consumption on a site that contains a lot of K2 content. Or am I incorrect?

[eworkers]

Yes, I understand. Unfortunately, this may trigger an increase in resource consumption on a site that contains a lot of K2 content. Or am I incorrect?

Yes of course, it creates N serialized objects in cache storage equal to the N k2 items within a k2 itemlist page, but we found out that joomla new cache system is bypassing these objects when serving content from cache no matter what, and it only serve the cached page within com_k2 container related to the specific k2 itemlist page. Thus, from our founding so far no performance effect, on the contrary additional execution time to store these N objects and to deserialize these objects for reading without serving them eventually, additional disk storage, and occasional invalid callbacks when looking for matched keys within com_k2_extended.

In short, serving k2 from cache on new Joomla versions is good enough without this com_k2_extended container.