Two days ago I decided to support the Associazione Drupal Italia (Drupal Italia Association), subscribing and becoming a supporter member.
This is to support the guys back in my country who really are dedicated to this platform. Hopefully this association is going to make the Italian Drupal community stronger and larger, and I also hope to stay much more in touch with the Italian community despite living abroad.
Let’s keep in touch guys, and good luck to everyone.
I love Drupal. I really do, even if many people do not understand why (one day I will explain to you what you don’t see, guys). I’ve been working with it since the version 4.6. Then, during the 2008/09 I stopped for like a year (for many reasons that are not worth to be told), but eventually I came back aboard, and now I am also the “specialist in charge” for this platform at Ibuildings.
For a long time I never had the chance to contribute “seriously” (just some little patches here and there) in the community, but now different working conditions allow me to do so. This brought to my attention some issues in the community attitude. And when it comes to social attitudes, I am not an easy person to deal with when I get disappointed.
A few days ago, I have announced the Alternate Content Copy module, which hopefully is going to be accepted on the Drupal.org project repository (as soon as I submit it).
In that article I explained the general reasons why those modifications should be part of the official Content Copy module.
Now, I do realise that Fields in D7 might be so different that everything I am about to say could not make any sense in the near future. However, I would like, with this article, to explain why the programmatic update of CCK content types does benefit of my modifications.
Not long ago, I published a HowTo for creating CCK Content Types programmatically, including the ability of updating them via code. After some events, the HowTo needed an update, as it now (necessarily) depends on the Alternate Content Copy module.
Eventually, markus_petrus did not want to change the current behaviour of the CCK Content Copy module. Therefore, out of box, it won’t allow you to use my way to get CCK content type done programmatically (well, not including the update of them). But let’s forget about this for now. Let’s focus on CCK and the Content Copy module.
UPDATE 02/12/2009: this patch is out of the date, please refer to the Alternate Content Copy module now.
A few days ago I wrote a HowTo for creating CCK Content Types programmatically, including their update. Unfortunately, I must have missed something in my tests, so I found out later on that the updates won’t work properly.
This is due to the behaviour of the CCK import procedure, that skips already existing fields, so these don’t get updated. Plus, it also keeps fields no longer available in the updated content type definition, i.e. you cannot drop fields either.
I submitted a patch to the content_copy module, which turned up to be kind of a duplicate. Now the discussion is going on here, and my latest comment (including my patch) is here.
At the moment, Markus does not seem keen to include this patch, or any similar one, at all. We’ll see what happens.
In the meantime, I am using an alternative approach, because I don’t like to have patched modules in my installations. Basically I wrote a module called custom_content_copy that implements an alternative submit handler for the Content Copy import form. This way, you just need to install this module alongside of the content_copy module provided by CCK.
If you want, you can download this module here:
Custom Content Copy. Please refer to the Alternate Content Copy module now.
Update 28/11/2009: you need this patch to make this working 100%.
The fundament of Drupal is the node entity. In drupal (almost) everything is a node, which is the most elementary piece of content available, that can be “extended” to create new node types, also known as content types.
When you create new Drupal content types in the “classical” way, you do that by creating a new module. This way a content type is portable across different Drupal installations, just by copying and enabling the module in a new CMS instance.
Originally this was the only way to create content types. Then, CCK was created and it changed the life of many people, especially of those who use Drupal just as CMS. However, these people tend to create content types by means of the UI provided by CCK and to store them into the DB. This way a content type is not portable. Plus, it is not really friendly with complex development scenarios where Drupal is heavily used as framework and the code must be deployed across multiples environments.
Fortunately, we can achieve the same flexibility of the classical method, and more, taking advantage of all the CCK features, including the built-in integration with Views. Let’s see how. All you need is the latest versions of Drupal 6, CCK (and, optionally, Views).
Seriously, I can’t believe the trend of this poll. The question is
What PHP software would you typically use for an extranet type application (with user content, logins etc.)?
and (so far) 24 votes have gone to this answer
Custom built (with a framework)
not to mention those three who have voted:
Custom built (from scratch)
So, basically, people are telling me that for deploying an extranet application they are really willing to:
All this, with the burden of thinking about CRUD, Forms, and tons of other annoying and repetitive problems already solved by a Content Management Framework (not System, Framework) such as Drupal (or something equivalent, if it exists).
At the end of the day, 24 people are stating that they prefer to spend months solving well-solved problems once again in their life, to deliver a poorer and, almost certainly, more buggy, ad-hoc and — very likely — inflexible application; instead of spending weeks focusing on the customization and improvement of a powerful platform in order to match every single detail of the customer’s needs, ending up with a high quality, flexible, extensible application, with a much lower risk of critical bugs.
You’ve got to be kidding me.
ConsumerSearch.com is a website with a huge traffic. According to what Dries Buytaert reported is his post, this website gets 5.5 million unique visitors per month (and growing).
ConsumerSearch is a part of About.com group, a subsidiary of The New York Times Company.
With this post I want to provide you with a comprehensive list about Drupal-Powered websites. I will probably be never able to review every single website built with Drupal, so the lists you find below could be very useful. However, some of the sites you will find there are likely to be covered in my next posts.
Dries Buytaert is the original creator and project lead of Drupal. And of course he maintains a list of Drupal-powered websites himself, which is likely to be the most comprehensive resource about “large websites built with Drupal”.
Another interesting list is this one, which focuses on those websites which don’t look Drupal-based at a first sight.
You will find there some unexpected names.
A brief list of interesting Drupal-powered websites by Jeroen Coumans
DrupalSites.net is a directory that lists any website powered by Drupal. A very large list not focused on a particular type of websites. Currently, more than one thousand websites are listed there.
Hello, this is Vincenzo, I am a computer scientist, a Web engineer, a passionate and enthusiastic developer, an HCI passionate, and, sometimes, a Machine learning researcher. I currently hold a permanent position as Software Architect at The Economist Group, in London. Learn more about me.
Recent Comments