SPF is compatable with wp-minify and hopefully soon with wp-super cache… (already compatable with wp-widget cache)

we are currently working on reducing and triming everything, wherever possible, with each upgrade, so these types of requests are being attended to 🙂

no, we arent doing anything for wp-super-cache…  really doesnt make sense given the total dynamic nature of the page generation.

4.1 will include MANY query and throughput improvements…

We also hope to ship with minified css and js starting with 4.1…

Thus far, the WP 2.8 concatenation of scripts breaks just about everything so not sure how to get there yet…

Just pinging this thread, as SPF 4.3.5 has meanwhile rolled by in the stable release cycle, and I have trouble getting WP-Minify to work on the SPF pages. That is to say: having the WP-Minify plugin active won't break SPF, but it's necessary to exclude all SPF pages to avoid a bad clash.

Presently I do that in WP-Minify by excluding the SPF's JS and CSS files:

• In the WP-Minify settings page in the field labeled “JavaScript files to exclude from minify (line delimited)” I input the value “simple-forum” (no quotes)
• In the field labeled “CSS files to exclude from minify (line delimited)” I input the same “simple-forum” value (again, no quotes).

That's to ensure WP-Minify keeps working for the rest of the site, just not on SPF's “pages”.

So um, here's my request to see if there's something that could be tweaked or, perhaps, made context sensitive so as to allow WP-Minify to take a load off the JS and CSS code, which undoubtedly would help making the forums load faster, too.

Then, with WP Super Cache the same principle applies: having that caching plugin active won't break SPF, however it has to be disabled for all SPF controlled pages. In the WP Super Cache settings page, in the Accepted Filenames & Rejected URIs section, look for the field labeled “Add here strings (not a filename) that forces a page not to be cached. For example, if your URLs include year and you dont want to cache last year posts, it’s enough to specify the year, i.e. ’/2004/’. WP-Cache will search if that string is part of the URI and if so, it will not cache that page.” There, you input the URI segment that is relevant for your forum. In our case, the forum unimaginatively lives in the “forum” slug so that in the URI it shows up as /forum/ so “/forum/” is the value that goes there, in its own line, to exclude SPF from being (fully) cached.

It'd be awesome if at some point support for WP Super Cache could be built-in, either “negatively” by using the “do not cache” hooks of WP Super Cache, or “positively” by using e.g. the 

 and 

plugin hooks (which would require a “plugin” file for WP Super Cache of course).

This thread started with the V3 family of SP. In the V4 family, all scripts and css that can be compressed has been. We have never, along with some other plugins, had any success with concatenating scripts. So we took the approach to be careful with what we load for each page and load only what is actually needed.

We really made a mistake breaking the CSS into more than one file and that will be changed quite radically.

Caching is a more problematic thing. it's not just that every page load is different depending on what forum or topic you are looking at. Each page load can be and usually is different for each user as well. if the 'do not cache' hooks actually work (which, at one time was very questionable) then I would be happy to take another look at that.

We have started to internally cache a few things internally and that is an area that is destined to grow.

We have started development on version 5 (which keeps getting interrupted by WP changing core things we need to release updates for). Some  of the main targets for this version are: (a) SP plugins which will not only make SP more easily extendable  but will also move many of the current options to plugins thus reducing the core code; (b) reduce images and wherever possible introduce CSS sprites; (c) remove Highslide in favour of jQuery UI components (which may help in the concatenation question but that remains to be seen); (d) introduce more internal caching where possible; and (e) replace the current skins/icons approach with themes and templates. But at all times the overall goal is to reduce code, reduce http requests and make it far easier for our users to customise their forums.

Thanks so much for that clarification! However, I think an apology is in order: I probably gave the impression that the issues with concatenation / minifying and caching are major or trivial or perhaps even both; neither is true, and I am very mindful and appreciative of the enormous (truly staggering) amount of coding involved in SPF development. I am not too sure whether people realize what a monumental effort Simple:Press represents.

So, just to be sure: any issue in both WP Minify and WP Super Cache can be very simply circumvented (averted) by disabling the SPF pages in those plugins, as I indicated above. And for the foreseeable future, I see no real downside to that, as SPF performs very well.

All five suggested avenues for the version 5 series of SPF look promising. With regard to “internal” caching methods, that seems a very large undertaking; I just wish I could be of practical use there, and perhaps Donncha can shine some light on possibilities to “plug in” to his WP Super Cache plugin, as you said: where possible. And with regard to ditching Highslide in favor of jQuery UI: hells yeah!

Anyway, I'd like to once more just indicate that I was jotting down a few things, more intended as “that'd be nice” feature suggestions than anywhere near pressing issues. Again, it's just impressive to see SPF progressing as it does. Thanks again.

Thank you for those supportive comments. It always helps – especially on a forum dedicated to problems!

The sort of small time in-line caching that we started playing with in V4 has helped enormously for very little effort. Things like grabbing and formatting a user-info box in a thread just the once -running queries just once and making the results available for re-use etc. Seems obvious when I write this down but as is so often the case with software development these things evolve with need over time. So yes – we plan to try and get a lot more of this sort of thing into V5.

Now…. if only I could find that extra time to get in with it. That would be nice!

Seems like every time we start to dedicate ourselves to the task, WP announce yet another release with core changes that break SP and we have to stop once again!