Tadamhicks

esmi, thank you so much.

I had been fiddling with that on my host a couple days ago for a different site.

I did find out. It was, after all was said and done, a PHP memory allocation issue with the host. I tried fixes in .htaccess, php.ini and in the config files to no avail. Host was 1and1.

I was exasperated after way too many hours spent trying to fix, so I put my efforts to selling my client on a new host instead. Signed up with Name.com, transferred the install and, voila, everything clicked. Photos load fast and completely.

If you’re using a budget host I would consider that they’re simply limiting the PHP memory allocation.

Not sure how I breached the rules… weird, but anyway.

WPRanger, I think I’ve determined it’s an issue with the host. Don’t know why I didn’t think of this in the first place…

I have XAMPP locally for developing, so I revved it up and the questionable .jpgs uploaded just fine.

I will be moving the WordPress install away from 1and1. I don’t know what it is about the questionable .jpgs, maybe the metadata is so robust that it is utilizing too much memory on the server.

I’m not going to close this yet because it’s really just an experiment to see if switching hosts is the fix. I was wanting to move hosts anyway, so this will be a good test.

In the table I notice also that immediately after uploading there is no _wp_attachment_metadata for the offending .jpg files and if I try to edit them, which results in the thread title, there is an _edit_lock generated in association with the offending .jpgs.

I’m not sure if you’re just trolling, but…

I apologize for the lack of a common linguistic convention (“function to populate a table”) that would allow us to speak on the level.

The point is that the metadata from these questionable .jpgs is not making it’s way into the table, but it is from other .jpgs.

My question is: how do I troubleshoot and find the source of error here?

My guess would be that there is a XMP format that ‘the function’ is not written to take into account. I need to find this function and adjust it, but I’m not sure where or how at the moment. A few minutes research may guide me to it, or the assistance of an “expert” in this forum.

I don’t want to debate the php.ini location. I really want to solve my issue.

So, I went into look at the SQL tables and noticed that the .jpgs in question do not have _wp_attachment_metadata entries at all. I found where others have had issues with absolute vs. relative pathing for metadata entry creation, but it appears that the database isn’t even reading the metadata in my .jpgs.

And Pioneer Valley Web Design,

php.ini may go in root if that’s where the site is located…but on a shared server it needs to go in wp-admin. To test that out put it in wp-admin and you’ll see the file upload limits change in the WP uploader. If it’s in root then it won’t reflect the thresholds set by the scripts in php.ini.

Some more clues that might help. I notice that when the .jpgs in question were first sent to me via e-mail that no thumbnails show in the e-mail attachments when looking in Chrome. I think it may be a metadata type of issue where the WordPress software doesn’t recognize the data structure from the cameras used. Firefox will display the thumbnails, though.

Any thoughts on fixing either the metadata of the pictures or, preferably, fixing the WP_METADATA in the database to be more flexible? I’m MySQL savvy to a point, but this is something I need help with.

Just tried another at 742kb. So, not very big.

I threw a php.ini in wp-admin with this code:

memory_limit = 100M
upload_max_filesize = 100M
post_max_size = 100M
file_uploads = On

I’m at a serious loss.

I used gedit, which doesn’t add a BOM on it’s own.

One .jpg I tried with is only 1MB. Another is 3.5MB.