volleyballmaniac

I’ve disabled open graph tags using
add_filter( ‘jetpack_enable_open_graph’, ‘__return_false’ );

And built my own tags.

Are you saying that JetPack is directly submitting the content IN ADDITION to the Open Graph Tags?

If so, is there any way to stop this using a hook or filter?

Thanks for the help wpfranner.

I’m going to chock this up to a networking failure on DH’s part.

But they fixed something and it seems to work now.

In any case, I left my mem limit at 256.

The memory limit increase did not fix the issue, but Dreamhost did something in server configs and fixed it. I tried to get details, but could not.

I’m still leaving this open for a few days, as the problem did arise out of the blue, so it may do so again.

Thanks wpfranner. I’ve upped it to 256M and also increased by xcache.size to 64M.

I’d go to 512M but in the article it said it may cause additional errors, so just to be safe I went with the amount they recommended.

I will be back to post the results after I get up in the morning (it’s 3am now).

Hi Ipstenu,

From memory, nothing changed. I hadn’t installed any new plugins. I was in the Admin Panel, grabbed a bite, came back 20 minutes later, I tried to get to a new part of the Admin Menu, and I got the waiting–>404 problem
–> Immediately tested another blog, same symptom.

Theme –>
Yes, I change the name of my theme (to force a reversion to default), and no change. I also tested the problem on 3 separate themes-sites, and same symptom.

htaccess + plugin
I tried reverting the htaccess, and renaming plugin/mu-plugin DIRs at same time. No joy.

Here’s what I had in htaccess:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

I got these errors (I commented them out using @)

Warning: call_user_func_array() expects parameter 1 to be a valid callback, function 'redirect_to_mapped_domain' not found or invalid function name in /home/CENSORED/main/wp-includes/plugin.php on line 406

Warning: Cannot modify header information - headers already sent by (output started at /home/CENSORED/main/wp-includes/plugin.php:406) in /home/CENSORED/main/wp-includes/pluggable.php on line 875

Result is a blank screen and this in error log:

[Wed Sep 04 16:09:19 2013] [error] [client CENSORED] Premature end of script headers: index.php
[Wed Sep 04 16:13:49 2013] [error] [client CENSORED] Premature end of script headers: wp-login.php, referer: https://CENSORED.com/wp-login.php

My wp-config
For security I keep it outside the web dir (one dir above), but I tried moving it back and no joy.

here’s what /home/username/web/wp-config.php:

/** Absolute path to the WordPress directory. */
if ( !defined('ABSPATH') )
    define('ABSPATH', dirname(__FILE__) . '/');

/** Location of your WordPress configuration. */
require_once(ABSPATH . '../wp-config.php');

here’s what /home/username/wp-config.php looks like (censored of personal info:

<?php define('WP_CACHE', true);  //

// ** MySQL settings ** //
define('DB_NAME', 'CENSORED');    // The name of the database
define('DB_USER', 'CENSORED');     // Your MySQL username
define('DB_PASSWORD', 'CENSORED'); // ...and password
define('DB_HOST', 'CENSORED');    // 99% chance you won't need to change this value
define('DB_CHARSET', 'utf8');
define('DB_COLLATE', '');
define('VHOST', 'yes');
define('WP_ALLOW_MULTISITE', true);
define('WP_POST_REVISIONS', false);
$base = '/';

// define('DOMAIN_CURRENT_SITE', 'yourdomain.tld');     //commmented out for now b/c interfereing with Multisite plugin
define('PATH_CURRENT_SITE', '/');
define('BLOGID_CURRENT_SITE', '1');

// double check $base
if( $base == 'BASE' )
	die( 'Problem in wp-config.php - $base is set to BASE when it should be the path like "/" or "/blogs/"! Please fix it!' );
// You can have multiple installations in one database if you give each a unique prefix
$table_prefix  = 'CENSORED';   // Only numbers, letters, and underscores please!

// Change this to localize WordPress.  A corresponding MO file for the
// chosen language must be installed to wp-content/languages.
// For example, install de.mo to wp-content/languages and set WPLANG to 'de'
// to enable German language support.
define ('WPLANG', '');

define( "WP_USE_MULTIPLE_DB", false );
define(ENABLE_CACHE, true);  // Enable the WordPress Object Cache:
define('SECRET_KEY', 'CENSORED');
define('SECRET_SALT', 'CENSORED');
define( 'LOGGED_IN_KEY', 'CENSORED' );
define( 'LOGGED_IN_SALT', 'CENSORED' );
define( 'AUTH_KEY', 'CENSORED' );
define( 'SECURE_AUTH_KEY', 'CENSORED' );
define( 'SECURE_AUTH_SALT', CENSORED' );
define('NONCE_KEY',       'CENSORED');
define( 'NONCE_SALT', 'CENSORED' );
define( 'AUTH_SALT', 'CENSORED' );
define( 'SUNRISE', 'on' );
define('SAVEQUERIES', true); // works with Debug Queries plugin

// ========================DONT EDIT BELOW HERE========================//
/* That's all, stop editing! Happy blogging. */

define('ABSPATH', dirname(__FILE__).'/');

// Fixes a WP version 3.5 release issue, where media uploader not working in Chrome
define('CONCATENATE_SCRIPTS', false );

require_once(ABSPATH.'wp-settings.php');

Added Note:
Had the issue 4 days ago, DH tech told me to up my VPS RAM, I did, but the machine broke while upping (separate issue), so they moved me to a new machine 2 days ago. Was able to access Admin Panel for a few hours after they moved me (thought it was fixed). Then suddenly – again – it stopped working on the NEW machine.

– The problem seems to occur suddenly, and without any software/plugin changes on my part.

Hi wpfranner, thanks for the response.

I had upped my php.ini, here’s a cut-paste of it:

;;; DreamHost-generated php.ini for PHP 54

allow_call_time_pass_reference = 0
asp_tags = 0
date.timezone = "America/Los_Angeles"
display_errors = 1
engine = 1
error_reporting = E_ALL & ~E_NOTICE
expose_php = 0
include_path = ".:/usr/local/lib/php:/usr/local/php5/lib/pear"
magic_quotes_gpc = 0
mail.add_x_header = 1
memory_limit = "90M"
output_buffering = 0
post_max_size = "7M"
realpath_cache_size = "128k"
realpath_cache_ttl = 300
register_argc_argv = 0
register_globals = 0
register_long_arrays = 0
safe_mode = 0
session.bug_compat_42 = 0
session.gc_divisor = 1000
session.hash_bits_per_character = 6
session.save_path = "/tmp"
short_open_tag = 1
suhosin.cookie.encrypt = 0
suhosin.session.encrypt = 0
suhosin.upload.disallow_elf = 0
upload_max_filesize = "7M"
xcache.size = "16M"

EDIT: I AM getting end of premature end of script headers. I’ll need to look into this (sorry I had looked in the wrong log folder).

Also, I had disabled the plugins my renaming their DIRs temporarily (XXplugins/), (XXmu-plugins/)

Any other ideas?

Hi Daniel,

I apologize for any of your time being wasted.

I discovered my problem. I have a wonky multisite setup in that I have multiple networks under one install (legacy issue).

The workaround is if I go to blog 1 (the big daddy), I can make a change there and it affects all other networks settings.

However, I cannot make any changes from the other networks.

Thanks for your time, and my apologies if you felt any was wasted.

Cheers

Sorry for the delay, I did not get an email from WP notifying me of a reply.

After I hit the “Save Changes” button, I get the yellow box message at the top saying “Settings saved.”.

However, no changes show in the Settings fields.

Something Interesting
Oh and I checked the DB, for the plugin row “login-security-solutions-option”, and I can see the changes in the DB. However, the Plugin settings page fields still reflect the default settings.

So the DB is updating, but the Settings fields are not. I guess my next step is to start deactivating plugins, but just wondering if you had any other ideas?

Hi Daniel,

My apologies for not being clear. I have been editing the Settings via the Network Admin account.

/wp-admin/network/settings.php?page=login-security-solution

However when I click “Save Changes”, they do not take, and upon refresh, it still shows the default settings.

Could you perhaps do a Test save of your settings using WP 3.6?

@curtiss
Yes! Whatever magic you did there seemed to work. I can now access using the deprecated file path (site.com/files/….), and also access with other URI’s (like Cloudfront).

I call it ‘magic’ because I can’t explain it, but it works.

Add yourself to the “owed beers when in Vegas” List (see my first post).

@andrea
Just a heads up that the paparazzi often don Polar Bear costumes up north. So that innocent-looking bear pooping in your backyard, might actually be a photog from TechCrunch.

@ipstenu
Yeah, I was actually going to do it, until Curtiss’ post. Thanks for your help though young lady (yes, I read your About page).

Sidenote: Accidental Discovery of Anti-Hotlinking Technique
So for anyone not wanting to use CDN Origin Pull, it would appear that the code I had in my htaccess, was an awesome, amazingly-easy way to block Hotlinking:
RewriteRule ^(.*/)?files/(.*) wp-includes/ms-files.php?file=$2 [L]
*I still have no idea where I got it from

It won’t work for my needs, however, because I am using CDN Origin Pull.

TLDR Summary (if you found this thread having CDN issues)
– This code below (in htaccess) seems to block all URI’s except the Blog that uploaded the file:
RewriteRule ^(.*/)?files/(.*) wp-includes/ms-files.php?file=$2 [L

– Curtiss Grymala supplied an alternative to it, which seems to allow other URI’s to access your the Uploaded Files of a blog:
RewriteRule ^([_0-9a-zA-Z-]+/)?files/(.+) wp-includes/ms-files.php?file=$2 [L]

– Utilize Curtiss’ code if you are trying to get a CDN Origin Pull working.

Followup:

It would appear that:
RewriteRule ^(.*/)?files/(.*) wp-includes/ms-files.php?file=$2 [L]

…….is a necessary entry to have in htaccess if you want the Blog to access it’s uploaded image (using its URI).

Without it, Deprecated URL-path breaks on regular blog, https://site.com/files/2010……..

However, Regular URL-path still works though, https://site.com/wp-content/blogs.dir/23/files/2010……..

So my choices:
1. Delete entry, and use Cloudfront to serve Static content

2. Leave htaccess entry, and not have Cloudfront

I’m going with Choice #1, however I realize that this is not a wholly proper solution to the issue.

SUCCESS!!

Okay, this is embarrassing…………Remember this:

I’ve tried manually removing each item in there piece-by-piece, but still no JOY.

Well the reason that didn’t work is because I actually had the offending item in htacess in 2 different places.

Here it is:
RewriteRule ^(.*/)?files/(.*) wp-includes/ms-files.php?file=$2 [L]

Using my not-so-powerful memory as a reference (also the notes in htaccess), I recall that this was a “security” entry that was suggested in the WP README.txt when I first installed MU many moons ago.

(could be wrong though).

————————————————-

Besides the fact that my files can now be hotlinked……
Anyone have an idea of the repercussions of removing this line from htaccess?

————————————————

BTW, Andrea & Ipstenu my offer still stands: if either of you are ever in Vegas, PM me, and beers are on me. (sorry doesn’t include slots money, haha).

Hi Ipstenu,

Nice to bump into another WebCeleb (2 in one day, gee I feel special).

Can you turn it off to test?

Are you referring to Cloudfront? (my install is not currently linked)

If not, please let me know what I should turn off.

Just a note, that I don’t currently have any anti-hotlinking code in htaccess. (never worked on my install anyway).

If you’d like I can PM you a copy of my htaccess to see if it’s something in there causing it. I’ve tried manually removing each item in there piece-by-piece, but still no JOY.

Yay, Andrea Rennick responded to my posting!

Sorry, I get all weird around Web Celebrities ??

As you instructed, I did a desktop search (of a downloaded copy of my install folder), for every instance of “files”.

The only results returned were those in the blogs.dir\BLOG_ID\files.

I also did a manual inspection, and could not find any other folders named “files”.

———————————————————–

Just a hunch, but could this “block unless uploading Blog is in Base URL” actually be a feature that was put in to block Hotlinking?

It actually makes a lot of sense (until you try to use Cloudfront Origin Pull).

TROUBLESHOOTING UPDATE

Still not working.

I’ve tried the following using my CloudFront URL:

I traced the image down the folder path to find out where it breaks (it appears to be breaking at /files/ folder).

Note that working examples below may break soon, as I might remove that test img, but please be assured that they did work when I tested.

Works
https://d2ay33tzsh7115.cloudfront.net/wp-content/blogs.dir/body_bg.jpg

Works
https://d2ay33tzsh7115.cloudfront.net/wp-content/blogs.dir/9/body_bg.jpg

Broken
https://d2ay33tzsh7115.cloudfront.net/wp-content/blogs.dir/9/files/body_bg.jpg

So since it is breaking at the /files/ folder, it might have something to do with these files:
– wp-admin\includes\ms.php
– wp-includes\includes\ms-default-constants.php

—————————————————————-

Additionally, I’ve also tried CHMOD the permissions of the files/ folder (and all subfoders & files) to 777, but that had no effect.