Samisa has written a nice post about using PHP in the enterprise. A commenter there argues that he don’t use PHP because it’s a dynamically typed language. It’s somewhat true that if you’re coming from a statically typed language background you’re stormed with so many questions and wonder possible nightmares of using one. Once you start learning a language and understand how programs are suppose to be written in that language most of these problems go away.
For all these years, it has only been Java/.Net programmers who has been enjoying the luxury of service oriented architectures. These folks understand the value of building a business functionality as a service or exposing an existing functionality as a service. PHP programmers have been building their web based programs happily without having to know what services mean. People in the PHP community has tried to bring Web services into the language with varying degrees of success. These are very courages and thoughtful efforts. But if you analyze them objectively you’ll see that many of these libraries doesn’t contain that much of features in order to build/integrate an application with an existing enterprise app.
What WSF/PHP has done is lower the bar of building PHP applications that can fit with existing applications in an enterprise written in Java/.Net or whatever the language that might be. Also, it has enabled ability to integrate existing PHP applications to your other enterprise applications.
One strong reason companies have embraced developing applications in Java is that so their data will not be isolated from rest of the enterprise data. In the past having a PHP application inside your company might have been frowned upon because it doesn’t make sense to have information which is isolated from all the other applications in the company. This is why most organizations invest in an ERP for example. But now, this has become a non issue. If you’re using open standards inside your enterprise to communicate/integrate applications, using WSF/PHP, you can integrate or extend services seamlessly with rest of your enterprise services.
I’m going to take Drupal as an example during this post and outline some of the challenges of working on it with a loosely knit team. One major problem with PHP based content management systems is that it’s PHP. So, anyone who have taken the time to stare at some code snippets could modify, say, the user module (in Drupal) and get his changes displayed (assuming that’s what he wanted in the first place). As a side note, PHP Manual is all you need to learn about PHP. This was a much criticized fact for Ruby, lack of freely accessible up-to-date documentation. Although situation is improving as the ruby-doc project gained more momentum. Any “teach yourself how to clean dog poop in 24 hours” guides are useless because it’ll take 10 years to learn howto program effectively.
Coming back to Drupal, this issue of having the freedom to modify anything ‘cos it’s all PHP should really not be an issue but experience suggest otherwise. Having restricted access to Drupal core files is also of limited success. Remember, I’m not talking from an outsiders perspective where you worry about world readable files and whatnot, this is from the developer perspective who has full control over making a code level change. A set of people maintaining the site doing continuous modifications.
If you’re just running Drupal as a blog and you’re the only one who makes changes to it, then there are no issues. In a team environment sometimes you assume that something like a change to a core file should not be done unless you have 1) googled 2) RTFM (thrice) and there’s no other way to do it, but surprisingly people overlook this fact and do change the stuff that should not be changed. Usually these kind of shit happens when you cut your software engineering lectures and go collecting meadow muffins on perfectly bright and sunny days.
Close examination suggest legitimate reasons such as,
include/common.inc rather than reading the API doc, which is comparatively harder and takes more timecommon.inc. “I need to display the top most blah blah blah nodes on these set of pages, it’s a common feature to all these so common.inc is the right place to do it”.All goes well for a couple of years until someone else takes over and use the universal language to communicate with your entire genealogy.
Those 10 second hack jobs will stack up with time and by the time shit hits the fan, no amount of version control could save you. Problems arise when you have to update your CMS. Files such as common.inc belongs to the Drupal core and will be updated. So if you have modifications in those files you now have to get those to the system. If you’re really unlucky and the API has changed now you have to substitute the new functions. This will become tedious when you have to go through each and every file to see what has been added/modified. Things get more vexing if you have nodes embedded with PHP code. These are nodes with Input type PHP. If the API has changed now you have to go through those pages and see what breaks.
So what are the possible solutions for this mussed up state of affairs?
Making everyone aware of the extension mechanisms available and doing changes in a disciplined manner will save you when you have to upgrade. Also this will make the life of the maintenance programmer easier. This does have one drawback. Turnaround times for features/changes will now take a bit more time than earlier but the big upside is the whole thing could be rapidly updated (if there’s a security vulnerability or a newer version have a killer feature, makes it faster etc…) and someone else could take over without much effort.
This will show some of the neat API calls Drupal provides which you could use to do almost anything. OxygenTank, the developer portal related to WSO2 products runs on Drupal. The code examples in this post are extracted from a soon to be implemented module which will alter the way you download products. Everything you need to know about the Drupal API is nicely documented.
Forms are defined as PHP arrays,
$form['noreg'] = array( '#type' => 'checkboxes', '#title' => "Reason not to register", '#options' => $reasons, '#default_value' => 0, '#validate' => array('fizzed_up_validator' => array()) );
When the above code fragment gets rendered into HTML it’ll be a list of checkboxes with the items in $reasons. Also note that we’re passing a custom validation function. Inside your custom validation function you could perform all the checking and if there’s an error condition you could say,
form_set_error($form, $message);
which will display an error message and redirects users back to the form. $form is a parameter your validation function takes. Forms API is well documented with examples.
There’s this need to add the user to a particular role depending on from where the user come to the download page. This should be done in the registration phase. That’s trivial to do with Drupal. You could get this “event” where the user submitted details has passed all the validation logic and about to be inserted into the database, at that time you have to fetch the role info from the DB and insert stuff to users_roles table. Oh, and the redirection part. When the form is successfully submitted (meaning user got registered) you could redirect the user to anywhere. All the API and the things you could do with it is extremely well thought out and nice to play with. To get this registration form, all I had to do was hide some attributes before the form gets rendered. For example look at the standard registration page. Embedded registration form of the newly designed page had to contain only the mandatory fields. There was no need to display rest of the stuff. So, what I had to do was in hook_form_alter unset the relevant $form['elems']. Had to define a session variable to detect we’re coming from the right page, otherwise the all the registration form instances will be changed. After that display the form,
drupal_get_form('user_register');
voila! Now you have a customized registration form. The cool thing is all the validation stuff defined for the registration form will work and you don’t have to do anything extra.
A slightly less documented API call that we use is user_external_load. This’ll load a given user’s details into the current session so that the user will be logged into the system. To pull this off successfully there needs to be an entry in the authmap table as the function implementation shows. I’ve not been able to find a way one could insert a record to this table via the admin screens.