I’m really impressed with the WordPress plugin API and distribution system.  It’s well organized with great documentation.  I was psyched to see the little “upgrade available” button next to my own plugin once I published it to the WordPress plugin directory!  Even though I prefer object-oriented code, I have to admit the procedural style of WordPress code is consistent and easy to follow.

In the process I also had get my hands dirty with SimplePie RSS library that WordPress uses.  It does a nice job of parsing all kinds of RSS but I found it a bit difficult to debug feed errors.  Its also a little touchy with eBay feeds and there seems to be some glitches using set_feed_url(), so I would up accessing feed_url directly, which doesn’t seem right.  But it works so it’ll have to do for now.

If you give the plugin a try, feel free to leave a comment on directly the HungryFEED page.

The solution so far is to write a custom authentication plugin plus a component for Joomla.  The plugin handles sign-on and the component allows us to render basically anything within the content area of the Joomla site.  I was able to get proof-of-concept running today and not only does the Phreeze code render correctly inside the Joomla system, it wasn’t even necessary to merge the Phreeze code, it runs just fine with the source code in a separate folder from Joomla.  The component just has to do a little magic and configure some paths to make Phreeze happy.

This seems to be one of those rare moments where strict coding practices actually pays off.  I designed Phreeze to be an extremely modular MVC / ORM with the idea that we might one day use another rendering engine, or switch data engines.  We’re even in the process of swapping out direct database connection with REST services with no change to the views, which will be exciting.  Dependency injection is used for all the various parts so you can swap anything.  But I hadn’t really considered running the entire framework within another system.  So I was somewhat surprised when the code just ran with almost no configuration.

The biggest problem is with relative URLs.  Joomla I must say is pretty great about passing control to a component and then staying out of the way, even if you throw lots of weird querystring parameters on the end of the URL.  However, the relative paths to scripts, styles, images, etc are proving to be problematic.

I haven’t decided on the best approach yet but I’m considering simply writing new Views for Joomla.  This allows us to re-use all of our Model and Controller code.  I’d prefer to just use everything exactly as-is in each application but in some ways it might make more sense for the apps to render themselves differently when inside the Joomla system vs when running stand-alone.

Phreeze has a URL writer class which does help to solve the relative URL problem, however we didn’t use it consistently in all the views and so there is some cleanup to do.  Also this class isn’t accessible from within static JavaScript code, so that might get messy with some of the more advanced pages that make a lot of Ajax calls.

This is possibly my nerdiest post ever but it’s exciting to spend so much effort at writing adaptable code and then finally the day comes where you get to see it work in a totally unexpected way.

As you go through this walk-through, it helps to understand that WordPress MU was originally designed to create a branded, automated community of blogs using sub-domains such as user1.wordpress.com, user2.wordpress.com, etc.  You can sign up on wordpress.com right now and get your own instant blog, hosted on their servers.  You become a part of the wordpress.com community.  WordPress MU was designed to allow you to create your own communities under your own domain name branding.

This walk-through addresses a slightly different type of user which is perhaps a server admin or simply a person who runs several blogs.  There is no “community” and you don’t allow anonymous users to stop by and create a blog.  You might currently have WordPress installations on multiple servers with totally unrelated domains.  Keeping the code and plugins updated for multiple blogs gets to be a hassle, so the idea of a single, centralized WordPress install is appealing for maintenance reasons.  Thanks to WordPress’s flexible architecture you can do this, but it’s not part of the original design.

The reason I write all of this is to hopefully explain why TLDs are outside the scope of WordPress’s original design.  You can still set it up without understanding any of this, however it will make things easier if you know how the pieces fit together.

Requirements

To keep this simple I’m only going to write about the multi-site configuration.  I’m assuming you know how to install WordPress, edit config files on your server, create a MySQL database on your host and map sub-domains.  These things may be done differently depending on your host so you will need to do the research for your own host server.  If you run your own server you may have to know how to configure it for multiple domains as well.

DNS Configuration

Again, I’m not going to get into DNS configuration.  However, I will say that a simple setup is to simply point all of your domains to the same IP address and let WordPress do the rest.  You can also assign one domain an IP and then park each additional domain onto this one, which may save hosting fees.  WordPress relies on the hostname, so it doesn’t matter how you’ve configured Apache or IP addresses, so long as the domain maps to the physical location of your WordPress install.

As a handy tip – you can edit your local hosts file to point a domain to the IP of your WordPress installation and WordPress will install easily this way.  This is a great way to experiment and migrate over an existing site without taking the domain name offline.  If you don’t understand what this means, then don’t worry about it!

1. Install WordPress

Install using all defaults is fine.  You should install this onto the domain that you plan to use as your “master” domain.  My recommendation is to install it at the top level of your domain, for example “domain.com” (without the “www” prefix).  If you plan to use sub-domains for different sites then this will keep things simple.  You can always add “www” during site configuration, but you can’t remove it from your sub-domain sites if it was installed that way.  For example your sites will look like this: site1.www.domain.com  instead of simply site1.domain.com.

Verify that WordPress is running but don’t bother putting any content in at this point.  In the next few steps we’re going to enable new menu items one after the next that are necessary to use the multi-site feature.

2.Enable the WordPress Multi-Site Feature

Assuming WordPress is running, edit wp-config.php and add the following line:

define(‘WP_ALLOW_MULTISITE’, true);

After you add this line and save the file, return to the Worpress Admin page and look for a new menu item Tools->Network.  Navigate to this new menu and you’ll be prompted to “Create a Network” in order to enable the multi-site feature.

You have some choices as to whether you want to use sub-domains or sub-folders for your network.  Leave all the defaults and choose sub-domains.  We’re going to be using separate TLDs anyway so choosing sub-domains seems to make more sense to me.  If you choose folders, you’ll be on your own from this point forward.

Once you enable the network, you will be given text that you must copy and paste into an .htaccess file and some additional variables to be pasted into wp-config.php.  Do this as directed on the Network page.

After you edit these files and re-login you should see another new menu “Super Admin” which is above the dashboard menu.  Your site is now ready for multiple sites.

3. Install Plugin WordPress MU Domain Mapping

At this point your server is already setup to handle multiple sites, but we need to install a plugin in order to support TLDs.  The plugin to use is called “wordpress-mu-domain-mapping“  This plugin also includes a special file known as a “drop-in” which must be manually copied and hooks into the lower levels of the WordPress API.

You can install this plugin by manually uploading it, or through “Plugins->Add New.”  Just make sure
you install version .052 or higher.   After you have installed it, go ahead and activate the plugin.  You’ll notice that plugins now have an option to “Network Activate” which activates a plugin for all sites.

Once the plugin is installed, you need to manually install the Sunrise “drop-in”  which is included with the plugin source files.  You may either copy sunrise.php from /wp-content/plugins/wordpress-mu-domain-mapping/ to /wp-content/ or if you prefer  you can create a symbolic link (for example ln -s plugins/wordpress-mu-domain-mapping/sunrise.php.  I prefer the link myself).

Once you’ve copied or linked the file, you have to edit wp-config.php one last time and add the following line which will tell WordPress to activate the drop-in:

define( ‘SUNRISE’, ‘on’ );

Once you re-load the console you’ll once again have some new menu items.  This time they appear under the Super Admin menu and they are Domain Mapping and Domains.  The Domain Mapping has some settings that don’t actually need to be changed.  The Domains page is where we’ll map TLDs to a site (in the next step).

4. Create a Second Site

At this point your server is fully ready to support TLD sites, you just need to know how to add them.  The basic concept is that you create a site first using WordPress’s normal functionality.  Then you using the domain mapping plugin to map the TLD to the new site based on it’s Id.  Because WordPress doesn’t yet natively support TLDs, you have to do a little fudging with the forms.

First, under Super Admin go to the Sites page.  You’ll be confused because you have to choose a sub-domain for your site, even though we’re going to use a TLD.  That’s ok, just enter whatever you want as the sub-domain and add the site.

Now that you’ve added the site, you can click “Edit” under the new site and this will bring up a long page with lots of settings.  Don’t worry about changing everything right now but you do want to change these two fields: Domain and Fileupload URL.  These need to be changed to your new TLD:

At some point once WordPress natively supports TLDs you would probably be done at this point.  In fact you will be able to visit your new site if your domain is already configured, but you won’t be able to log into the admin panel for the site.  So we need to map the domain over to the new site.

Before you leave the Sites page, make a note of the ID of your new site.  (In the screenshot above, my site “whatever” has the ID of “8″).  If it’s a new install, then your ID will probably be “2″.

Head to the Super Admin -> Domains page and there is a form at the bottom to add a new Domain.  Leave the Primary checkbox checked.  Enter your site ID from above and the domain.  Click Save to add the mapping.

At this point you’re done and you should be able visit your site using your TLD as well as login to the admin panel.  I hope this tutorial worked for you and helped you to understand how WordPress MU feature works as well as some of it’s current shortcomings.

Please leave a comment if you have any suggestions to make this walk-through easier.

Josh’s instructions include everything that I need except mcrypt.  Luckily Michael Gracie has provided a walk-through for installing mcrypt on Snow Leopard which involves re-compiling some things, but isn’t as tough as it first appears.

After getting PHP and mcrypt going, the last step for me is setting up MySQL which has some caveats on OSX.  The main problem is that the MySQL installer places the mysql.sock file in a non-standard place and so you have to either create a link or alter your php.ini file before PHP will be able to talk to MySQL.  (If you get “Can’t connect to local MySQL server through socket ‘/var/mysql/mysql.sock’” or  “No such file or directory” when calling mysql_connect, then this is the problem)

After completing the steps on Josh’s & Michael’s pages and running the MySQL installation package, here are the additional steps that I like to take to get my local environment configured:

Edit /private/etc/php.ini

display_errors = On
mysql.default_socket = /tmp/mysql.sock
pdo_mysql.default_socket=/tmp/mysql.sock
date.timezone = ‘America/Chicago’

Edit /private/etc/apache2/httpd.conf

DocumentRoot “/Users/jason/Sites”

Edit /private/etc/apache2/users/jason.conf

Append FollowSymLinks to the Options

I also like to change the permissions on php.ini and httpd.conf to allow my user account edit permissions and create an alias to those two files somewhere easy to get to.

Installing MAMP is probably easier, but for some reason I prefer using all of the services that are pre-bundled with OSX.  Also Snow Leopard includes PHP 5.3 which led me to find a couple of deprecated functions in some of our libraries.

• NetConnection.Call.Failed: HTTP: Status 500
• Channel Disconnected

You may have tried directing your browser to weborb.php only to get this message: “WebORB v3.5.0 Fatal error: Call to a member function getServiceURI()”

The getServiceURI message is actually a red herring error message.  This simply occurs because weborb.php is expecting the raw headers to contain Flash remoting AMF message data.  Your browser is just making a normal HTTP GET and doesn’t know anything about AMF.   So weborb.php winds up with a null object on which it tries to call getServiceURI().  I wouldn’t be surprised to see a future release of WebORB that catches this error, even though it isn’t the purpose of this particular file to run inside a browser.

So, you are probably frustrated because you were trying to figure out what is wrong with your install and why you are getting the connection and/or channel errors.  These errors are almost always the result of a PHP compile-time error.  PHP5 itself is rather inconsistent in the way it handles different types of errors.  You may have noticed that it’s impossible to catch a syntax error or a bad path in a require_once() statement, for example.  If an include file is missing, PHP craps out before you have a chance to do any error handling.  You can only catch and handle run-time errors within your PHP code.  You may be tempted to think that WebORB should be able to catch these errors and return a more useful message to Flex, however the PHP engine stops executing before it even gives your code or WebORB a chance to handle anything.  It’s kinda the equivelant of having a syntax error in Java or C code that causes your app to not compile.  It doesn’t matter what type of error trapping code you write – if you code doesnt’ even compile, it doesn’t even get the chance to run.

When any part of either your service or WebORB encounters a compile-time error, it instantly dies and, depending on your server config, will write out the error details to STDOUT (which shows in a browser) but what it does not do is return a proper AMF message to the client.  If you were to look at the output of the PHP page, most likely you would instantly see cause of the error.  However Flex/Flash seemingly ignores the output of the page and it only processes the headers returned by the server (ie 500 error).  So PHP is outputing the details of the error but Flex blocks you from reading it.

UPDATE: I now use App Puncher to view error messages now.  A network proxy or packet inspector would probably work as well.  My original info below is still here in case you want to trace down errors by hand.

To figure these errors out, I try to start debugging with a simple function that doesn’t do anything.  Slowly, step-by-step I start re-enabling code until I locate the source of the channel disconnect by process of elimination.  Other times I write a debug page in PHP and call the function in question directly.  (This isn’t always easy if Flex is passing in complex structures, however, it can be worth the effort sometimes).

I’ve noticed these things to be sure-fire causes:

• require_once statement with file missing (or PHP include path not set right).  Note that if you are dynamically calculating the abolute path of the current working directory that it will be different when you are running via the “Management Console” than if you call your service directly from Flex.  This is a dead giveaway if it runs in one, but not the other.
• passing in an argument to a method that does not match the declared PHP type.  You can detect this by simply removing your type declaration in your methods and see if the data comes through.  This could indicate a mapping problem or an unsupported type.
• syntax error that causes PHP compile-time error.  This can be any type of silly syntax error.  These are usually easy to see if you create a server-side page that calls your service method.
• If the WebORB examples work, but not your own services, it’s pretty much a giveaway that PHP is crashing somewhere inside your own service code and not the WebORB installation.
• If you can’t even get the WebORB examples to work, then there is a good chance that editing PHP.ini will be required.  If that’s the case, hitting weborb.php with your browser can sometimes show you what’s wrong – just realize that any errors mentioning either getServiceURI() and FlashorbBinaryReader are due to the missing AMF headers that your browser didn’t send and are not the problem.

If you have a better way of debugging, please post a reply.  This can be an extremely frustrating error to chase down and I would welcome any suggestions.

The top search result as well as others indicates that this is a problem with php_mysqli.dll however none of the suggestions on this page helped me.  An experts exchange post indicates that the problem is with libmysql.dll, however I didn’t know where to download the replacement for libmysql.dll.  It turns out that I already had it and the following solves the problem on My Vista and Windows 2003 boxes:

Copy From: C:\Program Files\MySQL Server 5.0\bin\libmySQL.dll

Paste To: C:\Program Files\PHP\ (overwrite the original)

This assumes you installed MySQL and PHP to their default locations.  If not, then use the correct paths for your particular setup.

Prior to this fix, my unit tests were causing the “CLI has stopped working” error at least 50% of the time.  Since replacing the dll file I haven’t seen the error.

Steps to Fix the Problem:

Before you troubleshoot further, you may want to read #5 about how the Application Pool effects PHP configuration changes.

1. Replace the old DOS format path to the PHP Executable with a full path w/ quotes
2. Move php.ini to C:\Windows
3. Edit php.ini to set cgi.force_redirect = 0 (only necessary for CGI mode)
4. Make sure php-cgi.exe and/or phpisapi.dll are included in Web Service Extensions
5. Recycle the Application Pool

1. Replace the old DOS Path Format

The default path to PHP is C:\Program Files\PHP. When creating the IIS extention mapping, the PHP Installer uses the old DOS format path to the PHP ISAPI or CGI executable such as “C:\PROGRA~1\PHP\PHP5IS~1.DLL”. IIS does not seem to like this format.

One simple solution for this is to simply reinstall PHP to C:\PHP, or another location that doesn’t use long filenames. This will generally save you a lot of grief as PHP and its installer do not seem to handle windows long file names consistently.

If you prefer to keep things in Program files, go to the IIS Extension Mapping screen and locate the value for “.php” (See screenshot above). Click the browse button, select the executable and put quotes around it the entire path. So the value for this field should look like this “C:\Program Files\PHP\php5isapi.dll” (WITH the quotes around it). If you have installed PHP in CGI mode instead, the file name would be php-cgi.exe instead of php5isapi.dll

While you’re at it you may want to check the box for “Verify that file exists” as well. This allows IIS to handle actual missing pages (ie broken links) and return a 404. Otherwise IIS will just pass the request to PHP without verifying the .php file really exists and PHP throws a CGI error when the file isn’t found. People seem to have inconsistent results with this setting.

If you recycle the app pool at this point (see step #5) you *may* solve the 404 error depending on what extensions you installed or whether you had re-run the installer and changed stuff. However, you may still have issues changing php.ini settings in which case keep reading.

2. Copy php.ini to C:\Windows

The PHP installer creates a php.ini file for you based on your selections in the setup process. However the installer saves the file in C:\Program Files\PHP. The problem is that PHP is looking in C:\Windows for the .ini file. So, you need to move the file php.ini to C:\Windows. This may be confusing because PHP seems to run fine. But if you look closely at the phpinfo() output, you may find that php.ini file is not being loaded and all default settings are being used.

One of the critical things when configuring PHP is to actually edit the .ini file that is being used by PHP. The installer creates a worthless file in a location that PHP won’t read and so you may waste a lot of time editing this file. PHP pretty much universally will check the Windows folder for php.ini on all varieties of Windows, so my advice is to use that location and delete any other php.ini files that are hanging around..

3. Set cgi.force_redirect = 0 (Only necessary for CGI mode)

Various people report that you need to edit php.ini and set:

cgi.force_redirect = 0

I haven’t noticed this setting having any effect on my installations, but many people claim it is necessary when you are running PHP in CGI mode. This setting will have no effect if you are running in ISAPI mode.

4. Make sure php-cgi.exe and/or phpisapi.dll are enabled in Web Service Extensions

In IIS Manager, click on “Web Service Extensions” This includes a list of all dll and exe files that IIS is allowed to execute. The extension mapping that is specified for .php files must also be added here. I prefer to just add both php-cgi.exe as well as php5isapi.dll here and enable them both so that if I don’t need to worry about it again.

If the handler is already in the list, make sure that it is “enabled” as well. The enabled services have a green overlay on the service icon.

Lastly, confirm that the file path is exactly the same here as it is in your .php extension mapping configuration. That includes the dos path formatting. If you use junctions, you need to be using the same path in both places. IIS seems to check the path rather than the executable. It will not recognize if you use a slightly different path, even if they both point to the same executable.

5. Recycle the Application Pool

In order for any PHP configuration changes to take effect in Windows 2003, you need to recycle the Application Pool. If you have made changes to php.ini and they don’t seem to take effect, this is likely the reason. Among other things, the pool caches PHP settings and you need to clear it before new configuration settings will take effect. You’ll read people telling you to restart IIS (which doesn’t recycle the app pool) or even reboot your machine (which is overkill). You don’t need to do either of those. Just right-click on the DefaultAppPool in the IIS management interface and “Recycle” is one of the options.

If I’m having trouble with the ini file, I like to have a typical phpinfo.php file on the server while I make some arbitrary change to the php.ini file (like the session timeout or the max upload size). I refresh phpinfo.php and verify that my changes are taking effect. You can also check the Windows Event logs under “System” which will sometimes report errors in the php.ini file.

Notes regarding re-running the PHP installer to make changes:

The PHP installer does not really handle changes all that well. For one thing it will overwrite the path to the PHP executable w/ the old DOS format so you need to fix that after you run it.

The 2nd thing is that it will write changes to C:\Program Files\PHP\php.ini – regardless of the fact that PHP is actually looking at C:\Windows\php.ini

If you had previously moved php.ini to the windows folder, when you run the Change installation feature, it will create a fresh php.ini file that only incorporates the most recent changes. (ie, if you had 10 extensions enabled and you make a change to enable 1 more, your new php.ini file will only have the 1 enabled and the previous 10 will no longer be enabled)

One way around this is to temporarily move C:\Windows\php.ini file to C:\Program Files\PHP. Then run in installer to make changes. The installer will write changes to php.ini in that location. Then, move php.ini back to C:\Windows.

The ORM component of Phreeze has been developed internally by VerySimple over the course of five years and powers several of our client’s web applications.  Phreeze powers several of our clients’ web application and has proven to be an efficient and stable ORM for large datasets and high volume usage.  The MVC component of Phreeze is a new addition, but is already stable for production use.  The MVC uses Smarty template engine for view rendering, which is easy for developers and non-programmer designers to customize.

Basic API documentation and a support forum is currently online.  Tutorials and examples are coming soon.  The code is licenced under the LGPL which means you can use it for any purpose for no charge -including commercial applications.  A video demo is also available if you want to see an application being generating before you try it.  Phreeze is now a community project so please feel free to pitch in with any ideas or suggestions.

This will run PHP in CGI mode for both IIS and Apache.

1. Download from www.php.net the Windows Installer version of PHP AND the Windows “manual install” .zip distribution. (If you already have PHP running for IIS, then you only need the zip version)

2. Run the PHP installer. Install it to its default location of C:\PHP. PHP should now be working with IIS.

3. Move the file C:\PHP\php.ini-dist to C:\Windows\php.ini

3. Unzip the “manual install” distribution. You’ll notice that it has much of the same files as are already in C:\PHP. Move all the of extra directories contained in this .zip to C:\PHP

4. Download and install Apache HTTP server from www.apache.org. (I used version 2). Default install location is C:\Program Files\Apache Group\Apache2. The configuration you use is up to you, but i specify in the install wizard to run Apache manually on port 8080 so that it will co-exist with IIS (which is already on port 80). Then after that is done, I install it as a service by executing the command-line command: apache -k install
(from within the apache2\bin directory)

5. Edit the Apache configuration file C:\Program Files\Apache Group\Apache2\httpd.conf – make the following changes:

# search for “DirectoryIndex” and add index.php to the end:
DirectoryIndex index.html index.html.var index.php

# search for “ScriptAlias” and add the following lines in that section:
ScriptAlias /php/ “c:/php/”
AddType application/x-httpd-php .php
Action application/x-httpd-php “/php/php.exe”

6. restart Apache and the new configuration should take effect. create a test PHP file and see how it works.

* caveat: if you use the same browser and surf back-and-forth between IIS and Apache, you may get a bunch of weird error messages about permission denied while writing session files. This is because Apache and IIS run as different users & they will block each other from writing to the same session file.

Various websites instruct you to call set_time_limit() on the upload page. This overrides the max_execution_time setting which is found in php.ini. Calling this function on my upload page seems to have no effect on my server.  Changing max_execution_time in php.ini to 0 is supposed to be an unlimited timeout. However i was still receiving the error message. It would say “Fatal error: Maximum execution time of 0 seconds exceeded” which does not make any sense to me at all.

I discovered that, in addition to max_execution_time there is an additional setting max_input_time which controls how long a php file can spend processing the request data.  When i set max_input_time to a higher value, the problem goes away. So, it appears that the error message is reporting the wrong configuration variable.

These settings are found in php.ini, however depending on your host you may be able to override them either in your script or in an .htaccess file.   After you update php.ini you may have to restart your https server process to reload the php settings.  (windows servers may need to recycle the application pool).