robhindle

I hear what you say and understand why you don’t auto-delete the JPGs by default but I’m still inclined to save resources on the server. You could add a delete option in the “extra features” section (unselected by default and with appropriate warnings).

My host caps both disk space and inodes (effectively number of files). WordPress is problematic anyway because it makes copies of each image in multiple dimensions, storing duplicates of all my JPGs as WebP gobbles yet more resources.

The conversion operation (at 75%) worked well in that it didn’t take long and the new files were close to half the size of the originals. Google speed test went from 94% to 98% The problem is that I’m now using near 50% more storage because I have images in both JPG and WebP formats.

If I were to download a copy of the /uploads/ folder to my PC (and a keep a backup!) then in the scenario you identify, the plugin being removed, I could copy the uploads folder back.

Mine is a “hobby” site, I guess if it were commercial I may be more cautious. If I were building from scratch now I’d upload images as WebP anyway as recent versions of Chrome, Safari, Firefox, Edge, and Opera all handle WebP and I don’t think it essential to cater for the laggards.

As for AVIF, my understanding is that it’s a little less widely supported and doesn’t make files much smaller than WebP (although quality is better so you can turn up the compression without losing quality) so, at least for my hobby site WebP can save me a load of disk – if I delete the jpgs.

Same problem using backup codes, switched to email verification, now OK

Possibly a typo/autocorrect for awesome as it was 5 star

Same error, this was when wordpress upgraded to version 5.3

Switching PHP from v7.1 to v5.6 fixed the problem, don’t know why but that might help anyone investigating and otherwise may be OK as a temporary fix

Old site was still available so I pulled down a DB dump.
ENGINE=MyISAM DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

Is it possible that you have hardcoded these links in your templates? We search and replace for database only, but not the files.

Those links were in posts. Could the conversion have had a problem because I was shifting to a different domain and at the same time from a subdirectory to base level?
I may need to shift another WP site to SG from the same place so I’ll try to get better diagnostics if I have any problems next time .

It’s essential to take a backup first and check the site carefully after the move. The question mark issue was just one of the more obvious problems and one I’d like to think the authors of Migrator might be able to diagnose and fix.

What I did, changing domain name and directory, may have made the migration harder and so while Migrator helped, it didn’t deliver a complete solution.

I had other problems including embedded links like https://oldsiteexample.com/file-external-to-wordpress in test mode those appeared to work because oldsiteexample.com was still there but going live I needed to do another database fix.

Fixing the shifted web site might call for a significant amount of messing with the database, the example SQL code fragment is only a start and has the problem that it also removes question marks you want. It was intended as an example, not a fix. With a small site & small number of exceptions that’s OK you can edit the affected pages to put them back. In my case I had a load of web links with parameters like example.php?id=123, that needed special treatment. (Including search and replace only those ?s with a space before or after but that too is a simplification, doesn’t fix everything.)

I don’t regard these other issues as a problem with Migrator, there are too many potential site specific problems for a tool like this to anticipate and cater for all eventualities. Migrator might deliver a 100% success in many cases but as with any significant web site change you should backup, test, and be ready to revert to the original or be ready to implement some fixes. Post advance “down-time” warnings, choose a quiet time for website activity and suspend changes until the move has been successfully completed and tested. One of my sites only needed the question mark fix and a few manual edits, the other was more complicated.

I’m glad I found Migrator, it was so much easier than any other WordPress migration approach I’ve tried in the past and I had to undertake similar post-move fixes then too. It’s so easy to use that it’s worth a try. It only took me a few minutes to move a site (but I do have fast internet). If the preview test mode finds any problems and you’re not into debugging and fixing then revert and try a different approach. (Don’t try messing with the SQL database if you’re net experienced, it could end in tears.)

I’ve just got the same problem. Google search for “HTTP Error When Uploading Images” finds loads too with loads of different suggested fixes. My own investigations turn up some factors I’ve not yet seen referenced elsewhere.

There’s a common suggestion that it’s related to memory or file type. When I FTP to the relevant directory the images ARE there and I intentionally tried uploading a small image (6K jpg), seems very unlikely that would cause a memory issue with subsequent processing.

The image is listed in the media library but is displayed as a grey box (the wp default image) and won’t embed in a page. When I click that “Attachment details” show the correct path”, when I then click “view attachment page” no image is shown BUT this text “Published September 23, 2017 at × in snow” The x is a hypertext link and clicking it shows the full-size image.
Examining the HTML of that page shows another image tag linking to the original jpg but with html height and width elements both set to 1px.

It seems that normally wordpress creates further copies of an uploaded image with different dimensions. That has not happened, the uploaded image is only there at original size.

Looking at the server error logs I see the below which might cast some light on what’s going wrong to someone with a better understanding of the wordpress code:

[Sat Sep 23 16:04:32.736522 2017] [proxy_fcgi:error] [pid 27185:tid 140636833384192] (104)Connection reset by peer: [client 80.0.10.2:49601] AH01075: Error dispatching request to :, referer: https://pdmhs.co.uk/wp-admin/upload.php

Another possible clue is that when I click EDIT I get this error after a few seconds “The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.” I can be certain that the server is available and well resourced so could this be indicating something like a nested loop that’s built up a demand for excessive CPU or RAM?
The error log at that point gives:

[Sat Sep 23 16:14:56.993005 2017] [proxy_fcgi:error] [pid 27188:tid 140636883740416] [client 80.0.10.2:49723] AH01071: Got error ‘PHP message: PHP Warning: Illegal string offset ‘width’ in /var/www/vhosts/pdmhs.co.uk/httpdocs/wp-content/themes/twentyeleven/image.php on line 34\nPHP message: PHP Warning: Illegal string offset ‘height’ in /var/www/vhosts/pdmhs.co.uk/httpdocs/wp-content/themes/twentyeleven/image.php on line 35\n’, referer: https://pdmhs.co.uk/wp-admin/upload.php?item=2482

Looks to my untutored eye as if something is wrong in image.php and/or upload.php

All plugins are up to date. WordPress 4.8.2 running Twenty Eleven PHP vsn is 7.1.9

I don’t know how long the server’s been on 7.1.9 (released 31 Aug) but it’s set to upgrade to latest so I reverted to prior vsn: 7.0.23 . PROBLEM SOLVED! for me at least, whether that helps anyone track down a similar problem but running different versions or wordpress & PHP, I don’t know.

Fixed it myself but in an unsatisfactory manner. I would have expected that deleting the plug-in which says something like “and associated data” would remove all traces including wp-content/uploads/dlm_uploads and the WP DB entries.
I found the relevant entries in the WP database and deleted them. Messing with the DB is high risk, not recommended.