yudayuda

Thanks Bernard for your response.
Currently I have the following entries after the plugin’s flags, in the following order:

1. wp-types plugin.
2. Divi theme
3. Views plugin (part of the wp-types family)

Thanks a lot Bernard, this is great news!
Can I use this space to suggest a minor improvement?
Currently, the language “buttons” are located on the highest level of the main admin navbar, and adding an entry for every language with its corresponding flag. This indeed is very useful & easy to locate, however it takes a lot of space on the admin navbar, and in my case preceding some other important entries that now I should scroll into view every time I want to use them.
Since I don’t assume people are switching admin languages that often, I believe a more “discrete” location would be better. This can be as a settings page under the “Settings” entry, or as a dropdown on the admin top bar (my preferred solution: still very easy to locate & operate, but doesn’t take any space on the main navbar).
Hope you’ll find this suggestion useful, and thanks for all your efforts ??

thanks so much… was on my way of installing it to all my clients – thanks god i didn’t…

Same case with me. Whenever a site’s name has non-ASCII chars (in my case, Hebrew chars), it is auto assigned to the ZIP name, and then the download function fails.

The file is indeed there on the server, and it works fine if I download it thru FTP, but the download link in the WP admin fails (404 error).

The URL that fails contains the file name as:
wp-content/backups/-.backup.2012-04-24-05-59-20.zip

notice the “-” – I suppose the plugin uses this as default when it fails to use the proper UTF-8 file name.

Any workarounds for now? Maybe use the “Constants” mentioned in the plugin – but where are their docs?

Thanks heaps

yuda

You can try TRUEedit – allows you to switch autop off – plus many other such hard to find customizations to the editor.

kudos mercime, beautiful short answer

bump. same here.

See my reply here

good luck

I had the exact same problem (WP 2.5, K2 theme, homepage only crashes).
After grueling testing, inc upgrading to XP-SP3, removing all plugins, then posts, then sections of code – the culprit was found in a DB call for the blog links, in the Links section on the sidebar.

My suspicion is that the real problem is always DB related, not necessarily with links. In another post someone reported that changing (?) the DB helped him – so possibly some actions can be taken on the DB to solve it.
I simply deleted the problematic DB call… probably until next time.

BTW, my host is running Windows/IIS, and as a result I get heaps of problems. I wonder if this is also MS-Windows/IIS related (on top of the MS-IE problem :-). Do the rest of you use IIS as well?

Good luck
yudayuda