joe.toomey

Fairly certain this is a visual composer bug. Not sure if it has been fixed yet or not.

I did find a workaround that will keep me above water until a fix exists. The problem appears to be in the way visual composer parses the content of the raw html component. It’s obviously base-64 encoded text.

I did a diff of the raw content of a working restored copy of a page (before it got corrupted) and the raw content of a corrupted page after it was edited. The change appears to be that they expect no whitespace in the [vc_raw_html] section at all before they parse the base-64 encoded content, but somehow carriage returns started getting inserted into the sections, which busts the parsing of the content and things fall over.

My workaround (which worked for me, YMMV) was to toggle to the text mode of the classic editor so I could see all the visual composer shortcodes, find every [vc_raw_html] section and remove any whitespace in it, so it looks like this when you’re done:

[vc_raw_html]VGhpcyBpcyBteSBmYWtlIHRleHQhIQ==[/vc_raw_html]

It’s critical that the open and close tags appear on the same line as the base-64 encoded content.

After I made those edits to every raw html section on my page, I toggled back to backend editor mode and things looked normal again and work fine. If you edit and save again, you’ll need to apply the same workaround.

Hope it helps someone else. If you notice a fix for this, please update this topic so others can find out as well. Thanks!

I’ve added these troubleshooting steps to a serverfault answer I posted last week on this issue. I’d appreciate it if you could upvote both the question and the answer if this helped.

Thanks!
–Joe

https://serverfault.com/questions/609416/wordpress-site-has-repeated-php-out-of-memory-error-despite-increasing-php-memor/610805#610805

Glad to hear it, Tim.

If you know you are able to restore from your backup (i.e. you’ve tested your restore process and know that it works), then you should feel okay trying to prune from that table.

My guts says it should be okay to remove all the records (definitely do not drop the table). Like I said, if you can restore to a backup confidently, everything becomes a lot less stressful.

We had tens of thousands of 404s as well, and they appear to have been caused by botnet traffic. You can try to figure out the cause before cleaning up the DB by just looking at your DB backup’s SQL file in a text editor that can handle large files (for example, notepad++ on windows, TextWrangler on Mac, or just page through with less on linux).

Your “Allowed memory size exhausted” error is occurring at the same location mine was (wp-db:1941), which is inside wordpress’ get_results() function. get_results() is a utility function in wordpress that executes a query against the database and and returns the results in the format requested. Line 1941 is part of the code path when the caller requests that the query result be returned in an integer indexed array.

I can see from your error message that you also have PHP configured with 256MB of RAM. Not knowing more about your situation, I can’t say for certain if your issue is the same as mine or not. For example, how often do you encounter the out of memory error? If it’s very infrequent and seemingly random, you could have a memory leak somewhere in your theme/plugins that slowly exhausts all memory, eventually running out and reporting this error. If, like me, you find that php memory usage is stable and low until iThemes Security tries to do a backup, then you’re probably hitting the same error we’ve been discussing above.

The way that I went about troubleshooting the error after the normal fixes (increasing php memory and making sure that actually worked, confirming that my memory usage was stable and low over time) was to add some debugging log statements to wp-db.php so I could see what was happening when the error occurred. Here’s the code change I made to help narrow down the problem (be sure to make a backup of wp-db.php before trying this so you can easily restore your settings and in case you mess something up when editing the file:

function get_results( $query = null, $output = OBJECT ) {
		$this->func_call = "\$db->get_results(\"$query\", $output)";

		if ( $query )
			$this->query( $query );
		else
			return null;

		$new_array = array();
		if ( $output == OBJECT ) {
			// Return an integer-keyed array of row objects
			return $this->last_result;
		} elseif ( $output == OBJECT_K ) {
			// Return an array of row objects with keys from column 1
			// (Duplicates are discarded)
			foreach ( $this->last_result as $row ) {
				$var_by_ref = get_object_vars( $row );
				$key = array_shift( $var_by_ref );
				if ( ! isset( $new_array[ $key ] ) )
					$new_array[ $key ] = $row;
			}
			return $new_array;
		} elseif ( $output == ARRAY_A || $output == ARRAY_N ) {
			// Return an integer-keyed array of...
			if ( $this->last_result ) {
				$emited = false;
				foreach( (array) $this->last_result as $row ) {
					if ( $output == ARRAY_N ) {
						// ...integer-keyed row arrays
						if (!$emitted) {
						    error_log("Current Mem: " . memory_get_usage() . ", eak mem: " . memory_get_peak_usage());
							error_log($query);
							$emitted = true;
						}
						$new_array[] = array_values( get_object_vars( $row ) );
					} else {
						// ...column name-keyed row arrays
						$new_array[] = get_object_vars( $row );
					}
				}
			}
			return $new_array;
		} elseif ( strtoupper( $output ) === OBJECT ) {
			// Back compat for OBJECT being previously case insensitive.
			return $this->last_result;
		}
		return null;
	}

This is 6 lines of added code; the first declares the $emitted variable to keep track of whether we’ve already logged for this request, and then 5 lines of the if clause to actually log.

What this does is print out the current and peak memory consumed by php before we start reading the query results into memory, and also print out the query that was executed. The memory will give you an idea of if you have reasonable memory available before we start reading the results. If the available memory is close to your limit (within a few MB), then the problem is probably elsewhere and you don’t really have the available headroom to run a reasonable size query. If, like me, you have tons of free memory before the query is run, then look to see what the query is that runs right before you run out of memory (my log entries were all in php error log, but if yours are split across and iThemes log and the php error log, correlate between the two based on timestamps.) The query that was run immediately prior to the memory error is the one that blew you up.

In my case it was a SELECT * FROM wp_redirection_logs;. That table was blown up to a huge size b/c the Redirection plugin was misconfigured on my site to never expire log entries. From reading the iThemes security plugin’s code, it’s clear that the backup action does a SELECT * FROM query on every table in your DB that starts with the wp_ prefix (or other prefix if your site is configured to use a different prefix due to multi-site or something else.) Once you find what the query is, you can start to reason about the cause of your error, and perhaps prune unnecessary DB content to workaround the issue like I did.

I’d be happy to offer suggestions if you go through these steps and report back.

–Joe

I’m not sure if the iThemes Support people monitor all of these threads or not, but I have a question:

If I were to fix this bug, could I submit a patch to be incorporated into the plugin? Do you have a git repo where I could fork and submit a pull request, or alternatively, could I just post the source here?

(Note, I’m not going to write and test the code if it’s not going to be folded into the production plugin; I already “fixed” the site I was working on by reducing the size of a table that was unnecessarily large. But I do think this is something that should be fixed properly.)

I just dealt with this same issue. I imagine there may be some debate about whether this is a bug or not, and it’s true that you can typically resolve the problem by increasing the amount of memory allocated to php (first in your php.ini file, and perhaps also necessary to remove an apache RLimitMEM restriction if one is in place.)

I would argue that the root cause is the fact that the iThemes Security plugin (which is fantastic, by the way) assumes that a sql representation of the entire database can fit in memory in a php string. It does this in better-wp-security/modules/free/backup/class-itsec-backup.php in the function execute_backup(). In this function, it populates a string called $return with the full sql content of the backup of the entire database, and when it’s complete it writes that string out to a file and optionally zips the zip.

I’ll repeat that I think this plugin is fantastic. I do think, however, that it’s not fair to assume that the entire wordpress database can or should fit in memory. In the case of the site I was investigating, the Redirection plugin had created an enormous log table (whose name began with the wordpress wp_ prefix.) Our site itself typically consumed less than 40MB at steady state, but we were still blowing up php during the backup process with 256MB allocated to php. I confirmed with some debug output that the backup process indeed consumed all of that memory before crashing. This was worsened by the fact that iTheme Security appears to retry failed backups very frequently (in our case every 3-4 minutes), and each of these retries resulted in the same out of memory error, crashing php.

I think it would be a fairly straightforward refactoring to write the .sql file in chunks rather than storing the entire file contents in memory. This would make this excellent plugin even better, and would help a lot of people who are mystified as to why their modest wordpress sites are blowing up quite large php memory limits.

I notice that our host upgraded us to version 0.3.0.05 and the problem appears to be fixed. I can’t say for certain that it’s related to the version changes, but it seems like the most likely explanation. If you fixed something — thank you.

–Joe

I think I’m seeing the same symptom. Please let me know if I should open a different thread for this instead.

We don’t use the AJAX file browser for end users, only for content people editing posts/pages and uploading content. This was working yesterday and appears to have stopped working when our host upgraded us from version 0.3.0.02 to 0.3.0.03. Today I tried upgrading to 0.3.0.04 but the problem remains.

When an author clicks on the toolbar to insert a wp-filebase file into the rich text editor and then navigates to the Single File tab, the Select file area on the bottom of the tab is blank. In Chrome Developer Tools, I see the following error logged 3 times.

POST https://www.mysite.com/wp-content/plugins/wp-filebase/wpfb-ajax.php net::ERR_EMPTY_RESPONSE jquery.js?ver=1.10.2:5
send jquery.js?ver=1.10.2:5
x.extend.ajax jquery.js?ver=1.10.2:5
load jquery.treeview.async.js?ver=0.3.0.04:37
$.fn.treeview jquery.treeview.async.js?ver=0.3.0.04:91
refreshTrees editor-plugin.js?ver=0.3.0.04:225
(anonymous function) editor-plugin.js?ver=0.3.0.04:253
c jquery.js?ver=1.10.2:3
p.fireWith jquery.js?ver=1.10.2:3
x.extend.ready jquery.js?ver=1.10.2:3
q jquery.js?ver=1.10.2:3

The site in question is not yet publicly deployed so I can’t provide access, but I’m happy to provide any additional detail that would help in diagnosing the problem.

Thanks for your help,
–Joe

The solution you found on question-defense should work, but the RewriteRule is missing a character to remove the query string from the rewritten URL. This should work (note the additional ‘?’ at the end of the rewritten URL):

RewriteCond %{REQUEST_URI}  ^/$
RewriteCond %{QUERY_STRING} ^/?author=([0-9]*)
RewriteRule ^(.*)$ https://www.wordpressexample.com/some-real-dir/? [L,R=301]

I tried calling get_locale() from our theme’s index.php file but I didn’t see any result (not sure where I’d expect to see it.) Tried writing the result to error_log and got no result, so maybe index.php is cached somewhere (I cleared our hosting company’s cache to no avail.) To be honest, I’m not a php guy and don’t have any sort of debug environment set up for the php side.

I managed to call the function from wp-tinymce.php by adding the following code that I found on stackoverflow for pulling in references to wordpress core code:

require_once(‘../../../wp-blog-header.php’);
header(“HTTP/1.0 200 OK”);
error_log(get_locale());

That got around the “Call to undefined function” error I was getting prior to that. Here’s what I got in the error log:

[Wed Mar 13 15:04:00 2013] [error] [client xxx.xxx.xxx.xxx] en_US, referer: https://OURSITE/wp-admin/post.php?post=XXXX&action=edit

So, en_US locale.

I might be in a good position to help debug this problem, because it occurs on our staging server but not on our production server, although both are running the same set of plugins and plugin versions and are configured essentially identically. (We host at WPEngine and use their staging capability to take a snapshot of our site to staging for testing out changes.) I wish I knew when the problem first surfaced on our staging site, but I don’t. I don’t have tons of cycles to spend, but I’m happy to help get to the bottom of it with some assistance.

Thanks for your help.

Debugging a bit further, it appears that requireLangPack() is called by editor_template.js:

// Tell it to load theme specific language pack(s)
	tinymce.ThemeManager.requireLangPack('advanced');

I’ve seen this issue once before, and it recently happened on our staging server. I found this thread on google and although it doesn’t have a complete fix, it seemed current, so I thought I’d add some additional information in the hopes that we can find a solution together. We’re running WP 3.5.1 with the Advanced Custom Fields plugin (latest version) among several other plugins.

I see these errors when I try to edit a page:

GET https://OURSITE/wp-includes/js/tinymce/langs/en.js?ver=358-23224 404 (Not Found) wp-tinymce.php:1
Failed to load: https://OURSITE/wp-includes/js/tinymce/langs/en.js wp-tinymce.php:1
GET https://OURSITE/wp-includes/js/tinymce/themes/advanced/langs/en.js?ver=358-23224 404 (Not Found) wp-tinymce.php:1
Failed to load: https://OURSITE/wp-includes/js/tinymce/themes/advanced/langs/en.js wp-tinymce.php:1

Digging through the results of https://OURSITE/wp-includes/js/tinymce/wp-tinymce.php?c=1&ver=358-23224 pointed to the source of the request, but finding it has taken a fair amount of digging (thanks for minify). It is indeed TinyMCE that generates these requests, although it could be due to a language configuration setting that varies or some other variable I haven’t identified.

In wp-includes/js/tinymce/tiny_mce.js (version 358-23224), 155,528 characters into the minified script is the following function (JS Beautified so we can at least try to figure out what’s happening). This function is added to tinymce.AddOnManager among numerous functions.

requireLangPack: function (e) {
  var d = b.settings;
  if (d && d.language && d.language_load !== false) {
    b.ScriptLoader.add(this.urls[e] + "/langs/" + d.language + ".js")
  }
}

I have not dug in to understand why this is called for some WP configurations and not others. I’m open to suggestions on how to get this fixed.

I see now that you’re probably not running on IIS (based on the Linux paths in your error message). Still looks to be a cached php issue, since line 473 of post.php is not a declaration, and the 3.5 version of post.php doesn’t contain a declaration of get_post_to_edit() at all.

So I think if you can force all cached php scripts to be reloaded, you should be okay. Restarting the app server is probably harsher than you need, but should work.

I saw this same issue today after upgrading to WordPress 3.5 on a blog we’re developing right now (not yet in production). Oddly, we had another copy of the same blog hosted on the same server which we upgraded to 3.5 first, and it worked fine. I compared the file contents of the two blogs and they were identical, yet one reported this php error:

PHP Fatal error: Cannot redeclare get_post_to_edit() (previously declared in <blogroot>\wp-admin\includes\post.php:473) in <blogroot>\wp-admin\includes\deprecated.php on line 993)

This made me suspicious of state, so I reset the IIS server that was hosting both blogs, and the problem went away. This makes me suspect that perhaps some old php content was cached (which I have seen before in IIS and is maddening to diagnose). This theory is further supported by the fact that line 473 of post.php (as listed in the php error) is in the middle of a comment block — it’s not a function declaration. It looks like the get_post_to_edit() function was deprecated in the 3.5 release and moved to the deprecated.php file, but the cached copy of the old post.php still had it declared.

Not sure if you have access to your IIS server, but if you do, running “iisreset” (from a Run As Administrator command prompt) should fix the problem. I’m also interested to hear from others hosting wordpress on IIS (not my choice) and how you deal with this php caching issue.

–Joe