Saving images w/custom field goes to 404 page

Hi kgosser

That does sound very strange. Does it save if you try something other than the URL in the field?
Do you have a different setup on the localhost, in terms of different plugins or theme active etc?

Ah, good suggestion: the form does save properly if it’s something other than a URL. I tried saving with “test” in the text input and it worked.

To your second question, there is only one difference in the set up: I have the Smooth plugin active on my localhost. https://uninuni.com/wordpress-plugin-nextgen-smooth-gallery/ — it is not even uploaded let alone activated on production.

With this new insight of a non-URL value saving properly, I’m still unsure what to do next.

For what it’s worth, I checked the response/request headers in Web Inspector, and it’s virtually identical between local/prod instances.

Ok, after more testing: it definitely does that 404 error thing when the value in the text input has an “https://” in it. If I take that off and just have “www….” it saves properly.

Can definitely work around this by manually adding https:// in the template and just save all the custom field values without it. Not sure if it’s a bug in your plugin, but it’s worth looking at.

FWIW, I’m still confused why it would do that on production but not localhost. Perhaps different versions of Apache or PHP on the shared host? (I think this client is some random 2nd-tier shared host, not Media Temple or anything.)

I cannot reproduce it at all, and I’ve never had someone else mention they can’t save URLs (and lots of people seem to use this plugin for that).
I will try re-produce this on a couple different setups when I’m back in the office next week, and see if I can isolate something. But for now, hardcoding the ‘https://’ into the template seems like the best approach.

Thanks for the feedback, I hope the plugin is useful to you ??

You bet. It served my purpose exactly. Thanks for the plugin. You can mark this as resolved for now — the template modification will work just fine.

P.S. Chances are it has something to do more at the php/apache level, as I’m 99% positive the codebase is exactly the same between my local and prod instances. So probably not much to stress out about. However, it is odd that it does this behavior only for your plugin, not any other type of text input field within WordPress.