error export to XML file

Hi! I’m seeing this in some sites too.
I compared settings and I noticed that this is happening when the db is >20MB and the restart job param =0, restart counter =1, max execution time =0. If I raise the value of the counter to 5 and enable restart jobs after each task, and set a max execution time lower than the real one (if in PHP is set to 90s, I’ll set 80s here), then I am able to run it ok.

Surprisingly, I didnt found this error in servers with PHP 5.2. It’s happening in my servers with 5.4. Oddity…

The error from the log as follows:

[24-Dec-2013 10:30:24] WARNING: strpos(): Offset not contained in string [24-Dec-2013 10:30:24] ERROR: Could not generate a WordPress export file.

I’m running WP 3.6.1

Guys, hi. If you go to the WordPress Tools menu, Export. Are you able to export the XML file normally? Cause I’m not in the website with the issue.

Does this apply? https://www.ads-software.com/support/topic/sometimes-it-cannot-export-the-xml-file?replies=3#post-5034137

In my particular case, I’m testing it and will let you know. dont know if it could be the same error source to others.

Hi, I have the same problem. Does this problem only belongs to the free version?

Still unable to export XML files…. Nothing new detected?

Hi, some additional comments, maybe it will help someone, or maybe Caspar can explain this further.

Exactly the same problem with “strpos(): Offset not contained in string” appeared suddenly on my site on Dec 28th, before that no problems. After much searching I tried the suggestion of Marcelo Pedra above, and suddenly the backup worked again, thanks Marcelo!

However, when I looked at my backup zip archive in Dropbox, the size had increased from about 50MB on Dec 27th to over 160MB from Dec 28th onwards. When comparing the old and new backups, I found that the reason for the drastic increase in size was due to a new folder in wp-content/uploads/backwpup-02b25/ with an uncompressed size of 113MB. If I understand the BackWPup log file correctly, this folder is created as a temporary folder during the backup process, but I suppose it should be deleted when the backup is done?

I’m not a programmer, but my layman summary of what happened would be: For some reason the temp folder was not deleted, which resulted in a huge increase in backup size, which in turn caused the backup process to time out until I changed the settings. But why wasn’t the temp folder deleted, could we avoid this problem in the future? Thanks.

@hans Ehrencrona:
The problem I see in your site is that the temp folder IS BEING included in the zip file uploaded to Dropbox. Have you tried excluding it using the folders tab in that job settings screen?

@caspar:
Actually the strpos problem is still happenning to me in two multisite installs but the backwpup settings page is ignoring my settings for max execution time. If it dont allow me to set it to 90 seconds, the process will stall, and on restart job, will get the error again. It’s weird, because in the same VPS I have standalone WP installs where I was able to change those settings. So, it is surely a problem with multisite compatibility. I searched via phpmyadmin, but I dont know where this settings are being saved in order to manually set it ?? . If any of the developers can point me out what to change, It will be great.

@marcelo:
Thanks for your input. Maybe I was unclear in my description, but I have had BackWPup running for about a year without any problem and the zip file was always around 50MB. When the strpos problem occurred and the backup failed, the zip file was suddenly over 160MB due to this folder (the size change came literally overnight, no change in my site layout). I have never changed any settings as to which folders should be excluded, so this must be an error in BackWPup and not anything that I have done as a user, IMHO.

@hans: you’re right then. You should open your own topic in this forum since you are experiencing a different problem.
Thanks

@caspar / Daniel Huesken:
Is there any coming fix to the xml export issue? or should we shout to WP rather than this plugin?

Anybody know how can we troubleshoot to define if it’s WP or the plugin the culprit?

Hi again, Marcelo. I’m not sure why it would be a different problem, the error code I receive is exactly the same as the original poster @bicounet stated in this thread. And as you alluded to in your first post here, Marcelo, it seems to be related to an execution timeout.

ok, let’s keep it here. I proposed a new topic due to the incorrect folders being added to the zip package. THAT could, probably, be a different bug.

hi,
I’m still having the same problem on another site I just upgraded to WordPress 3.8.
WordPress Backup Plugin Version 3.1.1 worked correctly previously.