nicollb

I think I have it fixed — well sort of. I found 2 plugins that were updated in the last 2 days; I had to move them out of the plugin directory; then I updated the network, and I can get back in to the site.

Now, to figure out which of the 2 is the problem.

I thought of the theme function idea; but several working sites use the same child theme; The comparison of a working user_roles with the non-working one didn’t turn up anything thing other than a couple of rights for plugins present in a working site, but not present in the broken site.

Interesting — if I clear my cookies in the browser, I can get the wp-login.php page; but when I try to login, I get the error message; And, thereafter I get the error message and no login page;

I’ll try option 2 — I tried granting a new user access and that failed to let me in.

Is there somewhere I can uncover the meaning of these cryptic codes (s:17, b:1, etc)?

Jeremy:
The workaround adding the action (added to my functions.php) makes it possible to edit new posts; I tried adding a new recipe. That doesn’t work, but at least I can add other posts, and display already recreated recipes.

Thanks

Same issue here… hope the conflict can be resolved soon.

Update — fa-green worked like a charm!

count this as resolved.

Laurenng: It took a minute to figure out what I meant, but I think I can explain:

Under the CDN tab (WP-Supercache settings) there is a place to put the Include Directories: I had forgotten to add “files” to the list of included directories.

My setting now reads: wp-content,wp-includes,files

When you have a multisite set up, at least on mine, the url (path) for things like images, etc, is not …/wp-content/… , it is sitename/files/…

Example: https://cdn1.famvin.org/en/files/2012/09/vinFormation-ad-smaller2.png

if this were the top-level is would read: https://cdn1.famvin.org/wp-content/uploads/2012/09/vinFormation-ad-smaller2.png (that image doesn’t exist at this level on my network.)

Thanks for the help. I think I consider this Resolved.

I think I got it!

instead of:
RewriteRule ^/site/wp-content/uploads/(.*)$ /site/files/$1

I used:
RewriteRule ^site/wp-content/uploads/(.*)$ /site/files/$1

(I did put a RewriteCond in front of it: RewriteCond ${HTTP_HOST} ^domain.org$)

I use WP-Supercache; I have cleared the cache(s);

It simply does not rewrite the URL. It returns the url that was entered. And, now I am back to the Server Error 500 for the files.

The other rules (domain1 –> domain2) are working. So, I’ve entered something incorrectly, I’m sure.

It feels like one step forward, 2 steps back, right now. I’ll back off; check everything and go through one step at a time again.

Ipstenu — Thanks.

I put those rules in place.

The redirects for Vincentiana work beautifully — and much easier to read.

At this moment, I no longer get the 500 Server Error, but I don’t seem to get /site/wp-content/uploads/blahblahblah rewritten at /site/files/blahblahblah

I’ll study it further

sorry I got into a hurry in the original post and got this off on the wrong foot.

Breaking WordPress. I had some very inelegant rules to point to a new location for a 3 app (a Greenstone Install that changed domains. With them in place, I got the server error for the /wp-content/uploads/ path. With them removed I get a 404, which, while not perfect, is far better than a Server Error 500.

Removed rules: (domain1.org is the WordPress domain that this whole thread deals with)

# BEGIN Vincentiana
RewriteEngine On
RewriteCond %{HTTP_HOST} ^domain1.org$ [OR]
RewriteCond %{HTTP_HOST} ^www.domain1.org$
RewriteRule ^cgi\-bin\/library$ "http\:\/\/domain2\.org\/vincentiana\/cgi\-bin\/library\.cgi$1" [R=301,L]
RewriteCond %{HTTP_HOST} ^domain1.org$ [OR]
RewriteCond %{HTTP_HOST} ^www.domain1.org$
RewriteRule ^gsdl\/collect\/?(.*)$ "http\:\/\/domain2\.org\/vincentiana\/collect\/$1" [R=301,L]
RewriteCond %{HTTP_HOST} ^domain1.org$ [OR]
RewriteCond %{HTTP_HOST} ^www.domain1.org$
RewriteRule ^gsdl\/cgi-bin\/?(.*)$ "http\:\/\/domain2\.org\/vincentiana\/cgi-bin\/$1" [R=301,L]
RewriteCond %{HTTP_HOST} ^domain1.org$ [OR]
RewriteCond %{HTTP_HOST} ^www.domain1.org$
RewriteRule ^gsdl\/$ "http\:\/\/domain2\.org\/vincentiana\/" [R=301,L]
RewriteCond %{HTTP_HOST} ^domain1.org$ [OR]
RewriteCond %{HTTP_HOST} ^www.domain1.org$
RewriteRule ^vincentiana\/$ "http\:\/\/domain2\.org\/vincentiana\/" [R=301,L]

nope — always had yyyy/mm/file.jpg as the path. the only alteration would be /wp-content/uploads/ to /files/

I removed some other rules (non-WP) from the .htaccess and now I don’t necessarily rewrite the path correctly, but I don’t get the server error.

I don’t think that is the problem — it was always yyyy/mm — it’s just that it was /wp-content/uploads/ instead of /files/

I can try the RewriteRule —

the .htaccess is interesting because it contains rules for the WordPress multisite, and several Mediawiki sites that live inside the directory structure, and some redirects because of another major move. One of those rules probably is the problem, since I get a 404 on another multisite install on the same server.

(How’s that for beginning to answer my own question?)

Made a backup copy of my .htaccess and started deleting rules. Redirect seems to be healed. Now I just have to figure out how to do that needed redirect without breaking WordPress.

At least I don’t get the 500 Error for this anymore.

Thanks.

Patrick — thanks. I did the search and replace earlier to get the internal links straightened out. It is a wonderfully useful tool.

But, the server error still occurs when an external site hits an old, incorrectly formatted URL. I would think that there should be a way to avoid the 500 Server Errors. a 404 would be a better solution, IMHO.