Bjoern

By the way: I’m working towards version 1.0 which will include a simplyfied Interface similar to your previous Suggestion for which I try to implemet some kind of auto detection of optimal Settings.

WPPP uses the WordPress object cache for caching. So you need to have any persistend object cache installed to see any speed improvements, e.g. EM Object Cache, APC Object Cache or other caching plugins, which contain an object Cache like W3 Total Cache.
Cachify is a page cache only which doesn’t implement an object cache.

You can verify if an object cache is installed by looking for object-cache.php in wp-content.

As WPPP uses the Default WP-Cache-API it doesn’t conflict with any other caching plugins.

Object cache plugins shouldn’t cause conflicts with Cachify. Cachify only serves front end pages to not logged in users from cache. So installing a cache like EM Object Cache and activating WPPP caching would improve performance for logged in users and backend.

One more update for you. I took another look at your Website and found you are using bwp minify. That was the cause for your Problems (or at least it was a cause for problems), which I could fix.

So once again – please give it a try…

I added an updated Benchmark in the screenshot section. With activated cache MO-Dynamic was as fast as native gettext in my tests (even a few milliseconds faster). The reason for this being, that only used translations are cached. One Cache is used for all front end pages (front pages usually don’t need many translations, so this shouldn’t get too big). For the back end one cache per backend-page is used. Given a fast object cache (I’ve tested with file caches and APC – Benchmark used APC) this could get even fast than in my benchmarks.

So in short: Provided a fast object Cache is installed, MO-Dynamic should be at least as fast as native gettext.

Latest update (0.6.1) includes some fixes in the JIT module. Maybe these fix your previous problems.

I just visited your blog and both plugins seem to work without problems. Search in Place showed correctly and search terms are “background-highlighted” on the search results page.

But I guess JIT is deactived… so no wonder it works. Sometimes I should think first, then post…

Both work with my test Installation. Please check if WPPP is loaded as first plugin (you can use Debug Bar for this). Or just deactivate and reactivate WPPP. This should set WPPP as first loaded plugin.

Yes, native gettext and JIT localize are the best option. If native gettext isn’t available or doesn’t work use MO-Dynamic. They don’t have to be activated simulaneously.

Disable JIT if any script errors occur when using it (if so, please post them here so I can try to fix them).

BTW: I rearranged the Settings by “prioriy” in 0.5.2 and added some more info in the help tab and in the FAQ section on the plugin page.

I can’t reproduce that bug. Are you shure it’s related to WPPP? Please describe your exact steps which produce this bug. A screenshot could help also.

Version 0.5 has the option to allow user override to reactivate backend translation, but currantly doesn’t offer an option to select a default (as of now, all users have to manually reactivate translation). Next version might include this option.

I’m glad you like the plugin and I appreciate any suggestions.

I don’t like your interface idea very much, as I like to know what a setting actually changes. Your interface hides the inner mechanisms from the user.

But I understand the wish for a simple – and in my “programmer view” dumbed down – Interface, as not everybody wants to know how a plugin works exactly or has the knowledge to understand it.

I’m thinking of a way to Switch between a “default” and an “expert view”. The “Default” view similar to your idea (maybe using a slider from “fast” to “slow” for “Admin/Dashboard Acceleration” and “Web/Frontend Acceleration”), and the current settings become the “expert” view.

I’m working on the next update and am just working on your feature request. For now I’ve gone another route: I added an option to allow each user to override the setting in his user profile.

So if you disable backend translation and allow the user override, each user gets a setting in his profile to “reactive” translation. This way each user can decide on his own if he wants a fast or a translated backend.

What do you this of this? If you think it’s too confusing I could add an option to deactive translation based on e.g. user roles. I prefer the per user decision.

WPPP doesn’t rewrite htaccess. The plugin itself doesn’t use or activate gzip, but should work with any plugin that does.

Sorry for the late answer, bt here it is:

A preload mechanism would be difficult, if not impossible to implement. The next best – or even better – thing would be to use a caching plugin, e.g. W3 Total Cache.

I don’t know of any route finder plugin or similar for wordpress. The biggest problem would be to get the bus route data and keep it up to date. And programming such a route finder isn’t a trivial task either. So sorry, can’t help you with that.

Version 0.4 brings another change to the way the locale is set when using native gettext. Please give it a try.