Drupal Planet

The creation of new modules that add extra functionality on Drupal and make it work exactly the way we want has become a daily occupation of our programmers. We often realize that our team’s modules are necessary for other Drupal community developers. In such cases we feel obliged to provide for free the code that we wrote, in order to be used by everyone, with the same exact way that we are using all those awesome modules that have been developed and published on Drupal.org!

Two of our most recent modules that are published on Drupal.org is Entity Translation Export/Import and Node Translation XML sitemap.

Entity Translation Export/Import

This module provides the ability for mass export and import of content translations (nodes, categories, products). Of course one can translate content through Drupal’s translation UI and in most cases this is just enough. But there might be some cases, such as the existence of a large amount of content, in which massive export/import and editing in excel might save a lot of time.

Entity Translation Export/Import gives the ability by just pressing a single button to export as many as content type fields as we want. Then we can open the file in excel and translate the fields in all available languages. Finally again with the press of a button we upload the file.. and we are ready! The translations have been applied.

We benchmarked our content manager guy with both available ways. The results are enlightening:

  UI translation Excel translation
100 categories (terms) 30 minutes 7 minutes
100 products 45 minutes 10 minutes
100 pages translation (nodes) a couple of centuries... :) about 30 minutes

Node Translation XML sitemap

“Node Translation XML sitemap” doesn’t do anything extraordinary but it covers one very basic need. The ability of exporting xml sitemap of all the available languages of the site and not only from the original language.

It sounds a little bit odd that such a famous system like Drupal lacks this ability, but it is also makes sense. Drupal 7 has two ways of translating. Internationalization and Entity Translation. Internationalization was the basic way of translating in Drupal 6 and this was continued in version 7, at least in the beginning. In the meantime Entity Translation was developed which is expected to be the main translation mechanism for Drupal 8. So Entity Translation as a subsequent system it had some inconsistencies with many famous Drupal modules and one of them was XML sitemap. As a consequence, every site that uses the modern Entity Translation, mainly the more recent ones, are in need of Node Translation XML Sitemap in order to be able to export sitemap for all the languages.

Convert.comSome days ago, we released to the Drupal community a module that facilitates A/B Testing & Multivariate Testing through Convert.com.

Convert.com is a new generation experimenting tool that allows people with no coding capabilities to start optimizing their site.

Enable the module, go to the settings page (admin/config/system/convert), set it to ON and insert your account id. Then, you are set to go.

The module adds the Convert.com tracking code in your page's HEAD and also allows you to tag your pages using Drupal Tokens.

Finally, adds the revenue tracking js on the commerce checkout complete page, so you can have revenue as a tracked goal as well. You don't have to do anything to enable this, it is added automatically.

You can sign up at the convert.com service here. You can download the module from here. You can get more information about how the module works and how to integrate with convert.com here.

At Netstudio we have extensive experience on building, running and analyzing A/B and multivariate experiments, so if you need any help, feel free to contact us.

My name is Panagiotis Moutsopoulos and I am the most recent member of the Netstudio.gr team. I have been part of this great team for a few months but I never had the needed time to say "Hi!". Wondering about what I should write, I thought of what Ernest Hemingway used to think: “Do not worry. You have always written before and you will write now. All you have to do is write one true sentence. Write the truest sentence you know".

So, I've been a member of Drupal.org since 2009 but my first contact with Drupal was a few years before that, back in the 5.x era. I had just reached the end of my studies in university (Information Technology in the Technological Institute of Athens, actually) and I was used to build websites from scratch using plain PHP and MySQL. Well, Joomla existed but I still preferred using custom code. It might be that I didn’t like Joomla’s logic or that I had to pay money for some modules. The fact is that in a colleague’s screen I saw the Garland theme with the Druplicon. It was kind of weird. It seemed so weird that I wanted to explore it. What it is, what it does, who uses it and why! All these questions filled my mind and since I was used to check the various web applications found in the Ubuntu repositories (like EGroupware for example), I thought of testing the Drupal system too.

Long story short, I started reading the docs, hacking the core (and understanding why this is a bad thing!!!) and developing my custom modules from defining simple hook_form_alter()s to implementing payment methods for the Ubercart ecommerce system or processing images using the PHP GD image library. I also learnt jQuery in the process. So, after being burnt and having got my hands dirty many times with what I did wrong, I decided to write below a few statements and a few advices. Some of them are meant to be read from anyone in the WebDev community, whereas others are meant only for the Drupal community.

1) Don't ask for the solution. Discover it!

(if you have the time)

We will always find bugs in the code. May it be a module that doesn't do what it says, may it be a library that has a conflict with custom code. Bugs are always bound to survive and developers are bound to always be there to fix them. From the smallest function to the largest framework, everything comes down to basics eventually. In most cases, someone will have already asked the same question and you will be able to find it with a simple Google search or a more focused one like in StackOverflow or Drupal Issue queues.

Do not forget: There are times that it is needless to reinvent the wheel. If what you are trying to do is so extreme, or you will need more time doing it than having a benefit from the experience, it might be better if you asked a colleague. Just make sure you dedicate some time later on understanding how the code you may have copied works.

2) Don’t improvise! Use the tools you have!

(or at least have a knowledge of them and when you have to use them)

From a simple programming language to a full framework, the developer has some tools at his disposal and must know how to use them. If you know for example that the PHP function array_slice() exists, you will most possibly avoid for{} loops until a certain index is reached.  On the same track, if you know that there is an entity_load() function in Drupal, you will most certainly avoid querying the tables of the database to get the values you need. When choosing a toolbox, we use to choose it for the tools it offers and not for the wood or the iron we can get if we disband the hammer.

Do not forget: There are times that you will not able to do exactly what you want to. There are also times that if you do it the framework-way the whole process will take longer. For example, if you need the title of a node in a Drupal single-language website, using node_load() just for this might be a bit excessive. You could just db_select() or even better db_query(‘SELECT ...’) the node table. If you have knowledge of the tools you have in your possession, you will be more flexible. I wouldn’t want to give the benefit of flexibility away. Would you?

3) Check the server! Check the version! Beforehand!

(or upgrade if necessary)

When developing a new website or adding new features to an existing website, make sure that the client has specified the supported browsers and that the hosting company has specified the possibilities of the server. If the client needs IE6-support, in case of an intranet site where the users haven’t upgraded their Operating Systems for a very long time for example, you might want to make sure no border-radius or box-shadow or any other hocus-pocus CSS exists in your code. Hocus-pocus for the Middle-Aged IE6 that is... If you add features to a pre-existing website, you might also want to check its software version. May it be a JS or PHP framework, you must take the version into account. For example, the entity_language() function in Drupal was added in version 7.15. If you need this function and the website is built upon a version prior to 7.15 you should consider upgrading. On the other hand, make sure your production server has the same packages installed as your development server. It would be terrible if you couldn’t use file_get_contents() to get the contents of a URL you need because the hosting server is a shared plan and the allow_url_fopen setting is set to false.

Do not forget: You won’t be able to please everyone. You may get anxious, you may struggle to make everything work correctly with what the client and the server offers you, you may try again and again but some things are not meant to be. If you are sure you will get the job done much easier using a version of PHP >5.2, you’d better talk with your client about investing on an upgraded server.

4) Gain the experience of the Drupal or similar application process!

(even if it takes sometimes long)

I have the experience of the Drupal application process but I’m sure there are others like this too. It was easy to start developing a module. This part is always easy. I even remember a speaker in a conference telling us that it is much easier to forget security in web applications than in desktop applications. Web languages offer the possibility of displaying your content immediately and when you see immediate results, you can always say «Since it executes and displays correctly, it’s ok», but clearly it’s not. Till now, developing a custom module in Drupal is almost like writing a function or two {which are mostly hook_alter_*() functions} in a .module file and enabling it. After my experience with the Drupal application process, it seems this isn’t just that. There are coding standards that you won’t be able to miss if you want your module published in the community. My experience was with the UC Clear Roles module of Drupal 6 and there were many things I had missed. For example, when creating menu items through hook_menu() functions, you don’t need to enclose your string in t(). The system does it by itself and using t() over the default t() is just plain wrong. The website will still work. But you will have some translation issues. Other than that, I also discovered the Coder module.

Do not forget: Sometimes it may seem harsh when having done a great work and people tell you that you have to correct the comments and the lines that exceed the 80 characters-limit. Don’t take it too hard. There is a reason behind this. You won’t be able to understand the “why” until you succeed but it is definitely worth it.

5) Check how the core developers have made it!

(and file a patch if it’s faulty)

If someone knows how to do it better than anyone, it must be the core developers. They are the ones who created all the tools you have in your hand to start building your application. Check the code of a core module of the system you are using and get a glimpse on how the core developers have written their code. Don’t expect to start developing and implementing a new payment method in Drupal Commerce without having at first looked the DC core module implementing the Paypal method. You may succeed but it will be painless and useless.

Do not forget: Sometimes you will find bugs in the core documentation or modules. Don’t just fix the problem in your local environment without informing the developers. In Open Source systems especially, their power is the power of contribution from the community. Even if you don’t care about the community, at least think of this: If you don’t fix the problem, you will encounter it again in the future.

6) New technologies mean new possibilities!

(sometimes new troubles too)

Being a developer is not something you study in university and after graduation someone will tell you “That’s it! You ‘re ready! Congratulations!”. It definitely doesn’t go this way. Using document.getElementById() function when you have jQuery or any other JS framework loaded is like using the copy con DOS command to write a text file when all those editors exist out there. It’s worthless unless you want to add a Google Map in your application or if you are studying JS from zero point. You have to learn new technologies and test them. Clients will learn about them and ask for them. You can’t just say “I have studied B and in B I believe” when it has been overlapped by C and C++.

Do not forget: It’s not possible for a human being to study all and every new technology. You will get anxious and eventually give everything up. When having your first steps is when you need to get a glimpse of everything. After deciding your field of knowledge, you‘d better stick with it and just evolve and advance in it.

7) Secure your database! Secure your code! Secure your input!

(anyway you can)

Most web applications at this time require a database system to store their information. I’ll start from the basics. The user passwords should not be plaintext. You should encrypt them and then store them. If not even the administrator of the website may make the system reveal a user’s password, then this gives the system an integrity bonus. Another thing you should make sure when developing an e-shop system and the client needs credit card details stored in your system is this: make sure you store the data encrypted. No, MD5 algorithm won’t suffice. You should better consider using a salt algorithm for this kind of data. Just make sure your salt is not hard-coded but, instead, included in your code from a file outside your website’s root folder. You should also consider securing your code. Drupal modules are mostly functions doing nothing if you’re not Drupal. CSCart uses another mechanism for its files: it looks for a constant normally defined in its index file. If it’s undefined, die() is invoked and the process stops. Drupal’s contributed modules don’t have any .php extension too. One of the benefits of this, is that the developer may include them in his/her code but no one will be able to execute them since Apache only knows about .html and .php files. Files with a .module or .inc extension are no candidates of being executed.

Do not forget: Drupal has this simple but powerful function called check_plain(). It’s actually just a wrapper around the PHP built-in htmlspecialchars function but it gets the job done well enough. I have even found myself copying this wrapper in other systems to make sure the values the user submitted are going to reach the database without breaking anything. Well, dangerous strings will break but that’s a good thing I can assure you.

8) Cache what you can!

(don’t overdo it though)

From basic PHP to frameworks like Drupal, there are some mechanisms and some ways of caching the data you once produced in the same page request, in the session or somewhen in the past. For example, if a function returns a HTML string and doesn’t take any arguments, you might want to use the static keyword to declare the variable holding the output and return this when non-empty instead of recreating the value. You might also want to store values in the $_SESSION variable, like the email, the full name and other personal details, to prepopulate the fields the user has already filled but left the form page. Drupal also offers various mechanisms for caching forms, blocks, entities, views and other elements in database and these values can be used later in the day to save regeneration.

Do not forget: Don’t overdo it! Using static variables increases the memory footprint and using the $_SESSION variable to store HTML is not the best thing to do. You can always store the values you need in session and have a HTML template file for the static content.

9) Run cron outside Drupal!

(or even more outside)

Drupal 6 without Poormanscron module required a cron job to make the website’s cron run. In Drupal 7 this is no longer required since every time a user views your website, if a certain time has passed since the last time, cron will run. This has some drawbacks though. This means that the visitor running cron will have a slower response. This also means that if no one reaches your site for a certain day, cron will not run. To avoid all this, or if you need cron to run every minute for example, you should set a cron job from an external source. As for how to do this, you should consider checking the drupal docs.

Do not forget: Drupal runs each module’s hook_cron() based on the module’s name and weight. If a module’s cron execution takes longer than desired, you have at least two ways of solving your problem. One way is to create an external file which will include the drupal bootstrap and call from there your desired function. You may find information on how to do that in Navin S Nayan’s blog. The other way is to install and enable contributed modules like Elysian Cron or Ultimate Cron and decide how often each hook_cron() will get executed. This way, you may set, for example, the core’s functions to get executed once per hour but your custom module’s hook to get executed every five minutes.

I'm very excited about the upcoming Drupal 8 release and its features and even though I'm not a core developer (yet), I follow its development as close as I can. There are numerous blog posts about it and the new features it has. There are hundreds (if not thousands) of issue queues where you can watch our community discuss and build the new system, you can even try the freshest dev release by using SimplyTest.me.

But, while there is a vast amount of information about Drupal 8, I couldn't find any metrics about how it will compare with Drupal 7 performancewise. I know that we're not in code freeze yet and that performance improvements are scheduled for the "polish phase" which officially starts on 1 July, but I was curious to see how Drupal 8 performs at this stage, where many API's have changed, a lot of hooks have been replaced and a new framework is implemented into it (Symfony2).

So, I thought that since there was no such information on the net yet, I would find out myself. So, here is a quick and dirty performance comparison between the latest Drupal 7 version (7.22) and the latest dev build (1 June) of Drupal 8.

Test setup & methodology

I downloaded and installed both systems on my MacBook Air (1.7 Ghz Intel Core i5, 4Gb 1600 Mhz DDR3 RAM) and measured requests per second on MAMP with PHP 5.4.4. I used ab (apache benchmark) with 20 concurrent requests (-c 20 -n 20). So, on the following table, you can see the amount of requests per second that MAMP was able to serve for 4 different cache settings and 3 default pages: Admin home page and site homepage as it comes when you install the Drupal standard profile for both anonymous and logged in users.

For each metric, I used the highest number I got after 10-15 consequent measurements.

Results

 

Requests/sec (more is better)

 

Drupal 7.22

Drupal 8 dev

APC & internal cache disabled

   
admin homepage (/admin) 10.25 5.07
homepage, logged in 10.57 4.25
homepage for anonymous users 11.66 4.56
     

APC disabled, internal cache enabled

   
admin homepage (/admin) 10.32 5.09
homepage, logged in 10.58 4.17
homepage for anonymous users 114 37
     

APC & internal cache enabled

   
admin homepage (/admin) 49 14.02
homepage, logged in 43 11.44
homepage for anonymous users 491 147
     

APC enabled, internal cache disabled

   
admin homepage (/admin) 50 14.17
homepage, logged in 43 11.43
homepage for anonymous users 65 14.04

Conclusion

When I saw the results, I got disappointed. I had a secret hope that I would see Drupal 8 perform better, even though this was not the logical result.

In the above table we see a 50%-78% performance regression which is rather big. Do you think this is the expected result? Do you see any flaws in the above methodology? Am I missing something? At which phase do you think it would be wise to test again? Feel free to leave your comment below.

Anyhow, I hope the Drupal community will do a really good job at the polish phase and deliver a really fast Drupal 8.

About a month ago, I had the opportunity to present at Internet World London, why I believe that Drupal is the best Open Source solution to build professional level websites, e-shops or online applications and why you should dig in it and do your own research about it.

The speech is in English. You can enable the English or Greek subtitles by clicking the captions button or read the transcript below.

Presentation Transcript

Hello everybody, my name is Yannis Karampelas. I'm the owner and founder of Netstudio.

Netstudio is a Web Design and Web development company in Athens, Greece. I am Greek and this is the first time I give a presentation in English, so if what I say, sounds Greek to you, feel free to interrupt me and ask questions.

I started Netstudio 8 years ago and Netstudio got reputable in Greece for being able to tackle advanced online e-commerce sites, regular sites and online applications.

We got to a point where our development and design team got to build really big sites for Greece's standards.

So, about three years ago I thought that I should find a platform to base our work. Because until then everything we did was based on Joomla which is a free and Open Source CMS.

So, about three years ago I started researching my options in the Open Source field again and I started researching the CMS's. I got to see some of them, but what got my attention finally was Drupal.

The Drupal CMS is Open Source and free and the more I was researching about that, the more I got excited about the opportunity that lied beyond me,  because I had the experience what our clients wanted to do for them and I knew the constraints I had till then using Joomla and I got excited about the power I saw in the Drupal framework and the Drupal CMS.

So, I'm here today to describe to you the 7 reasons I think you should research Drupal and find out if it is the best choice for your site, your online shop or your online application.

So, let's start.

Reason Number 1

The number one reason that got my attention is that Drupal is really flexible.

Back when we used to use the Joomla CMS, it was very usual for clients to ask us to do things that we could not do not because we weren't good enough developers, but because the CMS did not allow us to do these things.

For example, when a client asked us to add a new field to his website, either we could not do it or we had to use external components like the K2 component or JReviews or another CCK component to build their website. But that was not always sleek and easy to do because sometimes these requirements came after the site was live, so it was not so easy to alter the structure of it.

On the other hand, Drupal has an inherent, in core Content Construction Kit that allows you to build your own Content Types with your own fields. Content Types are data sets of fields. For example, Joomla had only one content type, the Article Content Type, where you had the opportunity to input the Title of the Article, the Body of the Article, the Publishing Date and some other details. In Drupal, you can build your own content types and have as many fields as you like in them and you can add more fields even after your site goes live. So, for example, if you build your online shop on Drupal and at some point you think that you should charge shipping fees based on the weight of the products, it is very easy to add a new field to the product content type called weight and input there the weight of the products.

What accompanies most of the Drupal sites is an external module called Views. The Views module is the most famous one in the Drupal world because allows you to grab data from your database that you have build your own content types and build your web pages the way you want. So, it's not so clear here, but with the Views module, you can select the fields that you want, set your filter criteria and your sort criteria and build your web page the way you want to appear to your visitors. This is very powerful, so in the upcoming release of Drupal, which comes by the end of this year, the Views module will be inherent in the core of Drupal. Essentially, the Views module is an SQL Query Builder that allows someone who is not a coder to build the queries and get the data from the database and show them the way he wants to the visitors.

Another cool feature is that in Drupal you can have set of users which users have roles and each role can have its own permissions. So, you can set as many roles as you like for your site and allow them to do whatever you like them to be able to do. For example, you can build an ecommerce site and have some users have access to your wholesale prices because they are your wholesale customers. This is again something that you can do with a graphical user interface and most of the time you won't need developer help.

Another advanced and very nice feature of Drupal, is the Rules module which allows you to build our own custom workflows. For example you can tell Drupal to send a text message to the mobiles of your customers whenever they place an order. Again, using a practical user interface, you can build this rule and be able to customize it the way you need. To say the truth, some of these things need more reading and more advanced digging in the system and you might select to have your developer or your agency to build it for your, but after they build it for you, it is very easy for you to customize it and tweak it and make it work the way you want it to work.

Reason Number 2

The number two reason that I believe Drupal is a very good CMS, is that Drupal is search engines friendly. This is something very important for your sites and for the sites of our clients. So, when I started researching the Drupal CMS, I checked if it performs ok with the search engines. What I found out was that the Drupal community had built numerous modules that tackled this with paramount importance matter.

There are a lot of modules that help your site rank better, I could talk a lot of time about them, but I will talk only about Pathauto, which allows you to build the URL structure the way you want. So, for example, when you build a site with Drupal, you can put the articles of this site in the articles folder and have each article have its article in the URL. This is very important for search engines, but also usabilitywise for users because users look at the URL of your site and try to orientate themselves and understand in which place of your site they are. What we found out after migrating a lot of site from Joomla to Drupal and from proprietary systems to Drupal, was that right after we migrated them to the Drupal CMS, they had better rankings in Google. Here is an example about a Greek website where after we migrated to the Drupal CMS, we had almost 40% percent increase in search rankings and visits from Organic results. What we use to say is that Google does love Drupal.

Reason Number 3

Drupal is reliable and some of the biggest sites in the World use it. I got impressed when I started researching about Drupal that I found out that some of the biggest sites, like the US White House runs on Drupal. Or MTV UK. France24.com. The Louvre Museum. The Economist. The Grammy Awards site. ING US. Examiner. So, I thought that if these organizations depend on Drupal, then it might be ok for my clients and I could trust it as well. Here you see the growth that the most famous Open Source CMS's have at this time. As you see, last year, Drupal had over 20% growth in its usage. Currently, over 1 million sites run on Drupal.

Reason Number 4

Drupal is secure. Vendors of proprietary systems have an argument against Open Source systems saying that since they are Open Source, everybody could look at their code, scan the code and find vulnerabilities. This is true for other CMS's, but not for Drupal. Because Drupal has taken security very seriously and has formed a team of security professionals who actively seek and patch vulnerabilities in the system. Because they know that this system is used among the biggest sites in the world. And to tell you the truth, I have seen many WordPress and Joomla sites hacked, but we had never a Drupal site hacked, at least yet.

Reason Number 5

Drupal has an active community. Why is that important for you? Because almost one million people work to make this CMS better and they are there to help you either for free via the IRC channels or in the forums, or in a paid basis. So, it is very easy for you to find good developers, good development agencies and you are free to work with anybody you like and change agency or developer whenever you like. Also, there are over 20.000 modules that are ready for you to use for free and extend the capabilities of your site.

Here you see some pictures of some of the Drupal Cons, the Drupal Conferences that are organized around the year and you can be in these conferences. The Drupal Cons are twice a year, but there are monthly smaller conferences, the Drupal Camps and the Drupal Meetups that you can attend and see the vibrance and the kind of people that are here to help. This is from Munich.

At Netstudio we have built a lot of modules on Drupal and actually two Drupal distributions. Drupal distributions are sets of Drupal setups that you can get, install on your site and have ready and running in some minutes. We have built the Open Deals Drupal distribution, which is "Groupon out of the box", you get it, you install it and your site is ready, and most of all, it's free.

Reason Number 6

Drupal is innovative. The Drupal community is very active incorporating every new technology in Drupal. So, it was Drupal that had the first responsive themes, that I will show you later, it was Drupal that started implementing inline editing, which is a technology that will be ready in the next months and will be in the current Drupal 7 for you to use and also in the upcoming Drupal 8, which allows you to edit the content of your site, without having to go to the admin panel. From the front-end, where you visit your site, whenever you see a mistake, or a typo or anything, you can click edit and you can change everything live.

Also, the are antispam mechanisms like Mollom, which I would suggest you take a look, they are very advanced and not annoying to the users.

Faceted Search is a new technology about searching, where you can use multiple Ajax filters to pinpoint what you want to find, and I will show you an example later.

And Symfony2 is the next big thing about Drupal. Symfony2 is a PHP framework developed by another community, that now gets in Drupal 8 and in a kind merges these communities and things will go faster.

Here you can see our site built on Drupal how responds to different screen sizes. This is responsive design.

And here you can see an online shop where we have built Faceted Search on Drupal where you can click and with 2-3 clicks, you can find what you want among thousands of products. In fact, we have built an external module on top of the Faceted Search API of Drupal, called Findastic, which is very fast and very advanced.

Reason Number 7

Finally, Drupal is free and Open Source and you can download it today and try it and see what you can do with that. You can choose anybody to work on your site, you don't have to pay any licenses, or any fees, you only pay for development and design time.

So, for me Drupal is the perfect system. Have I researched every system there is? No. But from what I've seen is the best choice and I'll be glad to talk to everybody of you and see if it's a good choice for you as well. Thank you very much.

In early 2011 the world changed! That happened because Drupal 7 came into our lives and along with it Drupal Commerce, the brand new online e-shop tool. In the blink of an eye Drupal Commerce became viral creating a small sub-community on drupal.org and as a result a majority of Commerce oriented modules came to life very fast that expanded its capabilities furthermore. In Netstudio we immediately contributed in the Drupal Commerce ecosystem, not only with extra modules, but also with a Drupal Distribution based on it, called Open Deals. Drupal Commerce is widely accepted and trusted within the Drupal Developers community and managed till August of 2012 in London’s DrupalCon to cover almost every feature of Ubercart, which until then was an A-player for Drupal e-commerce solutions.

The problem

Even though as mentioned, Drupal Commerce covered 99% of Ubercart’s features, during its early lifetime showed a noticeable weakness that troubled a lot of the developers that wanted to use it on their web sites. The problem had to do with the multiple attributes per product which affected the final price. An example of this situation is the "pizza" product. Each pizzeria gives the opportunity to its customers to choose the ingredients that are going to be used in the making process and the final price is affected by each ingredient respectively. Until now Commerce handles this by creating each product’s combination as a different product in advance and by manually calculating each combination’s final price. If we assume that the "pizza" product has 5 different types of cheese, 5 types of sausages, 5 sauces and 5 types of vegetables then we had to create 5*5*5*5 = 625 different products! Each extra ingredient would increase by a great amount the number of the products that had to be created and also maintained. This is the main reason that even today many of the online shops are developed with Ubercart and not with Drupal Commerce.

The community's solution

There have been many efforts on a solution to the problem by the community of Drupal Commerce. Commerce Option Module introduced the product options idea and gave the opportunity to the site's administrator to create combinations of attributes. With this solution the administrator could then maintain a single product and the customer could keep combining the attributes on the final product. BUT, even though this was a respectable solution there were two unsolved problems. There should be the option of choosing different attributes per product. (for example some pizzas should have three possible cheese options available and some other should have two). Furthermore, and also the most important one is that there was not an option to affect the final price based on the attributes that have been chosen.

The Netstudio solution

In our company we have encountered many similar situations in the past year. Sometimes we were obliged to use Ubercart and some other times we had to implement custom solutions to comply with each demanded functionality. We finally agreed that there should be a more organized effort on building our own complete solution based on Drupal’s module system. Thus, Commerce Pricing Attributes was born. This module covers all of the possible situations of multiple product attributes. Each product can now have its own attributes and its own price per attribute. We achieved total flexibility as far as the product attributes is concerned and have marginally improved their management. Now, there is no need for maintaining hundreds or even thousands of products! So far, the module has received positive feedback and we have gathered some great ideas for further feature enhancement. You can visit the project’s page at https://www.drupal.org/project/commerce_pricing_attributes. We urge you to try it and send us your feedback or comments on further improvement. Here is a short video presentation of Commerce Pricing Attributes module with directions of the installation and configuration.

Sometimes we may have downloaded a dev version of a module because it has some fixes, or maybe he have applied a patch. So in order not to lose our changes in case of an update we must install this module https://www.drupal.org/project/update_advanced and then go to admin/reports/updates/settings choosing the appropriate module's row tab "WARN IF OUT OF DATE" set to "Never". Drush also respects the settings of the module and as you can see in the above image views does not get updated due to the exclusion from our module.

CAUTION! When we make a "manual update check" you may notice that the module isn't been checked but when we check it to be updated and press update, then the update procedure ignores the module's settings. So you have to be very careful in this case and in order to be on the safe side you should always update through drush.

In my case though I had a module which I found in sandbox and it doesn't appear on the list of our magnificent module. What should we do in case the module comes out of sandbox and drush updates it without our attention after we have applied a patch on it? Well...there is a very nice and neat solution. We exclude it with the below hook code:

<?php
/**
 * Implements hook_update_projects_alter().
 */
function custom_module_update_projects_alter(&$projects) {
 
$blacklist = array(
   
'my_module',
  );

  foreach (

$blacklist as $module) {
    unset(
$projects[$module]);
  }
}
?>

/**
* EDITED
*/
User "Si Hobbs" also pointed out a very neat approach to the problem also.
You just change the project name from the .info file of your module, let's say with something like "hacked_%modulename%" and you're done!

Altered info structure:

Updates list after alteration:

For those who don't know about Open Deals, it is a Drupal distribution that lets you build a deals site (like Groupon) with a few clicks. You just download it, install it and you are ready to get orders.

We started building the Open Deals distribution about a year ago. You can find the initial post about it here. We released the 7.x-1.1 version (after many alpha, beta and RC releases) just a few hours ago. Currently, there are no open issues and this is considered a stable release. So, I think this is a good time to recap this year.

First of all, let's make clear that we didn't build Open Deals for personal use nor for any client that had asked us for something like that. We built it for two reasons. To learn how a distribution is built and to attract new clients.

Even though we didn't have the number of requests and jobs that we anticipated, we did learn a lot of new things and most of all, we felt the pleasure that Drupal modules and distributions maintainers get when they see their work used by others.

At the time of writing, Open Deals is reported to have been downloaded more than 4.000 times and is used on more than 250 sites! One of them being the University of Arizona! (uasavvy.arizona.edu). We have built a small showcase of sites built on Open Deals at the project page. Seeing your work used by others is indeed a rewarding experience.

Last but not least, Open Deals got us to know a lot of Drupal folks from all parts of the world who contacted us either via our contact form, via Skype or via the project's issue queue asking for support. That made us realize first hand that Drupal is indeed a global project. Internationalization at its best!

So, if you asked me if I did it again, the answer is Yes! If you asked me if you should do it, I'd say "Go for It"! It's not about money. It's about the rewards mentioned above.

Open Deals

Recently, I had to debug a lot of watchdog entries in a client's site. In order to better understand the meaning and cause of each entry, I had to copy the IP address that generated the notice or error and paste it in a DNS Resolver to check who or what was the visitor that generated it. It's easier to understand crawl-66-249-66-212.googlebot.com than 66.249.66.212. I thought that instead of doing this repetitive task, it would be much more helpful to see the hostname besides the IP address. But there is no such option in Drupal 7. So, I coded a very simple module that does just that. Shows the hostname besides the IP address. I uploaded the module at Drupal.org. If your site is built on Drupal 7, you can download and use the module for free at https://www.drupal.org/project/resolveip.

I recently posted on a developer discussion forum our view on Drupal 7 vs Joomla 2.5. I repost here:

Let me present my view on this issue after having worked with both systems extensively. Since I worked alone as a freelancer until our team got to have 6 full-time developers.

We used to work with Joomla since the... Mambo times (7 years ago) and until one and a half year ago. We had reached a point where we developed for Joomla advanced e-shops, online apps and that included development of many components, plugins and Joomla modules.

It's been one and a half year that we switched to Drupal. This change wasn't an easy decision, because when you have conquered a CMS and you have to learn a new one, the time investment is just this: AN INVESTMENT. Along with whatever that means. But we did switch and we didn't regret.

What do we like on Drupal?

First of all, its absolutely more collaborative community. On Joomla every developer built and promoted its own component or module essentially competing with all other developers of similar components. For example, there are over 50 photo galleries. On Drupal on the other hand, everybody work together to build a very good and complete module for each task. This got us excited and made us contribute to the community with a lot of patches, new modules and a new distribution (Open Deals).

Secondly, what we liked on Drupal and fitted very well with the way we work, is that the pieces (modules) that make up a website are smaller. For example, there's no photo gallery module for Drupal. But the combining parts of it (e.g. views, views slideshows, CCK) are there to use and build your own photo gallery just the way you want it. That means that you may need more time to build a site, but you have more flexibility. Even more, every module used is easily overrided from your own modules' code, without having to "hack" them.

Finally, what we found was that the Drupal community seemed to be able to provide solutions for high traffic and more demanding sites issues (caching, performance, SEO) that were more difficult to find among the Joomla community.

To sum it up, Joomla is fantastic, but Drupal got to cover our needs in a better way.

Anyway, both systems are free to use, so every user can explore them, compare them and choose which ever is best for his particular project.

Σελίδες