Fabrik and SpeedCache

[SoilentRed]

We recently took some advice and nabbed up a component called speedcache to speed things up on our site. It's working fine, but for some reason ever since I installed it fabrik forms will only allow one plugin. I THINK the redirect plugin specifically may have a conflict. What's interesting is that when I try to add, say, the email plugin, it will come preloaded with all the data I had in there previously, but both "Yes" and "No" are greyed-out next to published. And when I select yes and hit save, only the bottom (most recently added plugin) will be what saves. Does anyone have experience with this?

 

[SoilentRed]

Just read your warning... I assume that this is it.

 

[cheesegrits]

Which warning?

The thing with only saving one plugin is usually if you haven't updated Fabrik after J! does a "point release", ie. goes from 3.8 to 3.9. We have to override a J! class file in order to properly support those repeated option groups (like form plugins).

-- hugh

 

[SoilentRed]

ay caramba! It looks like I may still have an issue here. I'm going to get on your radar just in case... Testing shortly.

 

[SoilentRed]

I don't know what was causing the issue, but I did a github update and using a backup, was able to get the form plugins going again.

 

[p38]

Just for interest sake did speedcache make a big difference to your site?

I find any caching tools messes up the dynamic fabrik list data, so if this component does not interfere with the fabrik list, then perhaps it is something I can use in conjunction with fabrik?

 

[cheesegrits]

I've certainly not tried it. The problem with any kind of caching is that there's really no way for anything other than Fabrik to know whether a given list or form can be safely served from cache. The main J! site caching works, because that still calls the Fabrik controller, which can then make the determination as to whether a cached copy can be served. We invalidate the site cache for a given list or form if anything happens (within Fabrik) that might change the underlying data.

But most 3rd party caches, or J!'s own cache plugin, never call the component (be it Fabrik or anything else), and make the assumption that the data being served for a given set of request / post variables (like id, pagination, view, etc) is static. So if (say) &option=com_fabrik&view=list&listid=123&start123=20 has been served within the cache timeout period, then it can be served again out of the plugin's own cache. Obviously this isn't true for Fabrik, as there could be session filters, or a form could have been submitted which modifies the data, etc. And there's no way for us to invalidate the 3rd party's cache.

So really the only way to run a 3rd party cache is if it allows you to disable their caching for a given component, and add Fabrik to the exclude list. Which may or may not work if you use Fabrik modules and content plugins, rather than direct component links.

-- hugh

 

[SoilentRed]

Speedcache did indeed do improve the performance of my site substantially. However, as Cheesey McCheesegrits suggested I've found that caching apps do conflict with my form apps. I'm thinking of uninstalling it and making my own optimizations.

SpeedCache allows you to ignore/exclude specific pages, but NOT components.

Cheesgrits, hypothetically, if I excluded pages (as I'm doing now) with fabrik, there should be no conflict, yes?

 

[cheesegrits]

Theoretically, yes.

-- hugh