cvc1968

The error you are experiencing always happened to me whenever I would migrate from a local MAMP development server to the live server. I finally figured out why.

If you go to your iThemes Security setup page, under the “Global Settings”, look for the “Path to Log Files” field. It is highly unlikely that your development site and your live site have the same exact path relative to your server’s root (NOT the site root…this setting looks at the root from your SERVER).

For example, on my MAMP version of the site, the path to log files is relative to my Mac’s root and looks like this:
/Applications/MAMP/htdocs/mysiteroot/wp-content/uploads/ithemes-security/logs

But on the live server, it looks like this:
/home/myaccountname/public_html/wp-content/uploads/ithemes-security/logs

iThemes similarly uses server paths for its “Backup location” under the “Database Backups” settings.

These paths get stored in the database, so when you export from dev site and import into production site and vice vers, these paths remain, and are meaningless to the different setup.

You’ll notice under each field in the iThemes settings that there is a button to “Restore Default Location” which detects the correct server path, so you can use that to reset the path correctly for each server.

You’ll find this info on iThemes Blog under the heading: “A Few Important Notes”

WARNING, I have had this issue prevent me from logging into my site after migration in order to click that button and make the change, so your better solution is to do a search and replace on the SQL export file BEFORE importing it into the other database.

Note that the ‘Migrate DB’ plugin https://www.ads-software.com/plugins/wp-migrate-db/ (and possibly others), prompt you for source and destination server paths as well as domain names and handle that find/replace for you.

• This reply was modified 8 years, 4 months ago by cvc1968.

Great. Thanks.

You are correct. It is now working for me on the test site with TML active, as well.

AND the page passord problem has popped up on a site on which I’ve disabled TML.

So, my apologies. There is clearly something else going on. Back to the drawing board.

Pierre,
I haven’t had a chance to try this yet, but I will soon. Thanks for the update.

Thanks for your efforts, Eliot. JSON still confounds me, to be honest. It probably is too theme-specific in this case. Anyway, everything is still working fine, so we’re good.

Gonna mark this resolved.

I have not had a chance to look into loudmoutman’s post, but I do have an update to my situation.

I just set up another new site with its own cpanel, using what I believe to be the same configuration settings as before.

This time, installation and activation of W3TC was flawless.

So…I’ve had three installations on the same server running three apparently identical cpanel instances and three different results.
1. Installation 1, I got the error, then turned off ModSec Security and that fixed it.
2. Installation 2, I got the error, turning off ModSec Security did not fix it, and ultimately nothing (including changing all permissions to 777) fixed it, so I had to install WP Super Cache.
3. Installation 3, no error, no problem.

I’m vexed. I’m going to return to installation 2 when I get a chance and see if there is any change and I will keep trying to identify some difference in these situations.

Sadly, this solutions didn’t work for me. I’ve detailed my tests and attempts at troubleshooting this at the following thread:

https://www.ads-software.com/support/topic/ftp-credentials-dont-allow-to-write-to-file-htaccess-4?replies=5#post-6994938

Well, I just conducted a very telling experiment.

After once again completely deleting W3Total Cache and then restoring all files and folders to their default permissions, I tried to install WP Super Cache. It had no problem writing to .htaccess or wp-config.php or creating files and folders within wp-content.

So I completely disabled and uninstalled and deleted WP Super Cache and tried re-installing W3TC and the same error occurs again.

So whatever is causing W3TC’s problems in writing to .htaccess is apparently unique to W3TC, regardless of whether there is something different in my current server configuration vs. previous server configs where W3TC did not display this error.

I hate to switch to WP Super Cache, because I strongly prefer the interface and features of W3TC. But if a solution is not found for this issue, I will have no choice.

I’m back. Although the solution I mentioned above worked for one site. I am now setting up another site and turning off the ModSec Security has had no positive effect.

Per numerous threads on this topic, I have done the following:

1. completely deleted my initial install of W3 Total Cache. Removed the lines of code relating to W3TC from both the .htaccess file and the wp-config file. Deleted the cache folder and the W3 config folder from wp-content.
2. completely disabled and deleted iThemes Security, though at this point in a new install, I hadn’t enabled any of its features yet. I verified that there was nothing from this plugin in htaccess or wp-config and no database tables.
3. Disabled ALL other plugins.
4. verified in cpanel that mod_security was turned OFF.
5. Manually set all of the following files/folders to permissions of 777.

• .htaccess
• wp-config.php
• /wp-content/
• /wp-content/uploads/
• /wp-content/upgrade/
• /wp-content/themes/
• /wp-content/plugins/
• (I tried setting the root public_html folder to 777, but that caused an internal server 500 error, so it had to remain at 750.)

• I then re-installed a fresh copy of W3 Total Cache and enabled it.

The results:

1. upon enabling W3TC, the error appears immediately atop the plugins page.
2. Clicking the button labeled “Update via FTP” opens what appears to be an empty progress bar that does absolutely nothing at all and provides no feedback, error message or anything.
3. Manually adding the “required changes” to .htaccess, then refreshing the page with the error …. the error still persists after refresht.
4. An inspection of the wp-config.php file shows that `/** Enable W3 Total Cache */
   define(‘WP_CACHE’, true); // Added by W3 Total Cache` has been successfully added there.
5. An inspection of the wp-content folder shows that the ‘cache’ and ‘w3t-config’ folders have been successfully created, as has the ‘advanced-cache.php’ file.

At this point, I am still willing to concede that I have a server issue. I have used W3TC successfully for years on this very same host (inMotion). The thing that is different with these installs is that I now have one of their reseller accounts and I created each of these cpanels from their Web Host Manager Interface. But I can’t for the life of me figure out where the screw up is.

So now, clicking on the ‘uninstall’ link under W3TC on the Plugins page gives the following error:

Warning:  Missing argument 1 for W3_AdminEnvironment::fix_after_deactivation(), called in /home/sharms15/public_html/wp-content/plugins/w3-total-cache/inc/functions/activation.php on line 754 and defined in /public_html/wp-content/plugins/w3-total-cache/lib/W3/AdminEnvironment.php on line 64

Warning :  array_merge(): Argument #2 is not an array in /public_html/wp-content/plugins/w3-total-cache/lib/W3/Plugin/TotalCacheAdmin.php  on line 759

So many problems.

Sorry for taking so long to get back to this.

That shortcode doesn’t work, but I’m not getting any errors. Just nothing.

For the record, I worked around this problem in the following way:

I installed Advanced Custom Fields and created a field for this post type and one other post type called ‘utility’. I set the field to appear in a panel on the edit screen.

In functions.php I enqueued a script that loads into Admin using the hook for post edit screens only:

function my_load_scripts($hook) {
	if( $hook != 'edit.php' && $hook != 'post.php' && $hook != 'post-new.php' )
		return;
	wp_enqueue_script( 'autofill-js', get_stylesheet_directory_uri() . '/js/autofill_fields.js', array('jquery'), '1.0.0', true );
}
add_action('admin_enqueue_scripts', 'my_load_scripts');

The script ‘autofill_fields.js’ contains the following, which can probably be done more efficiently than this:

jQuery(document).ready(function(){
       // determine which post type we're dealing with by identifying which field is present
	if (jQuery('#pe_theme_meta_info__position_').length > 0) {
		var pval = jQuery('#pe_theme_meta_info__position_').val();
	} else if (jQuery('#pe_theme_meta_info__type_').length > 0) {
		var pval = jQuery('#pe_theme_meta_info__type_').val();
	}
       // now copy the value of the relevant field to my 'utility' field
	jQuery('#acf-field-utility').val(pval);

        // If the field changes, change 'utility' along with it
	jQuery('#pe_theme_meta_info__position_').change(function(){
		var pval = jQuery('#pe_theme_meta_info__position_').val();
		jQuery('#acf-field-utility').val(pval);
	});

        // And this is the same for the other post type
	jQuery('#pe_theme_meta_info__type_').change(function(){
		var pval = jQuery('#pe_theme_meta_info__type_').val();
		jQuery('#acf-field-utility').val(pval);
	});
});

So now, whatever is in the Position field gets written to the utility field and I use
[field utility] to display that info.

SOLVED IT!

Thanks to another error that I encountered fortuitously:
I reset the browser while I had an edit page open, which prompted the popup to login again. When I entered my login, I got an error telling me this was not allowed due to Mod Security.

After disabling Mod Security in via ModSec Manager in cpanel, W3 Total Cache is now able to write to .htaccess and no more errors.

Mark this and Remember!

Tried starting fresh again this morning. Still no joy. Searching for this problem on the web indicates the most common fix is to make sure htaccess permissions are set to 644. I’ve verified that. No fix.
Also, again…manually pasting the required changes into htaccess does not make the error go away either.

At this point, I’m just going to throw some jQuery at the problem to hide or remove these error messages, as they seem to be meaningless.

That works. Thank you, Thom.

But are you going to make that change to the plugin next update? or will I lose this modification when the next update comes? If so, is there a way to do this with a filter?

Thanks

Thanks, Pierre.

Correction.

The white screen wasn’t a typical WordPress white screen. It was the result of a failure of javascript to fade out a white loader.

Here are the error messages I found under the white layer:

Warning: strpos() expects parameter 1 to be string, object given in /home/imagea8/public_html/msaanetwork/wp-includes/shortcodes.php on line 189

Catchable fatal error: Object of class stdClass could not be converted to string in /home/imagea8/public_html/msaanetwork/wp-includes/shortcodes.php on line 197