Tag Archives: wordpress

Every action has his equal and opposite reaction

Plugins zijn fantastisch. Ze brengen nieuwe functionaliteit, en zonder plugins zou ik niet weten waar WordPress nu zou staan. Uitbreidbaarheid is mooi, maar heeft een keerzijde.

Modules/plugins/widgets, whatever, ze plakken allemaal een stukje code aan de core. En dat is nu juist het probleem. Gisteren bij het updaten van de redirection plugin liep het mis. De PHP parser spuwde een fatale error uit. Heel mijn blog lag eruit.

Nu, de vele plugins die op deze blog draaien worden regelmatig bijgewerkt. Niet verwonderlijk, want WordPress zelf komt ook om de haverklap met een nieuwe versie op de proppen. Plugins dus noodgedwongen ook. De administratie pagina’s van WordPress laten toe om die updates automatisch te verlopen. Heel handig, ik kreeg de melding dat het werkte. Nee: ik had de verstoring nog geeneens opgemerkt. Een tweede update heeft het probleem gelukkig wel verholpen.

Dit is duidelijk een probleem op ontwerp niveau. Door de plugins ontstaat er een hoge koppeling. Plugins zijn goed te onderhouden, code is begrijpbaar en ze kunnen zonder probleem getest worden. Maar niet als ze samen gebruikt worden met andere modules. Niettegenstaande een hoge cohesie (iedere module/plugin heeft zijn eigen taak en verantwoordelijkheid), neemt de afhankelijkheid wel toe.

De auteur van de kapotte plugin had wellicht iets over het hoofd gezien, zulke dingen gebeuren nu eenmaal. Maar dit toont duidelijk de kwetsbaarheid van modulair uitbreidbare systemen (zoals WordPress, Drupal en vele anderen) aan. En dan heb ik het niet alleen over parse errors, maar ook over zaken als XSS aanvallen en SQL injecties.

Een betere manier is om eerst de nieuwe plugin in een daarvoor bedoelde omgeving te testen. Laten we daarmee besluiten.

10 fundamental differences between WordPress and Drupal

Nowadays, WordPress, the blogging platform, offers some pretty advanced features such as static page caching, the media library, widgets and user management. Where to draw the line with a full blown CMS such as Drupal for instance? These platforms are not only both written in PHP, they also are more or less based upon the MVC platform.

So, that makes a comparison valid and therefore I would like to briefly address 10 differences between Drupal and WordPress, which I believe are worth knowing. The list below is certainly not written to prove which platform is best (that just depends on your requirements), nor is it an exhaustive list of the differences. It is rather an attempt to show the discrepancy from a technical perspective and a functional point of view.

  1. First of all, Drupal is a Content Management System. It is designed to handle multiple situations: you could build an e-commerce site, but also a blog or corporate website for instance. Although WordPress can (I do not agree with some that say it is a CMS) be used as a CMS, it is still a state-of-the-art publishing platform and is specifically targeted at weblogs. Drupal is much more complex and has much more features.
  2. As a result of the previous, the average end user will be okay with WordPress because it is far more simple, easy and user friendly (e.g. the admin interface which is much more intuitive). You also may need some reasonable understanding of Drupal to be able to hack into it. Due to Drupal its complexity, you are more likely to suffer from scalability problems (e.g. Allowed PHP Memory Size exhausted).
  3. Both platforms breath extensibility: you are able to add functionality to the core. Drupal works with modules, while wordpress makes use of plugins. The difference is that modules are more straight-forward and more advanced. To give an example: Drupal uses built-in paging and access control can be specified seperately. Thus, I would say that plugins are a lightweight version of the Drupal modules.
  4. WordPress is designed to only work with the MySQL database. On the contrary, Drupal works with a database abstraction layer which allows the platform to connect with basically any database.
  5. WordPress ships with Akismet by default, a spam filtering service that is free for personal use. Drupal also has its own spam filter which is called Mollom. The difference is that the latter relies on context analysis and CAPTCHAs.
  6. Both platforms allow to override the look and feel using template files. WordPress has its own template tags. Templates in Drupal can also be parsed using template languages such as Smarty, PHPTAL and PHPTemplate. WordPress does not currently support this.
  7. Blocks in Drupal allow you to have content in different parts of a page. You have the ability to configure blocks from the admin panel. WordPress also lacks this functionality.
  8. WordPress is built around posts, pages, comments, links, categories and tags. Drupal has a uniform structure called nodes. You could think of nodes as objects, with the same underlying data structure. They can represent a blog post, a recipe, a news item, a story, an article etc. Developers can add features like ratings, comments, geolocation information and so on.
  9. Although Drupal is highly customizable, the WordPress community has much more themes and plugins available. However, because WordPress releases a new version every once in a while, third party plugins are version dependable.
  10. WordPress.com is an online community, where everyone can have their own blog. The idea is that anyone should be able to publish on the web without hosting the blog yourself. Of course, Drupal has no such thing, because the concept of Drupal is quite different as stated before.

Een CMS aanwenden of op maat schrijven?

Voor je aan een project begint, dienen er talrijke assumpties gemaakt te worden. Wat zijn de vereisten? Welke ontwikkelingsmethode wordt er aangewend? Is het project haalbaar binnen tijd en budget? Is de infrastructuur beschikbaar? Bij het ontwikkelen van de IMBIT website werd al deze problematiek reeds behandeld. Een issue die echter meer tijd in beslag nam, is of wij zelf alle programmatuur op maat zouden schrijven oftewel een CMS, meer bepaald Drupal zouden aanwenden.

De IMBIT site moet eigenlijk een geïntegreerd platform vormen inclusief forum, kalender, nieuwsbrief en een blog. Bovendien moet dit alles SSO zijn en gebaseerd zijn op user-levels.

Redenen die werden aangehaald om gebruik te maken van een CMS zoals Drupal zijn de volgende.

  • Drupal is modulair opgebouwd; biedt modules aan om een forum te integreren en beschikt over een ingebouwd kalender systeem.
  • De vereiste dat er user-levels configureerbaar moeten zijn wordt ook mooi ingevuld.
  • Drupal is rijp: er staat een enorme actieve community achter. Alles is goed gedocumenteerd.
  • Het is eenvoudig te beheren: het kost geen moeite om zelf de presentatie laag vorm te geven (themes).

Nochtans is er besloten om gedeeltelijk op maat te schrijven. Voor het forum wensen we gebruik te maken van phpBB3, voor de blog WordPress. Verder hebben we onze gepersonaliseerde user table. Dit betekent dat registreren op de website hoort te gebeuren, evenals het single sign-on aanmelden.

Maar waarom dan geen Drupal of een andere CMS gebruiken? Laat het duidelijk zijn dat we het wiel niet willen heruitvinden. Een reden is rechtlijnig met het concept van Vendor lock-in, namelijk dat je afhankelijk bent van hun platform. Stel dat ze het hele concept over een andere boeg gooien. Gans nieuwe structuur en database model bijvoorbeeld. Tja, dan kan dat, misschien geen geld, maar wel veel moeite kosten. Alleen bij commerciële firma’s die Open Source producten zijn gaan aanbieden, zoals RedHat en MySQL of zelfs Movable Type, vormt dit op zich een minder ernstig gevaar. Bij zulke bedrijven is het vanuit commercieel oogpunt immers belangrijk dat oudere systemen compatibel zijn met nieuwere.

Keuzes dienen gemaakt te worden, en ook het op maat schrijven heeft zijn nadelen. Een nadeel dat je hebt bij het schrijven van je eigen code, is dat je het goed moet documenteren opdat volgende generaties developers begrijpen wat er precies gebeurt. Ook hier werd over nagedacht en daarom zal alle code volgens phpDocumentor gedocumenteerd worden. Een ander nadeel is dat we de taxonomie van de verschillende gebruikersrechten zelf gaan moeten implementeren. Dat is niet eenvoudig, maar het biedt wel de volle 100% controle en dat is, vooral op langere termijn, van cruciaal belang. Ook is het zo dat zowel WordPress als phpBB3 beschikken over voldoende functionaliteit, zodat deze geen upgrade meer nodig hebben. Op die manier kunnen wij eigenlijk volledig onafhankelijk en gecontroleerd opereren.