I find the excuse that the bug is just for your small “edge case” as an explanation for why it won’t be fixed annoying.
I have found “edge cases” to actually mean we don’t want to fix it. Often the issue isn’t needing some special code to deal with an “edge case” it is the coding was done poorly and breaks in many different “edge cases.” It isn’t that those edge cases need to be coded for. It is that the code should have been written in a robust way that didn’t break for lots of “edge cases” but the excuse given for not fixing the fundamental coding fragility is the bugs found are just “edge cases.”
There are real instances where “edge cases” is a justifiable excuse. For example, adding in special code to deal with some odd category of users that just isn’t worth the cost.
But I just am so tired of fragile coding being excused as if breaking in lots of “edge cases” is perfectly acceptable when the only reason it fails is because the code is fragile instead of being built in a robust way to begin with. The issue isn’t that you have some special edge case that you want special coding for the issue is the code was written in an unnecessarily fragile way that makes it not work unless you follow a list of acceptable use cases.
Sadly one of the hassles in managing your own WordPress blog is dealing with people that use your blog to serve spam content. These hacks can insert spam links into your pages and posts or create spam directories that are completely their own content on your domain.
There are many issues to deal with in re-establishing control of your server; but that isn’t the scope of this post.
This is just a tips if you are troubleshooting to try and determine what is going on. Often your server has been hacked to allow uploaded php pages to be added or for WordPress php files to be edited.
One way to track down if the files have been changed or new ones added is to compare the WordPress files on your server to the current files for a fresh WordPress install. This assumes your blog is using the current version, which hopefully it is because on the big improvement WordPress made is to make those updates automatic. That greatly reduces the chance to have WordPress be the vector to infecting your server. If you were using a older version then just compare to the field for that version from the WordPress server.
If you don’t have a current backup I would make a backup before I tried this. Obviously, don’t make any deletions or changes to your server unless you understand what you are doing. You can create big problems for yourself.
You can use the diff command to view the difference between WordPress on your sever and the fresh install from WordPress. I install the new WordPress in a new directory outside public_html. At the cli on a Ubuntu/Linux server:
My WordPress network site stopped displaying uploaded images. I finally found something that works, though it is a lame “solution” in my opinion.
I found this advice and it worked for me. Insert the following in wp-includes/ms-files.php
adding ob_clean() before the readfile in ms-files.php
So you end up with:
// If we made it this far, just serve the file
readfile( $file );
Caching seemed to make the images “disappear” slowly (they didn’t all go at once and using different browsers they “disappeared” at different times). So when I fixed it they “reappeared” at different times (it seemed like cached ones stayed disappeared for awhile).
The advice mentions the image files being seen as “corrupted.” The files seem unlikely to actually be “corrupt” because these are images that worked for years and then all of a sudden every image for the sites “disappeared” (wouldn’t be displayed). I suppose it is possible the are corrupt in some detailed way and some update no longer allowed some previous “lax” checking to allow the non-compliant files but it seems more likely that some of thing has gone wrong (but somehow ob_clean takes care of it).
I ran into a problem when I added a second WordPress blog network to my server. I had the Curious Cat Blog Network up and running for quite some time with sub-domains for each individual blog in the network. WordPress automatically dealt with routing the sub-domains and having urls work. It really is very nice how easy it is to create a new blog and have everything up and running – just add it in WordPress, no need to touch the server directly. Blog networks are a new feature in WordPress 3.0 (I think) which are very nice. I would imagine it builds on effort with Wordpres MU but it is just part of regular WordPress now.
When I added the second blog network however the new faux-sub-domain that should be used affordable-funeral.moneyite.com would instead be redirected to curiouscatnetwork.com and since no such domain existed on curiouscatnetwork.com it gave the standard error message WordPress generates for the case where a sub-domain url is not recognized.
The main domain for the new site was working: moneyite.com. I tried searching around for some solutions to this problem online but couldn’t find any. I am not sure if multiple wordpress blog networks should work on the same server without any special needs. But it wouldn’t for me. I found a solution that did work so I will share what worked for me.