Bjoern

This issue should be resolved in v1.8.

Version 1.8 includes an option to restore static links and will do so automatically on deactivation.

Version 1.8 includes options to restore static links and will do so automatically on deactivation.

Maybe you did override the default setting in your user setting (if the option to do so is activated).

You can enable debugging (you have to install Debug Bar for debugging). This will show which classes are used for the loaded textdomains. When backend translation is disabled NOOP_Translation should be used.

Hi, sorry for the late response. I was on vacation.

The {{wpppdynamic}} is added when dynamic Image linking is enabled. As of now, it’s never removed, but replaced by the right path as long as the plugin is activated. So as a workaround kepp WPPP activated, but disable everything. The dynamic links will still be replaced.

I’m currently working on the next release of WPPP and I’ll add a tool to restore the Image URLs in the posts, which will be executed automatically when WPPP is deactivated.

Thanks for the hint. I duplicated the method so this will be fixed with the next version.

It might come with 1.8 or 1.9. The current implementation is (in the meantime loosely) based on Dynamic Image Resizer. The exclusion of multisite is based on the way files got handled the time that plugin was developed. That has changed and maybe this opens the way for multisite support, though not as “elegant” as for single site setups, multisite doesn’t allow htaccess rewrite rules.

But for now I’m working on resturcturing WPPPs internals. After that, I’m going to change the way the dynamic resizing is done (right now it’s basically done the way Dynamic Image Resizer does it, but that way when editing an Image in WordPress dynamic resizing doesn’t work) and then I’ll look into multisite.

So stay tuned ??

Sorry, don’t know how that one slipped through. Should be fixed in 1.7.6.

It took a while longer, but I just uploaded Version 1.7.5. Please test if now you can activate the plugin without errors.

I don’t know why that error occurs (the specific it should work with your PHP version), but I think I know what causes the issue, so I’ll change the implementation. The next update (somewhen this Weekend – I’m in the middle of some major code changes) should fix it.

Which PHP version do you use? And did this happen when you activated the plugin?

Version 1.7.4 fixes this issue as it performs some simple integrity checks on mo file contents. This causes the french translation of All In One SEO Pack not to be loaded (as does wordpress’ default implementation).

I could identify the problem: It is caused by the French language file of All In One SEO Pack. It seems to me, the file is corrupted. The default WordPress implementation doesn’t load the translations (All In One SEO stays in english). WPPP doesn’t catch the error and tries to read insanely large strings (caused by erroneous tables in the mo file – the first few entries seem fine, then suddenly offsets and sizes get out of control, so to say).

Quick fix: Delete all_in_one_seo_pack-fr_FR.mo from all-in-one-seo-pack directory.

I’m going to implement some sanity checks so WPPP will catch such corruptions instead of trying to allocate that insane amount of memory.

One more thing: Could you post the full stack trace from the error (maybe you have to activate debugging so it gets displayed). That way maybe I can determine faster where exactly the error occurs.

Ok, I’ll try to reproduce the error. I guess it’s a problem with one of the language files. Maybe it’s a bug in the mo reader, maybe an error in one of the files.