help diagnosing import errors please!
-
Hi, I’ve successfully used FooGallery for years; great plugin.
I now need to migrate to a different host, and different website, so I’m using FooGallery export/import functionality. Export readily creates a text file I use for import…which works, sometimes. (FooGallery 3.1.1; WP latest on Bluehost.)
I usually get “There has been a critical error on this website.” I’ve enabled debug_log, and once saw php_ini limit of 60 sec as problem, so I upped to 300 sec, but that hasn’t fixed the import issues…which often happen without logging on debug_log.
Sometimes I simply repeat the import and it works…or adds a few slides to gallery before error. Usually not at all.
I have about 20 yr of annual slideshows, each about 40 images per gallery, to import. I’m importing them one by one to help. Any advice on how to diagnose/fix appreciated; my interactions with Bluehost support staff has been decidedly mixed, so I suspect this forum may be more helpful.
Jim
-
This topic was modified 1 month, 1 week ago by
doctorproctor. Reason: little edit
The page I need help with: [log in to see the link]
-
This topic was modified 1 month, 1 week ago by
-
We’re glad to hear FooGallery has served you well over the years!
Based on what you’ve described, this does sound very likely to be a server-side limitation rather than a FooGallery bug, especially given that:
- The same import sometimes works when retried
- The error is intermittent and not always logged
- Increasing max_execution_time helped once, but didn’t fully resolve it
- The import occasionally completes partially before failing
All of those are classic signs of hosting constraints being hit mid-process. Let me break this down further:
What’s most likely happening
The FooGallery import process needs to:
- Parse the import file
- Create gallery records
- Process and attach multiple images
- Write data to the database
On some hosts (Bluehost included), this can be interrupted by limits such as:
- max_execution_time
- memory_limit
- post_max_size / upload_max_filesize
- Internal PHP worker limits or request throttling
Unfortunately, when these are enforced at the server level, WordPress doesn’t always log them to debug.log, which explains why you’re seeing failures without any clear error output.
Why retrying sometimes works
When you retry the import, fewer items may be left to process, so the request completes before hitting the server limit. That’s why you’re seeing partial success or full success on subsequent attempts.
What we recommend next
Since you’re already importing galleries one by one (which is the right approach in this case), the next step would be to ask your host to specifically check and adjust the following for your site:
- PHP memory limit (ideally 256MB or higher)
- Max execution time (300 seconds is good, but confirm it’s actually applied)
- PHP workers / request limits
- Any ModSecurity or request timeout rules that may interrupt long POST requests
When contacting Bluehost, it helps to be very explicit that this is a long-running admin import request that needs sufficient PHP resources to complete.
With all of this said, we’re limited in how deeply we can debug server-level behaviour, but from everything you’ve shared, this is almost certainly something your host will need to assist with on their end.
Thanks again for using FooGallery, and I hope this helps point you in the right direction.
Regards,
ElvisHi, excellent response, thank you!…I’ll keep in touch on progress for the benefit of others.
Jim P.
OK, well, I’m sorta limping along here with FooGallery imports. This is what I and Bluehost have done so far:
- Upped max_execution_time, now at 1200 sec (!). Longer exec time *may* be helping, but import process still aborts.
- Bluehost also whitelisted possibly uploads URL in mod_security.
- Most common now is (FooGallery?) reporting “Something went wrong with the import.” But no other debug.log errors evident. (display_errors set on in PHP_INI, but no new errors display.)
- Noted warning: “[21-Dec-2025 02:52:23 UTC] PHP Warning: Attempt to read property “ID” on false in /[host]/plugins/foogallery/extensions/import-export/class-foogallery-import-export.php on line 69″
- Also noted error WP automatically reported: “An error of type E_PARSE was caused in line 141 of the file /[host]/wp-content/plugins/foogallery/extensions/import-export/class-foogallery-import-export.php. Error message: syntax error, unexpected identifier “wp_die”, expecting “function””
At this point, here is what I do: (a) I run an import script and monitor media library (NOT FooGallery import screen; it often does not display) for progress; (b) I note “Something went wrong” error, but continue to check media library, as images continue to import [oddly in .webp, then convert to .jpg, though originally in .jpg, I don’t have any image optimization plugins nor do I find anything in Bluehost that does this]; then (c) once images stop importing I re-run same script, repeating several times until all images imported. Once they are all imported, script completes (though doesn’t necessarily tell me so) and seems to correctly create a new gallery.
The above process is laborious, but has now worked for ~1/2 of the galleries I need to create.
Jim P.
hi @doctorproctor,
Thanks for providing all that info – it is really helpful. The 2 PHP errors you mention are warnings and should not stop the import. Having said that, I have made some tweaks so those errors will not occur in future.
Looking at the code, the reason you are not seeing any progress when doing an import, is because the whole import is being run in a single operation on the server, which can be problematic for large galleries, or where the image importing into the media lib is taking a long time and causing the overall import to timeout (which I suspect is what is happening).
Just a side note – when FooGallery imports attachments, it uses the standard WP functions for doing so, so if there is any other process converting to webp etc then that would make it take longer. FooGallery does not do any image conversions and does not do anything specific to webp, so that must be coming from another plugin or your theme.
Are you able to post your gallery import JSON, so I can test it out locally to see what the problem is?Also, can you paste your System Info from FooGallery Setting pls?
Another thing – since WP 6.1 WordPress automatically generates WebP versions of images during upload if the server supports it.
Some good news! I refactored the import so that it incrementally imports images and galleries to avoid the problem you are having. It will now show progress as it imports each image and then does the galleries, and it will log any errors it may get along the way. And you can resume imports if you refresh the page.
It is available in v3.1.5 here: https://downloads.wordpress.org/plugin/foogallery.3.1.5.zipHi, and again thank you for such quick and detailed help!…your plugin has a great developer ;-).
By miracle, my (shared hosting) import process sped up late last night, not without similar burps but I got through the remainder of my import more quickly. I assume your updates will be of great help to those doing something similar to my task of the last few days!
Below is system, info, just fyi. Thank you again for all your help.
Jim P.
***
FooGallery version : 3.1.1
WordPress version : 6.9
Activated Theme : Bluehost Blueprint
WordPress URL : https://jimproctor.me
PHP version : 8.3.28
Thumb Engine : default
PHP GD : Loaded (V2)
PHP Imagick : Loaded
WP Image Editor : FooGallery_Thumb_Image_Editor_Imagick
Thumbnail Generation Test : https://jimproctor.me/wp-content/plugins/foogallery/assets/logo.png
HTTPS Thumb Mismatch : None
Available Image Editors : Array
(
[0] => FooGallery_Thumb_Image_Editor_Imagick
[1] => FooGallery_Thumb_Image_Editor_GD
)
PHP Open SSL : Loaded
PHP HTTP Wrapper : Found
PHP HTTPS Wrapper : Found
PHP Config[allow_url_fopen] : 1
PHP Config[allow_url_include] :
Features Active : Array
(
[0] => foogallery-custom-css
[1] => foogallery-import-export
)
Gallery Templates : Array
(
[0] => default
[1] => image-viewer
[2] => justified
[3] => masonry
[4] => simple_portfolio
[5] => thumbnail
[6] => carousel
)
Lightboxes : Array
(
[foogallery] => FooGallery Lightbox
[foobox] => FooBox
)
Settings : Array
(
[gallery_template] => default
[gallery_permalinks_enabled] =>
[gallery_permalink] => gallery
[lightbox] => foogallery
[thumb_jpeg_quality] => 90
[gallery_sorting] =>
[datasource] => media_library
[advanced_attachment_modal] => on
[hide_editor_button] => on
[default_gallery_attachments] =>
[default_gallery_settings] => 0
[caption_title_source] => caption
[caption_desc_source] => desc
[gallery_creator_role] =>
[limit_gallery_selector_block_editor] =>
[album_creator_role] => inherit
[thumb_engine] => default
[default_crop_position] => center,center
[thumb_resize_upscale_small_color] => rgb(0,0,0)
[language_imageviewer_prev_text] => Prev
[language_imageviewer_next_text] => Next
[language_imageviewer_of_text] => of
[language_images_count_none_text] => No images
[language_images_count_single_text] => 1 image
[language_images_count_plural_text] => %s images
[pro_promo_disabled] => on
[custom_js] =>
[custom_css] =>
[default_retina_support] => Array
(
[2x] => false
[3x] => false
[4x] => false
)
)
Active Plugins : Array
(
[0] => foogallery/foogallery.php
[1] => bluehost-wordpress-plugin/bluehost-wordpress-plugin.php
[2] => foobox-image-lightbox/foobox-free.php
[3] => instawp-connect/instawp-connect.php
[4] => prevent-file-access/media-restriction.php
)
You must be logged in to reply to this topic.