This is an ongoing list of things that are different in CCK and Drupal 5 to 7. Basically everyting that I hated about Drupal 5 whenI first started an everything that I dislike about Drupal as a code base and the ideas that I dislike that have been implemented using procedural code. I have done these things in OOP using the native functionality of PHP.

I really do not like using Drupals stucture for creating HTML forms automatically. It's too complicated to create and debug. I took the time out in a project to find an easier way. Here's the code for having the form print out directly when the method is called:

Drupal views is my default system for creating sites where an administrator or webmaster can configure a website after it has been developed. Unfortunately the community has misled many into believing that anything can be done using Views, Rules and a handful of popular modules without coding. This is definitively not true! And even if you can code it is a dangerous road to walk.

So here's my latest gripe. Connecting User and Node References, counting references and displaying the right information.
If you try to get the node id or user id from a reference it is not available in the $row variable as it should be. Ask the programmer why because I have no idea what this variable is good for otherwise. The output from it is:

stdClass Object
(
    [field_tutor] => 18
    [field_school] => 7
    [field_school_year] => 18
    [field_student] => 18
    [field_tutor_1] => 18
    [php] => 
)

Referenced field values are the node id of the parent and not the value that actually connects the information to the node or user content. The information is available though in the $data variable.

print $data->_field_data['nid']['entity']->field_student['und'][0]['nid']; // note nid not "value"
print $data->_field_data['nid']['entity']->field_tutor['und'][0]['uid']; // note uid not "value"

This took me about three days of hunting and frustration (along with a good portion of trial and error) and cost me a deadline. So posting it here might save you the same because there is no straight forward answer about this even from the Fields API creator or the Views team.

Technical debt (also known as design debt or code debt) is a new word coming out of a metaphor that refers to the use of bad code, short cuts and poor architecture in software. The so-called debt manifests itself as incomplete work and sometimes as the real world cost of hiring and firing personnel. The reason the concept of technical debt is taking the software world by storm because it is such a simple way of explaining the constant struggle of businesses to get projects done on time and on budget. One of the things that is not talked about is the usage of open source web based software and the technical debt that doing so incurs.

Smaller Web development companies and Start-ups have a difficult time separating job specifications and actual work. Their lack of understanding of the software development process usually leads to recruiting the wrong person or giving internal promotions to the wrong persons.  These people, many of whom have never worked in or for a very large organization typically have no idea of which roles their personnel are competent to handle. They always seem to think that anyone given or taking the title "senior programmer" means they can do everything with and within a particular technology or software. Even worse they confuse the architects role with that of senior programmer.  So what qualities and skills does an architect have and programmers or developers need to have to become competent architects? And why is it so confusing to know which role is needed?

I am probably going to take a lot of heat for saying this but.... not one of the top 6 most popular CMS systems is "the best". Being the best stopped being a priority with these systems long ago. They are the best at only one thing, being popular and that's it.

I have not had any luck in adapting OwnCloud because of the lack of community knowledge and documentation. So I took some time to strip it down to its components. In the end OwnCloud just seems to be Web GUI for SabreDav. After a little hunting and research I found that I could get a more robust and customizable solution by using Drupal as frontend (authorization, uploads, CalDav UI) for my own SabreDav server.

Both Drupal and SabreDav have enough documentation, community and interest by php developers to get me over any obstacles I believe. SabreDav has an excellent OOP plugin system and I found some sandbox code for Drupal SabreDav and CalDav modules.

The only real difference I can find would be that OwnCloud uses Mirall and another protocol to sync things.

Anyone know of any really big differences or missing features that would arise from doing this? Am I wrong in thinking that OwnCloud is a wrapper for SabreDAv?

For years I have been doing website development using Drupal and Wordpress. I adopted both of these systems when they made development easier and faster. They were also more complete than the CMS I was building and due to time restraints I opted for them.
But nowadays this is no longer the case. Systems like Drupal are a wall that has to be climbed with each project. Simple things are no longer simple and the amount of time learning has become greater than the time actually creating.
This is why I am creating Berlinto. Because I feel that things should be rolled back to simplicity. I think that web developers need to embrace PHP more and stop trying to "fix" it. Berlinto is not a "killer" or the next step in web frameworks. It's more of a reversion to plain PHP and then takes advantage of PHP advancements in a very simple way.
I first got the ideas used when I was creating the Movico module for Drupal. But although Movico makes a single module easier to develop there is still a problem. I find that on every Drupal project I am spending hours in the administration area doing tasks better left to , well, administrators. I am a web developer so should not complain right? But still, I like coding more than sitting for hours watching those ajax animations turn while I wait for the admin section to process a view or whatnot. Not only that but that ugly feeling I get when I know that I will have to modify something extensively using PHP in template file is happening more and more often. Businesses and others are using Drupal and Wordpress in ways that they just cannot accommodate. I always at some point during development wish that I was working with Drupal 5 or Wordpress 1.0. Ahh... it was so easy back then.
PHP has come a long way since the first popular PHP 4. I have used PHP since PHP 2.0/FI and seen the changes that make it one of the most popular scripting languages ever. The thing is not many if any frameworks take advantage of the simpicity and power that PHP 5.3+ brings. Not only that but some are in an upward spiral and are using monolithic frameworks in an effort to fix the problems of complexity. But what they are doing is making pool of understanding more shallow and decreasing the amount of developers that want to use the product. Worse the teaching of PHP as a language is being diluted by the teaching of API's.
This! is not a good thing.

Berlinto vs. Drupal

In most CMS's there are conventions and thinking that is proprietary to each. This is counter-productive and creates a steep learning curve. If the CMS core or API's change in any way the developer must re-learn and refactor their code with each version or update.
Typically in Drupal to call a function between modules you would use.

     if (module_exists("module_name")) {
        module_name_function_name();
      }

Compared to the PHP object oriented method that Berlinto uses. It is the very simple and common PHP coding convention.

    $variable = new Class();
    $variable->method();

We as developers need to get back to this use of PHP. Everything does not have to be an API. The performance of OOP is no longer a factor in the decision to write clean polymorphic code. Berlinto is meant to be mostly a guide for developers. Allowing them to get past some of the grunt work. They can setup an application or CMS without being enslaved to auto-magic methods, conventions and configurations that do not suit all.
Don't worry I will still be working with Drupal and the Movico module. Many things in Berlinto I will just port to Movico. This so if a decision is made to get away from Drupal the transition to something like Zend will be easier via Berlinto. UPDATE: Berlinto is now called "Content Connection Kit", CCK.

The Movico module is a scaffold for building Drupal modules in OOP and MVC. One requirement of the project is a hooking system, similar to Drupals, that uses OOP. The following is how I plan to build such a system using the PHP 5 reflection API.

This code shows how using Reflection makes it easy to create a system that hooks into several Class methods to build a linked menu. This moves two systems that are heavy resource users and overly cached from Drupal and places them into the Movico domain.

To try this out you can download and install the Movico module, place this code in ...movico/_controllers/hooks.class.inc. Then surf to ?q=app/hooks/get_hooks. If you get a access denied page then add this to the mvc.module

Update: Moving to hiveminds.Wordpress.com to get syntaxhighlighting and Linkedin connectivity

function mvc_access($uri){

    $authorize = array(
        'hello' => array('access foo'),
        'hello_log' => array('access baz'),
        'hello_log_view' => array('access foo','access baz'),
        'get_hooks' => array('access foo','access baz'),
    );

...movico/_controllers/hooks.class.inc
======================================

/**
 * Normally the Classes would be in individual files and loaded via an iterator
 *
 *
 * @author Carl McDade
 * @since 2010-02-18
 */
class ConClass1 {

    function hook_output()
    {
        $var[1] = 'link text(1)';
        $var[11] = 'link text(11)';

        return $var;
    }
}

class ConClass2 {

    function hook_output()
    {
        $var[2] = 'link text(2)';

        return $var;
    }
}

class ConClass3 {

    function hook_output()
    {
        $var[3] = 'link text(3)';
        $var[4] = 'link text(4)';

        return $var;
    }
}

class hooks{

    public $hook = 'hook_output';
    public $arr = array();

    function _modules()
    {
        $vars = array('ConClass1','ConClass2','ConClass3');

        return $vars;
    }

    function get_hooks()
    {
        foreach ($this->_modules() as $module)
        {
            $Class = new ReflectionClass($module);
            $Method = new ReflectionMethod($Class->getName(), $this->hook);

            if ($Method->isStatic())
            {
                $output = $Method->invoke(NULL);
            }
            else{
                
                $instance = $Class->newInstance();
                $this->arr = array_merge($this->arr, $Method->invoke($instance));
            }
        }

        return mvc_view('default', $variables, implode('',$this->arr));
    }
}

?>

I just spent the last day or so working on a scaffolding module that lets developers build a Model-View-Controller application as a module in Drupal 6. The code and ideas are still in beta stages but working beautifully. This is the fleshing out of ideas that came about under development of Drupal websites.

Take me straight to the code

In the last few weeks I have been using only third party modules to build a number of sites in Drupal 6. During this I saw a problem with the present state of coding for Drupal. It has become like the Wild West making it almost impossible to understand any of the thinking, reasoning and organization of the code in any large module. Typically you will find modules that are just so much spagetti code without any documentation explaining what is what and where to find it.


When procedural code fails in its implementation of OOP developers turn to helper modules. Helper modules are performance killers. They act as a pseudo form of a Class to subclass system but lack the functionality of OOP Abstracts, Interfaces etc. Polymorphism is only available while using active modules which leads to a performance hit with each module activated.

Caching is a fix for the burden of loading dozens of modules at runtime and the performance hit experienced under a heavy number of user requests per second. Drupals menu system contains access control and url routing making them subject to unwanted caching and the constant emptying of the menu cache. This hinders the development of on the fly access control and has other unwanted after effects.

The template system for the application layer for modules is dependent on the presentation layer of the entire website. This means that modules developed using template.php in a theme cannot be easily moved without taking template.php and possibly dozens of template files with them. The caching of theme templates hinders development while tools like devel module exist they tend to be crutches rather than solutions to the problem.

What is Movico?

What the Movico (MVC) module does is act as a connector and wrapper for an organized OOP application using the popular MVC design pattern. Six tersely coded functions let the web developer build software in Drupal using PHP object oriented features, recognizable design patterns and Classes for structure. Many of the problems encountered by using typical practices in Drupal module development are removed through the careful use of OOP structures and design. The organization, cataloging of functionality and documentation become easier. Placing as either a Model, View or Controller along with proper designation of code part as Classes, subclasses and methods makes for better code readability. Long term maintenance and upgrading to future version of Drupal are made easier with removal unneeded use of core functionality. One of the best things about building a module like this is that it becomes more of an autonomous or "third party" web application. This makes it quite simple to remove Drupals hooks from the application and move it to another environment or make it a self-reliable web app. This is why the Movico module will always only contain the bare minimum of code necessary to make the underlying application work. A developer will never feel as though it is too much trouble to yank the Movico module dump Drupal and go it alone.


Benefits:

▪ Speedy development using OOP and MVC letting developers use those same skills and knowledge in Drupal and cross to other PHP projects designed in OOP.
▪ Simplicity and organization of code using object oriented design.
▪ True dynamic access control without the need for menu cache refreshing.
▪ A faster more dynamic and autonomous template system for modules. Create templates and variables that are free of theme templates and template.php files. Removes the need to refresh the theme registry cache.
▪ More scalability without after effects.
▪ Easier to add third-party solutions that use OOP design.



Future plans:

Simple test unit testing examples



Summary:

▪ Drupal emulates MVC Helper modules are used as controllers for groups of included files which act as models. Includes are a typical fix for heavy page loads due to reams of code that are used only partially on any page request.

▪ Polymorphism in Drupal is only available using active modules and hooking which leads to significant performance hits in large community websites.

▪ While it is possible to do a "Drupal way" or procedural coded implementation of MVC it is not easy and maintenance becomes a nightmare. MVC this way does not make use of PHP OOP tools which make organization and maintenance easier.

▪ API popularity is a reaction to the lack of the use OOP tools provided by PHP. Heavy maintenance and design of any API can out weigh any benefits provided.

Download from Github

Okay, so there's a few reviews of Drupal 7 turning up online. They give Drupal 7 look of kudos and praise for the most part. But what these reviews don't do is go into the code. I am going to do that here in the next few weeks as I build Drupal.se using Drupal 7.

Now I am not going to write about bugs unless it is absolutely necessary as part of an explanation of the work. Drupal 7 is in alpha so bugs are expected. What I am going to be doing is talking about the internals that will be of concern to a web developer, php programmer or web designer.

First a bit about the environment. I am running Drupal 7 on:

YAWS webserver
PHP 5.3.1
MySQL 5
Windows 2003 Server

Some things will change as I go through like the use of Clean Urls will be introduced after I decide on using appmods as versus a single arg_rewrite module for YAWS. I may also go with PostgreSql over MySQL later on.

The information will be in short paragraphs without any long articles. The following is an example.

I found out today that Drupal 7 has much more default templating in the core. Upon seeing an extra link appearing in my theme just above the header I investigated the core to find out why this was happening. This lead me to the system module and all of its files. Errant code was to be found in html.tpl.php. I was surprised to find dozens of extra files in the same directory. It seems these are the glue that hold together the default look of Drupal 7. If you are an old timer with Drupal then you probably are familiar with drupal.css. Drupal.css was the bane to all web designers because it needed to be overriden or removed when creating a new design for a Drupal installation. Well drupal.css now has dozens of companion files that will further complicate the learning curve. Hopefully you may never have the need to touch these files in later versions of Drupal 7 but as of now you need to make yourself familiar with them in case you run into the same problems that I am having.

So get ready for some long nights in reading core code if you want to become a true guru of Drupal 7 or make it do your bidding as a web designer.

I need lto run Drupal on several webservers on the same network and use some different ports of the same host name. This morning I found the Drupal 6 installer does not have support for non-default HTTP port numbers. While trying to do an install on one machine the installer refused to function because the host name was incorrect. Even after trying to force the issue by using the $base_url variable the port numbers were removed and the installation failed.

So I created an installation on another machine using port 80 and then moved the files over to the other. I then found that language settings were being ignored when a non-default port number is used. Changing the port number using the same host name causes the language to switch.

I hope that this gets fixed in Drupal 7.

I received this case study in my inbox from Linkedin.com written Acquia, the Drupal company. While I appreciate the effort to keep me informed I could not help but to immediately take issue with the content and how it is flavored. There is a distinct sprinkling of Drupal throughout the text but it really only skims the surface. It needs more meat.

The scalability solutions mentioned are MySql and PHP oriented and any problems in implementing those solutions using Drupal architecture should be brought to light.

If you want to know what's involved in getting Drupal up to par in this game then read these posts. They are the needed supplements to the paper.

Scale Cheaply

Database Sharding

Spent a good amount of time talking to the Tax authorities today concerning Drupal.se as an association and as a hobby. The clarifications give good promise for a non-profit community site. According to the law there is nothing wrong with taking sponsorship advertisements as long as they are reported when reaching a certain level of income. These levels are fairly decent and will allow for Drupal.se to be self-sustaining at some point. There are also provisions for my out of pocket expenses. So I will be drawing up some specs for sponsor advertising and making provisions for donations to the Drupal Association if and when Drupal.se goes over the levels of income needed to sustain itself.

What this means is that the playing field for input to the community by business will be equal. There will be no need for a business to contribute things like web hosting which would give an unfair advantage to a single company.

I have also received some good ideas for Drupal.se from Linkedin and emails at Drupal.org. Some of them may take time to implement but they are not difficult otherwise.

I will not be attending the Drupal meeting in Gothenburg as it will take place during the work week. I am all for short work weeks but not when they start with a Monday.

Att installera Drupal 7 fortfarande är inte lika lätt som det är med andra web publiceringssystem som Joomla. Problemet ligger i hantering of den settings.php fil. Behögrihet i filsystem gör det så att användare måste koperiera och skriva till filen innan de kan använda web gränsnittet. Andledning till dessa är att de flesta webhotell tillåter inte allt som behövs för att gör det på annat sätt. Apache och PHP måste kunna ha skriv rättigheter och hämna i rätt arbetsgrupp.

För några år sen diskussionen om installen av Civicspace/Drupal 4.7 var het och jag såg att Drupal 5 borde ha FTP access. Många såg nej till min ideen att installation paket borde ha en FTP access gränsnitt som är mer användare vänligt. Medan alla sa att Drupal borde vara lika lätt installerad some Joomla ingen vill klona Joomlas system. Sen efter kommer Joomla med deras ny och förbattrad installation gränsnitt som har FTP UI. Kanske Joomla hade fel då men det var en lösning som har aldrig krånglagt.

Den enda problem jag ser med sån lösning nu är säkerthet men nu förtiden är SFTP mer vanligt hos de flesta webhotell och fler övergå till SFTP varje dag. Jag tror att lösning nu ligger med de följande PHP funktioner.

PHP ssh2_sftp.

$connection = ssh2_connect('shell.example.com', 22);
ssh2_auth_password($connection, 'username', 'password');

$sftp = ssh2_sftp($connection);

$stream = fopen("ssh2.sftp://$sftp/path/to/file", 'r');
?>

Eller ftp_ssl_connect() som OpenSSL är mer vanligt hos de flesta webhotell nu än då. Finns också bra OpenSSL binärt (exe) filer till Windows.


// set up basic ssl connection
$conn_id = ftp_ssl_connect($ftp_server);

// login with username and password
$login_result = ftp_login($conn_id, $ftp_user_name, $ftp_user_pass);

echo ftp_pwd($conn_id); // /

// close the ssl connection
ftp_close($conn_id);
?>

Genom de funktioner Drupal 8 (eller Drupal 7.xx) kan ha en elegant lösning till kopiering av setting.php filen

Well it's been a week or more now since I announced that I would be building up Drupal.se as a community. Again there have been very disappointing results in a showing of interest in creating a community.

So I will start today with the wireframing of Drupal.se on my own. I am going to be running the site with Drupal 7 on Yaws webserver, Postgresql and of course the pre-requisite PHP. I am a big fan of wireframing and so I will be using the Zen CSS Wireframing theme.

This might take a bit longer but what the hell. I have time and since there is very little interest in participation collectively, I can make these decisions without feeling like I have disregarded the interests of the community.

The blog for the site will be this blog until further notice. So any suggestions or interactions should be posted here. This is to prevent any loss of information during the build up.

I will be available for new projects starting from this week. I am looking for short or long term employment in the Stockholm area. You can read my cv but here's a more useful breakdown on my experience as a Drupal developer. I am not looking to become a business or a consultancy, merely an employee. So if you are looking for someone with:

1. Over 5 years experience in the development and implementation of large, high traffic websites using content management systems. Experienced mostly with collaborative websites, or social networking sites.
   
2. 5 years experience as a PHP Programmer, solid professional experience in the use of Javascript, PHP, HTML, CSS, Ajax, and MySQL databases. 5 years experience in Drupal development.
   
3. Demonstrable experience in full lifecycle website development using Drupal
   
   with Significant experience with Drupal 5.x and Drupal 6.x.
   
4. Experience independently developing, or working with designers, to create custom themes that support the unique needs of different projects.
   
5. Full knowledge of the Drupal architecture and the availability of modules that allow the building of Drupal powered websites. Experienced in designing and implementing medium to large scale with as little coding as possible using Drupal.
   
6. Ability to communicate technical knowledge to technical and non-technical audiences.
   
7. Experienced in international development or i18n with multi-site configurations and content migration from proprietary content management systems.
   
8. American Citizen authorized to work in the US.
   
9. Permanent resident with authorization to work in Sweden.
   
10. PHP programmer proficient with:
    
    
    
    • Drupal
      
    • Wordpress
      
      
    • Joomla
      
    
    
11. PHP Frameworks:
    
    
    
    • Codeignighter
      
    • Symfony
      
    • Yii
      
    
    
12. PHP Programming:
    
    
    
    • OOP
      
    • Design patterns
      
    • MVC
      
    • ORM
      
    • YAML
      
    • AJAX
      
    
    
    
13. Databases:
    
    
    
    • MySQL
      
    • PostgreSQL
      
    • Microsoft Access
      
    • Microsoft SQL Server
      
    
    
14. 
    New interests:
    

    The development of scalable, high performance web solutions using concurrent programming in Erlang, Yaws webserver, Zotonic CMS. Schemaless databases based on the Erlang programming language ie. CouchDB and Simple DB.

    
    

I am your guy!

Had some time to get around to cleaning up the imac and all of its stray installs of Erlang and other software. Now running clean and updated versions of everything via Macports. Looking around at the job scene as it applies to Erlang projects. Trying to get a picture of how things might look in the future with Zotonic CMS.

Tops on the list is getting PHP up and running on Yaws and finding a way to get Drupal to work. thinking of some new ways of using Erlang to increase performance of Drupal by caching via erlang c nodes. Might also be interesting to see how many calls to user_load can be eliminated if the object is placed in the "cloud".