WordPress 3.9 – PHP Fatal error: Allowed memory size of XXX bytes exhausted

More WordPress 3.9 system administration issues.  Kept getting errors from WordPress once a couple of plugins were installed that looked like this:

PHP Fatal error: Allowed memory size of 41943040 bytes exhausted (tried to allocate 30720 bytes) in /var/www/wp-content/themes/x/framework/functions/global/admin/sidebars.php on line 166

According to Editing wp-config, the minimum memory required for WordPress 3.9 is 64mb.  You can do this by editing the php.ini file and increasing:

And then restarting Apache or Nginx.  Enjoy!

 

Continue reading

WordPress 3.9 Update plugin shows FTP connection screen

While working on a new wordpress install for a person in my group, I came across a problem when trying to upgrade plugins from within wordpress itself.  It kept showing an “FTP connection” screen.  Putting in valid ftp credentials for that server would fail with “Unable to connect” errors.  WTF?

It turns out there’s a magical wordpress config setting that you can add to wp-config.php:

This forces wordpress to use another method of updating plugins besides FTP ( I don’t really know what method it uses at this point, should research that.)

Continue reading

wordpress 2.5 and subversion

For some reason, performing an svn update on the external repository http://svn.automattic.com/wordpress/trunk/ does absolutely nothing. This is pretty baffling behavior.

I’ve also tried /tags/2.5 and /branches/2.5 and nothing. No changes come across. Very weird. Anyone else getting this?

Continue reading

Using Subversion externals property for WordPress upgrades

I find that upgrading apps like WordPress, Drupal, Symfony and open source PHP apps is simple for less complicated environments, but once you start adding in things like new directories, custom themes/modules, source code control as well as separate development, test, and production systems, the upgrades start to get pretty hairy.

Take WordPress for example. A typical upgrade of WordPress involves copying the new WordPress files over your existing files. Then you have to copy back safe versions of things like wp-config.php, .htaccess (if you’re using it), as well as any custom themes/modules from the wp-content/ directory. Not to mention any of your own directories that should exist alongside your wp-includes/ and wp-content/ directories. After that you can run the upgrade.php file.

These upgrade steps aren’t terrible. They’re quite a bit better then most open source apps out there but they still suffer from a few problems:

  1. If you have your code, including your WordPress install, in Subversion or another source code control system, you have to commit all the files that change with each WordPress version. There may be files added, deleted, etc. You’ll have to keep combing thru “svn status” messages to figure out everything you need to do to get all the WordPress files into your repository. This can be painful. And take a long time.
  2. WordPress is specifically written so that you don’t ever have to muck with the guts of it. You create themes and plugins for added functionality. So, since you’re not maintaining the code that powers WordPress, do you really need all those deltas in your Subversion repository? I think not.
  3. What do you do with your own code in directories that sits alongside wp-includes/? What if it’s in a Subversion repo?

The WordPress site also has instructions for using Subversion with your site. Here, they advocate the use of “svn switch” to update your site. This is much more manageable and solves a few of the above problems. Most svn users can probably can get away with this method. But unfortunately not me.

I have additional directories on some of my sites that I need to add into my WordPress install. So I have to copy/move them into the WordPress dirs which gets tough. And then my “svn status” will get all wonky because my WordPress dir is under one repo and my code is under another. This was endlessly confusing for me.

So I found myself looking for a way to completely wall off my WordPress install from the rest of my files. I was reminded recently of the use of the Subversion externals property and my mind started buzzing with possibilities. With “externals,” I can say:

Pull the stable WordPress code from WordPress.org and put it into this directory named /docs/wp/

Then my other directories, which are under my own local subversion repo can exist at /docs/dir1, /docs/dir2, etc. Of course, some Apache Alias magic is needed to make all this work.

Here’s the way I set it up for my some of my projects. So far so good. This is a bit hairy to set up but subsequent upgrades are a breeze. I use this across development, testing, and production systems (how to get those environments to work with WordPress will be another entry)

First off, the previous Apache document root for domain1 was at /www/domain1/docs, so the WordPress files wound up like this:

/www/domain1/docs/wp-content/
/www/domain1/docs/wp-includes/

But I also have a lot of dirs that sit alongside of wordpress like this:

/www/domain1/docs/dir1

/www/domain1/docs/dir2

We’re going to wind up changing that.

Create an subversion external property in /www/domain1/docs for WordPress

vi starts up and you can add the following line:

Save and exit

This downloads the WordPress code from the above address into your wp/ directory. Now we are cooking.

  • Now, /www/domain1/docs/wp is where all your WordPress code lives.
  • Copy wp-config.php to /www/domain1/docs/wp/
  • Copy .htaccess to /www/domain1/docs/wp/
  • Create a link from the stock wp-content/ dir to your personal wp-content dir like this

  • In Apache config, set document root for this domain to /www/domain1/docs/wp
  • Put wp-content/ dir and any other non-WordPress dirs/files into /www/domain1/docs
  • Create an alias for wp-content/ and any other non-WordPress dirs/files in Apache config

This looks like a lot of work, but it’s really only a lot the first time around. Next time WordPress has an upgrade:

Everything after the propedit in this group can and should be scripted which will basically give you a 2 step process for upgrading WordPress, while keeping you wp-content/ dir under local source code control, as well as leaving room for any other directories or files your site might require.

This technique will probably also work with Symfony although I haven’t tried it yet.

Continue reading