Posts Tagged ‘PHP’

Using the autoupdate for Wordpress when you have STFP

The Wordpress autoupdate feature allows Wordpress to automatically download and install updates on your Wordpress.  It’s one of the best features in Wordpress and usually performs a clean update in a matter of seconds without you having to mess around with your files. One of the downsides of autoupdate is that it does not support SFTP out of the box. There are several tutorials explaining how to recompile PHP to enable SFTP in Wordpress, but the best way to get around this is to bypass using SFTP, FTPS and FTP altogether and assigning the correct permissions to your files so the web server can have write permissions.
Log into your account using SSH and type:


chown apache /var/www/blog -R

Note: Some Linux distros use other users for Apache, like httpd, wwwuser, or wwwdata. Check the User directive in your Apache configuration to make sure you assign the right user to your files.

Be sure to replace the /var/www/blog with the path to your Wordpress installation. And that’s it.  Wordpress should take care of the rest.

Tags: ,

02

03 2010

Important symfony security update released

The symfony core team released new versions of three branches (1.2, 1.3 and 1.4) fixing a security vulnerability in the Doctrine admin generator. The new versions are 1.2.12, 1.3.3 and 1.4.4.

All our servers have been upgraded but if you are using the admin generator in your site, it is important that you clear the symfony cache. On shared hosting you can do so by login to the Control Panel and using Maestro. On a VPS, through SSH and as root run the following command: “cd /usr/local/php; git pull” and then clear your symfony cache.

25

02 2010

Setting up subdomain virtual hosts for multiple applications in a symfony project

It is very common to have multiple applications in one symfony project, like frontend, backend, api, etc. The common way to access the application is by specifying the application front controller, like

  • http://example.com/frontend.php
  • http://example.com/backend.php
  • http://example.com/api.php

Most of the time, it is nicer and better to use subdomains, like:

  • http://www.example.com/
  • http://backend.example.com/
  • http://api.example.com/

There are some hacks (here, here and here) on the net that allows you to define the application and environment based on the domain. These are good options if you need something quick and do not want to mess with the web server configuration, but you lose some flexibility and specially, all the web server log entries end up in a single file. I think it is better to have the traffic go into separate files for reporting and debugging purposes.

You can accomplish this by setting up virtual hosts for each subdomain and define the front controller for each virtual host.

1) setup the DNS entry. The recommended way is to setup a CNAME record. If you have a A record that points your domain to the IP addresss (example.com A 1.2.3.4) then you can setup a CNAME record which will point your subdomain to the same IP address without having to specify the IP in each subdomain. Then if you need to change your IP address, you just change it in one location:

example.com. A 1.2.3.4
backend.example.com. CNAME example.com.
www.example.com. CNAME example.com.
api.example.com. CNAME example.com.

You can also define a wildcard DNS like:

*.example.com. CNAME example.com.

This will make any-subdomain.example.com point to your IP address.

2) once you have your DNS records in place, it is time to configure the web server. If you use Apache, you would setup several virtual hosts like the following:

<VirtualHost *:80>
DocumentRoot /usr/local/sfproject/web
ServerName backend.example.com
ErrorLog logs/backend-error_log
CustomLog logs/backend-access_log common

<Location />
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /backend.php [L]
</IfModule>
DirectoryIndex backend.php
</Location>

</VirtualHost>

<VirtualHost *:80>
DocumentRoot /usr/local/sfproject/web
ServerName www.example.com
ServerAlias example.com
ErrorLog logs/frontend-error_log
CustomLog logs/frontend-access_log common

<Location />
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /frontend.php [L]
</IfModule>
DirectoryIndex frontend.php
</Location>

</VirtualHost>

<VirtualHost *:80>
DocumentRoot /usr/local/sfproject/web
ServerName api.example.com
ErrorLog logs/api-error_log
CustomLog logs/api-access_log common

<Location />
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /api.php [L]
</IfModule>
DirectoryIndex api.php
</Location>

</VirtualHost>

Notice that the mod_rewrite rules that usually are included in a .htaccess file are directly specified in the virtual host. If you disable .htaccess files and specify this configuration in your virtual hosts, your web server will gain some speed. If you prefer to use .htaccess files for convenience, you can have multiple .htaccess files and define which file to use in each virtual host using the directive AccessFileName.

Notice how I linked all virtual hosts to the same symfony project, and defined the default page and mod_rewrite to point to each front controller.

3) restart your web server and test.

In order to setup something like this, you will need to have full access to your environment so it is only possible to accomplish in a VPS or dedicated server. This functionality is planned for the next release of Maestro for shared hosting.

08

02 2010

Enhance your date input fields in symfony forms

Symfony’s forms are very powerful and big time-savers. Also, thanks for the integration with an ORM like Doctrine or Propel, managing dates is quite easy. But by default, symfony displays date fields as regular select lists where you pick the date (month, day, year, hour, minute)

It is actually quite easy to enhance this functionality and display a friendlier way to pick a date. There are several options at your disposal:

sfFormExtraPlugin

The sfFormExtraPlugin plugin has numerous widgets to improve the appearance and functionality of form input fields. One of them is sfWidgetFormJQueryDate which displays a button next to your field. When clicking on it, a date picker calendar-style pops up.

Note: You will need to download the jquery theme to make it look pretty.

To use it, simply install the plugin and add the following to your form configure() method:

        $this->widgetSchema['publish_at']= new sfWidgetFormJQueryDate();

Also, make sure you load the jquery javascript files in view.yml:

  javascripts:
    - http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js
    - http://ajax.googleapis.com/ajax/libs/jqueryui/1.7.2/jquery-ui.min.js

sfJQueryUIPlugin

The sfJQueryUIPlugin plugin is a nicer option. It displays a date picker when you click on the date input field, but it still allows you to modify it manually.

Installation is also quite easy. Install the plugin and add the following to your form configure method:

        $this->widgetSchema['publish_at']= new sfWidgetFormDateJQueryUI(array('change_month' => true, 'change_year'=> true));

Unobtrusive Datepicker

The Unobtrusive Datepicker by Massimiliano Arione is probably the nicer of the options, but also the less straightforward as there is no aparent plugin for it yet.

Follow the instructions on the site to get it working.

Any others?

Have you found any other solutions? Let us know and share it with us!

04

02 2010

What Facebook’s HipHop means for PHP-based applications hosting

Today Facebook revealed what they have been working behind the scenes for a long time. In a nutshell, HipHop is aimed at improving PHP’s performance by converting PHP code to C++ and then compiling it with g++, thus allowing Facebook to keep up with their growth with fewer servers.

In theory, by running compiled code, users would get major gains in performance with the same hardware. This is specially true for applications and sites built using frameworks like Symfony, Zend Framework, Cakephp and others. But it also means that you will need to compile the PHP code and upload the result into a server that can understand and run it. In consequence, hosting that will support HipHop be limited.

We have some questions before hand that will get answered pretty soon. How does HipHop compare with running PHP with APC enabled? Since Facebook contributed a lot to APC, we are assuming that using HipHop should be an improvement. We also are very curious to see how it will fare with frameworks like Symfony and Zend Framework.

Here at ServerGrove, our core business is PHP hosting, and as you can imagine that we are very excited about this announcement. As we were one of the first companies to offer PHP 5.3 hosting, we will test HipHop to see what it offers for PHP hosting. Part of our mission is to squeeze every single CPU cycle to offer the best performance from our servers so our customers’ websites run as fast as possible. If HipHop is as good as it sounds, be sure that it will be added to our products offering, but not before making sure we can provide the top-level support that our customers deserve and get from us.

We look forward to hearing your predictions on HipHop. How will symfony and Zend Framework fit in the schema of things? How will this affect our workflow? If HipHop is as good as it sounds, what will be the ultimate hosting product to go with it? Check back soon, as our tests materialize we will post them here.

03

02 2010

Enhanced Access Control for Symfony Front Controllers

A problem I have often encountered when working with Symfony projects containing multiple applications is the maintenance of the non-production front controllers. These front controllers contain a default check of the client IP address and must be modified to allow requests from any system except localhost (127.0.0.1). The creator of the application is then left to “roll their own” access control in order to facilitate development while still restricting the world at large.

While this is not a problem for Symfony projects which contain a single application, maintenance of these non-production front controllers can quickly become bothersome as the number of applications in the project grows. Any time an allowed address is added or removed all these front controllers need updated manually.

Listing 1 contains a solution to this problem. The source of the front controllers to be restricted gets replaced with this code (with the proper application name, environment, and debug setting of course). It is assumed the same set of IP addresses will have access to all the front controllers which use this code.

Listing 1: web/frontend_dev.php

<?php

if (false !== ($hosts = @file(dirname(__FILE__).'/../config/hosts.allow')))
{
  $hosts = array_map('rtrim', $hosts);

  foreach ($hosts as $host)
  {
    if (substr(@$_SERVER['REMOTE_ADDR'], 0, strlen($host)) == $host)
    {
      require_once(dirname(__FILE__).'/../config/ProjectConfiguration.class.php');

      $configuration = ProjectConfiguration::getApplicationConfiguration('frontend', 'dev', true);
      sfContext::createInstance($configuration)->dispatch();

      exit(0);
    }
  }
}

header('HTTP/1.0 403');
echo '403 Forbidden';

As you can see, the list of allowed addresses is stored in the config/hosts.allow file. This file simply contains an IP address (or partial IP address) to be allowed on each line. A sample hosts.allow file can be found in listing 2.

Listing 2: config/hosts.allow

127.0.0.1
209.85.225.104
192.168.0.
69.147.11.

Problem solved. Now whenever a new IP address or set of addresses needs to be allowed access to your restricted front controllers they simply need added to the hosts.allow file.

It should be noted when matching IP address blocks: since the check uses a substring match on the client address the trailing “.” needs included in the hosts.allow file. Otherwise an allowed address of “69.147.11″ would match “69.147.111″, “69.147.112″, etc.

Happy coding!

Tags: ,

01

02 2010

The importance of APC cache for symfony applications

I’ve been developing a website based on symfony. Since symfony 1.3 and 1.4 came out this week, I decided to upgrade it to 1.3 and then when I feel confortable to 1.4. The upgrade was a little bit more complicated that I anticipated, mainly because I was using some plugins that are not compatible with these new versions yet.

Then, I decided to run some benchmarks using ab (Apache Benchmark) to see how symfony 1.2 and 1.3 compared. To my surprise, I did not see an improvement on speed. I was expecting the new version would be faster, but for some reason I am not seeing any improvements. I have not gone into speed improvement measures yet, this was just out of curiosity with a symfony project pretty much straight out of the box. And my development box is not fancy or speedy, but for comparing both versions it would be OK.

When I turned on view caching, things really improved, doubling the requests/second rate. I am running PHP 5.3.1 here, so I am using all the new PHP memory handling and speed improvements, which is very good for frameworks since they tend to be heavy users.

Then, since I was already dancing, I dediced to install APC, an free opcode cache. Basically it caches PHP compiled source code so subsequent requests do not have to do the parsing of PHP files. It always improves performance without touching a single line of code. But to my surprise, I got an increase from about 14 requests/sec (remember, this server is not fast at all!) to over 70 requests/sec !!! That’s 5x times faster!

It also includes a nice web page with status and statistics of cached data.

apc-console

I did not get into more tweaking, but you can see there is a big difference. That’s why all our VPS servers come with APC installed by default, so you can get all the juice from your server. And that’s why you need to use it whenever possible.

07

12 2009

Quick tips: How to locate php.ini in VPS hosting

If you need to make modifications to php.ini in your VPS, there are a couple of ways you can find out where it is located:

a) In the command line, run the following command:

php -i | grep php.ini

The following line will be displayed, containing the path of the php.ini file:

Loaded Configuration File => /usr/local/lib/php.ini

Note: yes, the line above does not include the closing php tag. PHP does not require it and it helps to prevent spaces sent to the client before all the headers are sent, a common problem that causes cookies to not be set.

b) you can create a php script with the following content:

<?php phpinfo();

When you access this script from your browser, you will also see “Loaded Configuration File” containing the path of php.ini

Remember it is not possible to modify php.ini in shared hosting accounts. To make changes to the PHP configuration, you will need to do so by putting the directives in .htaccess files.

Tags: ,

04

12 2009

Say hello to symfony 1.4.0 and more!

Before this decade is over, the symfony development team is making sure they don’t go unnoticed. December 1st will probably be named Symfony day from now on. Exactly one year after the release of the 1.2 series, they released 1.2.10 and stable releases of the new branches 1.3 and 1.4. symfony 1.4 contains the same feature set of 1.3 but all deprecated functionality in 1.3 has been removed. Additionally, 1.4 will be supported for 3 years, which means it is a safe bet to develop any new symfony applications in 1.4 and upgrade any existing ones as well. In fact, to celebrate these releases, we upgraded our own website to run on symfony 1.4. With the help of the upgrade instructions and the new task ‘project:validate’, upgrading was a matter of minutes!

But the core team did not end it there. As if these major releases weren’t enough, Fabien Potencier announced the released of a new advent calendar, which this time will be a book with advanced symfony articles written by ten (yes, 10!) authors and several more contributors. Looking at the current available documentation, we are extremely sure this new book will be of the highest quality, and the printed book is already available at Amazon! Can’t ask for more!

So, finish the year strong, if you currently work with symfony, make sure you read about all the new features. If you are considering using symfony or are looking for a top-quality PHP framework for your next project, look no further. The learning curve may be challenging at first, but the investment will surely pay off in no time.

And one last note, as always, all these new versions are already available on all our servers. If you are a VPS customer, make sure to update your local library to get the latest and greatest. And happy symfony coding! Congratulations and many thanks to all the people that make symfony happen!

Tags: ,

01

12 2009

Fixing “XML Parsing Error: XML or text declaration not at start of entity” in Wordpress

This is one of the more annoying bugs in Wordpress. Wordpress is working fine, but when you check the RSS feed you get the following error:

XML Parsing Error: XML or text declaration not at start of entity
Location: http://domain.com/feed/
Line Number 3, Column 1:<?xml version="1.0" encoding="UTF-8"?>
^

The most common explanation for its cause is blank spaces leading and ending the PHP pages caused by editing the theme. There are two solutions for this problem. The first is the easiest and I would recommend trying this first.

Solution 1:

Step 1)

Install the fix-rss-feed plugin. http://wordpress.org/extend/plugins/fix-rss-feed/

Step 2)

Go to Admin > settings > fix RSS Feed

Step 3)

Click on the “Fix wordpress rss feed error” button

This might or might not fix your problem. I have had it work on some themes and it failed on others. If it fails I would recommend the following solution:

Solution 2:

The “Wordpress leading whitespace fix” is slightly more involved than the plugin, albeit a very good solution when the plugin fails. The fix is well documented so I will not bother to repeat the steps here. You can read installation instructions and download from here: http://wejn.org/stuff/wejnswpwhitespacefix.php.html

Tags: , , ,

25

11 2009