hausinteractive

Update: Just downloaded and ran a copy of https://code.google.com/p/memcache-top/ (which is kind of cool, btw) and while hammering on a site running FFPC I did not see the stats do much of anything.

This leads me to suspect that the Backend status: DOWN message is accurate.

If I’m right then the question becomes: Why is the plugin seeing memcache as down when it is not?

Here is the list of WL locations used. The ones at the bottom have line breaks between them for readability (both here as well as in the *actual* config used on the site, for the same reason).

!is_page(‘membership’)
is_page(‘photos’)
is_page(‘mothering’)
is_page(‘about’)
is_page(‘faq’)
is_page(‘community’)
is_page(‘aboutjane’)
is_page(‘philosophy’)
is_page(‘trying’)
is_page(‘blog’)
is_page(‘membership’)
is_page(‘materials’)
is_page(‘contact’)
is_page(‘thinking’)
is_page(‘renew’)
is_page(‘paypalbutton’)
is_page(‘newsletter’)
is_page(‘smc-questions’)
is_page(‘about’)

is_home()

is_single() || is_home() || !is_(‘products-page’) || !($post->post_parent==’products-page’));

is_page(‘information’) || is_page(‘registration’) || is_page(‘the-agenda’) || is_page(‘hotel-information’) || is_page(‘childcare-options’) || is_page(‘sponsorship-opportunities’)

is_page(‘post-celebration’) || is_page(‘celebration-photos’)

global $post; return (is_page(‘products-page’) || ($post->post_parent==”products-page”));

is_home() || is_single() || is_archive()

is_home() || is_single() || is_archive()

Thanks alanft,

Our developer reported that “…some of the code I was using was copied and pasted from some WP forums that may or may not have been written correctly to last through an update.”

I think he’s going to remove it and run a few tests.

Will report back when we know how they went.

Cheers.

Hey Jaumesala,

If your web hosts allows WordPress FTP/SFTP access you can modify the file /wp-admin/theme-editor.php to also use this function.

This would be considered an advanced hack because:

(1) You are modifying core WordPress files

(2) You will need some understanding of how the code works to only modify the needed parts of the file so that…

(3) you can redo it after you upgrade WordPress if upgrades overwrite the /wp-admin/theme-editor.php file

jafcobend’s pastebin code shows the *differences* between the modified theme-editor.php file and the *original* file that came with WordPress 3.2.1. You will have to manually insert the changes to add this functionality to your wordpress sites running 3.2.1

I should also add that while I agree this isn’t *seriously* more insecure, generally FTP/SFTP accounts are protected by login rate limiters (locking out brute-force attackers after a certain number of attempts) while WordPress is not.

As such I would HIGHLY RECOMMEND installing a plugin such as Login Lockdown as a favor to your web host if you allow WordPress FTP/SFTP access.

Hey Ipstenu,

Thanks for the clarification.

It sounds like everyone wants wordpress to be able to live up to it’s full potential (and have all of the admin options be available to as many people as possible)

To that end, do you (or anyone reading this) know of any pages/wikis/docs that map out the different methods that people employ and their end result?

While most people obviously have no control over their hosts, I would bet that many web developers would still be interested (because, you know, knowing is half the battle).

Since I couldn’t find anything I put together a *super* incomplete (and possibly somewhat inaccurate) doc here:

https://docs.google.com/spreadsheet/pub?hl=en_US&hl=en_US&key=0AmG40U4O15VGdFI2RE1KR1lnamZXZWVMb0VTVUtDLVE&output=html

…that is publicly editable here:

https://docs.google.com/spreadsheet/ccc?key=0AmG40U4O15VGdFI2RE1KR1lnamZXZWVMb0VTVUtDLVE&hl=en_US#gid=0

Hey guys,

Many already put their SFTP credentials into their wp-config.php file in order to add/delete themes and plugins. What jaumesala is suggesting makes absolute sense–why give WordPress permissions to add a theme if it can’t then proceed to edit it?

One of the main security issues I see is that WordPress accounts aren’t protected as well as SFTP accounts are by default (and are more subject to script attacks).

It seems that use of the WordPress plugin Login Lockdown would go a good distance to resolving that problem.

Additionally, if one’s server handles it, the connections WordPress is making are easily made tighter with SSH vs FTP:

/** in wp-config.php */
/** Force WordPress to use SSH method for plugins and themes */
/** This eliminates the need to log in every time */
define(‘FS_METHOD’, ‘ssh2’);
define(‘FTP_SSL’, ‘true’);
define(‘FTP_BASE’, ‘/home/SFTP-Account/wordpress/’);
define(‘FTP_CONTENT_DIR’, ‘/home/SFTP-Account/wordpress/wp-content/’);
define(‘FTP_PLUGIN_DIR ‘, ‘/home/SFTP-Account/wordpress/wp-content/plugins/’);
define(‘FTP_USER’, ‘SFTP-login’);
define(‘FTP_PASS’, ‘SFTP-password’);
define(‘FTP_HOST’, ‘servername.com’);

While not all servers have (S)FTP access, this would be a HUGE addition for those that do. This might seem small to an engineering type, but would be a game-changer for end users, which is the point.

So all this to say +1 to using (S)FTP credentials to enable theme/plugin editor to “work”.

Good call. Disabled all plugins and went through the update process with one additional plugin installed at a time.

Can run updates flawlessly with all plugins on with the exception of Email Users 3.4.1.

Upon closer inspection, this looks to be a problem with WordPress core. The last line of the iFrame is “Just write.” which seemed like it would be unique among all the code in the site so I did this:

root@server:/home/sitedirectory/wordpress# fgrep -R "Just write" *

and got this:

wp-admin/includes/post.php: <div id="wp-fullscreen-tagline"><?php _e('Just write.'); ?></div>

If someone can take a look and confirm (and if confirmed add to an official bug list wherever it resides) that would be great.

Cheers.

Here is the full list of plugins that are active on the site (there are none inactive):
– Advertising manager 3.4.19
– Akismet 2.5.3
– Author Avatar List 1.1
– Avatars 10.0
– Email Users 3.4.1
– Enhanced WP-ContactForm 2.2.3
– Event Calendar 2.3beta2
– jQuery Colorbox 4.1
– NextGEN Gallery 1.8.3
– Rich Text Biography 2.7
– ShareThis 5.0.0
– User Photo 0.9.5.1
– WP-Migrate-DB 0.2.1
– WP Shopping Cart 3.7.6.1

In poking around I tried to reproduce so I could look at the contents of the iFrame. The following did NOT trigger the problem:
– Installing a new plugin (WP Supercache)
– Activating new plugin

Installing a new plugin and then updating it reproduced it so the problem seems to be limited to upgrading a plugin.

I’ve added the iFrame source to pastebin here

A cursory glance suggested it might have been nextGEN but disabling that did not remove the problem. Going to try to dig a bit deeper…

Update 2: I have been informed that we are NOT running suexec, so it’s not a problem with that.

That said, it’s still a problem. The ideal solution would be if WordPress could use ssh to write edits to the server using the system user’s account as that is what the perms are set to.

Is there an option to do this for editing files as there is to write and delete files?

I should also ask if the FS_CHMOD_FILE function is temporary (to save a file) or does it *permanently* set the permissions for a file once touched by WordPress?