Forum Replies Created

Viewing 7 replies - 1 through 7 (of 7 total)
  • Hi occreative–I had a similar issue on a SiteGround GrowBig account (which is structurally pretty much the same as GoGeek in this regard). I did indeed add an individual auto_prepend_file addition for the path to each one of my four sites’ paths to wordfence_waf.php, by repeating the process and just changing the sitename in the path, since I organize all of mine in the same way (under the main folder for my account, rather than as sub-directories inside my main site’s public_html folder). It seems to have worked–the firewall changed to “optimized” in the Wordfence interface for each site after doing this.

    Thread Starter llparker

    (@llparker)

    Just to update my observations: this is happening in the “Content” blocks, and it seems like the replicated content shows up when the “Edit Page” window opens. Each time it is either opened by clicking “Edit Page” or saved to return to the “edit” back end, it makes another replicate copy of the content in question. And indeed, it is bringing it back in even when it has been deleted and resaved.

    Thread Starter llparker

    (@llparker)

    Okay–so, I resolved the problem again–this time I deactivated and then deleted the Sucuri plugin and it started working again.

    I do not know why for sure… except that possibly it had something to do with the combination of the Easy WP SMTP plugin we have on our multisite and the attempts that Sucuri makes to send “Media file added” emails to the blog’s owner. We did not have anything in each individual blog’s Easy WP SMTP configuration, only the main network site (which did work), so there were errors in the PHP log for Sucuri trying to email blog owners according to their WP account emails and failing.

    I may at some point test out setting up each blog with the Easy WP SMTP config details, and see if that enables them to work together and allow image uploads. I like Sucuri but it doesn’t seem essential for us–it mostly was useful as a gauge of just how much bruteforce password guessing goes on at our site–A LOT. But, fingers crossed, no break-ins yet anyway.

    Thread Starter llparker

    (@llparker)

    AAAAARRRGGHH nevermind. It worked for a day, and now doesn’t work anymore. And the cache delete trick did not work again.

    Back to the drawing board…

    ZOMG eberlyjm, thank you so much for posting your apparent solution. We had the same problem, where the “Site #1” of our multisite install could upload and crunch image files just fine, but all the sub-sites (in subdomain structure) were failing the ImageMagick crunching/resizing etc. The files would load onto the server in their appropriate folder, but we would get “HTTP error” and they would not process properly for the media library.

    I went into our WP Super Cache settings, clicked “Delete cache from all blogs,” and voila–after weeks of Google rabbit-holing to no avail, the problem is solved!!

    Thread Starter llparker

    (@llparker)

    Okay–I just solved the problem, after finding this thread with the potential solution in comment #11: https://wordpress.org/support/topic/media-upload-error-wordpress-40?replies=12

    We use WP Super Cache, and I went into the settings and clicked “Delete cache from all blogs” and now it works again.

    I’m still not sure why the cache was blocking image crunching, and also, simply disabling WP Super Cache was not sufficient to solve the problem (because I tried disabling all plugins to no avail), but there we go.

    To future admins with this problem–try deleting the cache from all blogs on your WP Super Cache. 🙂

    Thread Starter llparker

    (@llparker)

    Thanks for replying–we are not running mod_security, we have an ip-tables firewall (which I think serves a similar purpose…our server is set up on Linode and I just followed all the linode documentation for the LAMP setup, which includes securing via ip-tables), but that hasn’t changed between when it used to work and when it stopped working.

    I checked that we have ImageMagick installed, and we do (and, the main site working implies that in principle ImageMagick is functional).

    Could it be a rewrite rule problem with how ImageMagick figures out where the files are for crunching? That’s the only thing I can think of, like maybe it’s having trouble finding the initially uploaded files? But if so, how would I find what is causing that in the first place? 🙁

Viewing 7 replies - 1 through 7 (of 7 total)