From time to the time, the topic of forming a new slogan for Drupal is coming up again and again. Admittedly "Community plumbing" might be a bit worn out. One could only wonder if a new slogan is part of the drupal.org redesign underway now or not.
As with lots of hobby projects, things could just drag on without much progress, if you don't sit down and just do it. It was the same situation with Weblabor.hu, the site which got me to use and heavily contribute to Drupal (4.3 originally). Unfortunately I only had the time to keep updating the site up to Drupal 4.6 and the long cycle around Drupal 4.7 and my heavy involvement with other things (such as finishing off studying for my MsC degree) dragged me away from taking care of the site.
Almost two years ago, I have started to work on an upgrade of the site to Drupal 5. That was "of course" never complete, so early this year, I've started to push for updating it to Drupal 6 finally, and got momentum among the other editors/managers of the site, so we worked hard in the little spare time we had to get it to launch. Our efforts reached the actual live upgrade this past weekend.
Because our first priority was to relaunch on Drupal 6 instead of 4.6, we dropped some of the less used features, avoided toying too much on the design, and concentrated on retaining data and getting the site run on a modern backend system finally.
One interesting thing I developed way back in 2007 however was the direct update mechanism. Drupal 6 lacks some of the old update functions, so I needed to copy them back, and there were two places where I needed to patch the old update functions (avoid menu_rebuild() too early before the new menu system is in place and avoid calling node types from the database before they are in there), but otherwise it was a great experience to just copy the old Drupal 4.6 database, hit update.php and the whole update process just run.
Due to the timing of our update efforts (and our diligence to update to the latest and greatest Drupal versions, given that we might not have time to do so for some time again), we were in the unfortunate position to never be able to use CCK and Views, due to no stable releases available of these fine modules. So if you expect a nice use case of porting 4.6 custom stuff to CCK and Views, I need to disappoint you. What we did, is that we ported custom node types to the build it node type system, we ported our custom file upload code to the since then built in upload system and a custom filter for Drupal 6, so that our attachments included in posts will still work. We kept custom code to list stuff in our jobs section or in our books area though. In cases when modules were available however, it was just so nice to be able to get new features developed through the past years by others. Oh, the wonders of building on an open source framework!
One interesting tidbit is that we keep using the tracker style which was available way back up to March 2004. This old style tracker lists comments to a post, compared to just listing their numbers in a boring table. This also allows displaying individual read information for users, as shown on the picture. To my best knowledge, this was removed due to performance reasons. Querying all related comments for all displayed nodes takes some power for sure. What we did to remedy part of the issue is to hide most read comments on long threads for logged in users, so they get a more compact view and the site eats less power.
We almost kept our self-promise to not add new features. One small new feature we've added however is of great help to site admins. Inspired by Flickr's in place title and description editing and by the doubleclick Drupal module, we've developed in-place editing for node titles, so we can touch up quickly on mistakes and typos. This feature consists of a little bit of code on the theme to mark up editable titles, JavaScript to replace titles with an input field, some AJAX to send it over to the server and a very small module to save the node title coming in (if the user has permission to change node titles). It would be a piece of cake to contribute to the dblclick module but the only problem with it is that it is heavily theme dependent. How you put the input field into the page depends highly on the markup used to display node titles, and that could vary quite a bit on different sites. I'll try to find the time to write up an article about it though.
I am happy to see almost two years of little bits of spare time work pay off, and I am hopeful our efforts will help put Weblabor.hu on a growth path again.
Ps. The logo in the site header is one we actually created in real life (although it did not become as good as we hoped it will be).
Drupal.org (and its whole site family) is being redesigned, thanks to heroic efforts by the Drupal Association. The site family grew quite big (and is still growing) so there is a lot of stuff to do. You probably have your own gripes on how it should work, so now is the time to get involved! Just as you'd expect from good architects when redesigning your home, Leisa and Mark are running a series of blog posts (just watch Drupal Planet to see them) to discuss details of the redesign, and understand our needs. Anyone can put in their opinions, and it is their job to filter it down and produce useful results in a relatively short time.
I started contributing with a one-on-one interview with Leisa at Drupalcon Szeged 2008. This event was a good opportunity to interview lots of different type of people on how they use the site, what are their problems and happy moments with it. If you have not been to Szeged, or have not been able to get an interview, there is no reason to step back. You can also contribute with comments on various blog posts (just as I do), taking part in the online card sort and submitting your own wireframe suggestions.
I've just decided today to sit down and make sure my opinion gets into the pipe, so I submitted this simplistic wireframe (click on it and get to Flickr to see the notes):
My goal with the suggestions is to get rid of the blog-look for the home page and get prime-time for more important stuff by highlighting them by topic area. We don't need such a long explanation on what Drupal is, if people can instantly see, that Drupal events are happening near them, they can buy books to hold in their hands, people build cool sites with Drupal and they can earn money with Drupal as well, within a thriving community, which takes software and security seriously. If you break this sentence down, several boxes come up for the homepage to highlight security bulletins, showcases, the Drupal Planet, events, and so on. These all describe Drupal's several aspects themselves, leaving the intro itself to a short explanation. I believe this kind of hub homepage would finally get us to a state where we can tell people to just go to the drupal.org homepage and get a decent overview of Drupal.
Do you think you can do better then me or have other ideas to get highlighted in the redesign process? Why not participate? Come wireframe with Leisa.
Packt Publishing is continually coming out with Drupal books for different verticals. They have a "Drupal for Education and E-Learning" title coming up, they sell the "Drupal Multimedia" title, and they are spot on with "Selling online with Drupal e-Commerce". Their target is the beginner who might have chosen another e-commerce software, and would only choose Drupal if directed from start to end to build user registrations, static pages and the e-commerce functionality itself.
Interestingly the original announcement of the book on Drupal.org spurred a lot of "why a book about a dead module, write about Ubercart instead". But this book is a testament that Drupal is really open, and the two competing (huge) module sets for e-commerce: Ubercart and e-Commerce are both moving along and worth evaluating.
Coincidentally I got this book for review just I was about to build the registration cart/wizard/payment interface for Drupalcon Szeged. We were in talks with Ryan Szrama from Ubercart who was about to sign up to help out with our payment system, I've been reading the book on the competing module suite, and at the end decided to assemble a custom built Signup, Signup Status and Simple Paypal modules based solution. I would not suggest you to go on a custom module set route unless you see your requirements really clearly, and feel adventurous enough to build an exceptionally tailored system for your own needs. (In our case, it turned out that our model was not as fitting to practice as we thought so, and an Ubercart / e-Commerce based system might have been a better fit). Generally, I'd suggest you to just grab a cookbook like this one and play along.
Because this book starts from the beginning and builds up a shop from the ground up, it will be useful to you even if you are not going to use e-commerce, but instead would take Ubercart. Some concepts will be a bit different, but you'll get an understanding of the issues involved with building a shop, including permissions, roles, branding, tax rules, payment and shipping details, securing sites and marketing the business. There is a lot of value in this book for beginner Drupal site builders beyond dealing with the e-commerce module itself. Basic concepts such as Drupal content and user management are explained, so that you can just take this book without buying a few hundred more pages on generic Drupal site building. On the other hand, appropriate contributed modules like Taxonomy Access Control, Image, Image Attach, CAPTCHA, Legal, Login Security, etc. are used and explained briefly where necessary. Of course this also means that if you need specific information on things such as Drupal theming, you'll need to refer to other resources, but that's not a pre-requisite to building a shop, right?
All-in-all, I'd suggest you to read this book, if you are a Drupal beginner looking to set up shop on the internet, or a somewhat experienced Drupal user, who never built a complex e-commerce site yet.
A little bit before Drupalcon Szeged 2008, I was invited to take part in Lullabot's event, called Do It With Drupal. Being a co-lead for Drupalcon Szeged, I was completely overwhelmed with organization stuff there, but now that it was well done, I can move over to planning for future events.
Do It With Drupal is going to be held in New Orleans, mid-December this year, and is basically a three day training event. Or as the FAQ puts it, it "is an expansion on the Lullabot workshops. Attendees can get much more in-depth and topic-specific information [compared to] the workshops. [...] Do It With Drupal is a very learning-focused event." I was invited to speak about multilanguage solutions, and I am going to again join the company of speakers such as Earl Miles, Karen Stevenson, Ryan Szrama, Moshe Weitzman, John VanDyk, just to name a few.
This event is quite a bit different to a Drupalcon, Do It With Drupal works with invited speakers whose hotel rooms and some of the travel costs are covered, and this is offset by having quite a bit higher entrance fees for attendees (starting at $795) on the other end. While Drupalcon's are characterized by anyone being able to be involved via BoFs and adhoc meetings, this event is about cherry-picking mainstream topics and closing in on them, so you get a different and very tight focus. This is the first event of this kind, and I am excited to see how this model works out. I am looking forward to be there and be involved.
As it turns out István Palócz, a lead in the Hungarian Drupal community was just energized again by Drupalcon Szeged 2008, and would not let the Hungarian community to skip this year's Hungarian Drupal Conference (you might call it a Drupalcamp). He already announced the date to be November 15th, and the location to be the usual Central European University Conference Venue in Budapest, which was the host of our previous local Drupal conferences the past years.
Dries said (again) in his State of Drupal keynote this past week that a whole lot of people want WYSIWYG editors in Drupal. He also highlighted FCKeditor as the most popular one used for this job in the Drupal community (based on call-home data from Update Status module). So you'd say this is just too easy, move FCKeditor to core and we are done. Well, going the simple and quick way would just alienate those from RTEs (another nice acronym for these editors), because these editors are just too aggressive when it comes to pushing themselves to your face.
The assumption in these editors is to treat all textareas as fields with HTML input by default, so you'll obviously need the HTML editor on them. But this is not the case. In previous times, if you installed an RTE, and went to a block's configuration page, the textarea where you can provide a list of paths on where the block will show/hide was taken over by the RTE. Through time, the RTE authors realized this is a problem and built in tools to limit their reach. If you look FCKeditor's profile editing interface (image on the right), you'll find settings to exclude certain form item IDs from FCKeditor's work. But who knows the form IDs? Well, FCKeditor authors built a tool which tells you about the form IDs on forms, eg. on the block configuration page, it says: The ID for excluding or including this element is: edit-pages - the path is: admin/build/block/configure/user/1. Then if you need to modify your configuration on this field, you need to remember these values, go over to the linked "excluding or including" page and alter the list of items there.
There are a couple of flaws with this approach:
End users need to deal with (internal) form item IDs to configure their site for forms which are not covered by the default settings.
What guarantees that "edit-pages" will not be used as a form ID for HTML input in another form? Nothing. If we block it out, we block it out in all forms.
Blacklisting keeps textareas open to FCKeditor by default, so if a contrib module comes requiring text input in a field, there is no way to tell RTEs not to process that field, the user will face the pushy RTE and submit a bug against the contrib module such as http://drupal.org/node/293502 (and will get users hack as hell).
If this all was not enough, FCKeditor also has a simplified toolbar view, which is used for text input using the filtered XSS admin processor (when input format is not selected, but some HTML is still allowed). Again end users set up which textareas are using this method (beyond some defaults included). How they get to know that? Well, trial and error, or they need to look into the code.
All these ugly hassles for the end user, while we programmers know exactly that input from a textarea will be plain text (eg. email text, a list of paths), passed through filter XSS admin or filtered via one of the input filters set up. Not only that, but we know if a textarea is passed through input filters and the particular input filter used escapes HTML, it is pointless to display an RTE for HTML. So it is not only the page the textarea was displayed on, it is not only the ID of the textarea, it is also the properties of the selected input format for that textarea (when applicable) which defines whether FCKeditor should be there or not.
These are all things programmers can tell Drupal about without any user interaction, completely removing these settings and making WYSIWYG editing really seamless for the user. How do we tell Drupal what type of input is on the textarea? Well, we tell it to use a specific format. There are two competing proposals on how this should work, both in the issue: Textarea with input format attached. If you care about WYSIWYG editors in Drupal core (for Drupal 7), please help do quality reviews and provide feedback on the approaches proposed. This is a prerequisite to making RTEs integrate seamlessly to Drupal.
In the craziness which was this summer: moving together with my fiancée, redoing the kitchen, co-organizing a fantastic Drupalcon, I've even managed to get married with the love of my life and go on honeymoon. Dries Buytaert also posted some great photos on his blog, but I figured I'd share some of the photos we got done before the ceremony, and some memories we had from Prague. Our wedding was a great day in our life, and the greatest was of course that we have been able to be together for a week's honeymoon after that in Prague.
If my session makes it (vote!), and you come to Drupalcon Szeged (you should), I'll teach you how can you convert an existing HTML/CSS template to a Drupal 6 theme in a matter of 45 minutes, with the full live demo from the ground up included with instructions. I've managed to do this before, so I am confident it should be lots of fun. We will break our Drupal site numerous times, and learn to live with it while the tough time constraints are looming on us, and should of course get to a gorgeous end result. We will convert the Modern World template by Solucija and will get to a Drupal 6 theme with blocks, menus a theme screenshot and all.
I'll also tell you how can you contribute the theme to drupal.org or through other means if the template license does not allow you to upload to drupal.org. This is of course not a requirement, since you might as well only work for your own client. You decide!
Just make sure to vote on my session, to help me get into the program and come to Drupalcon not only for this great session, but all the other fun programs which are on offer. You definitely should not miss it!
After three years of being happily together with my girlfriend (fiancée since almost a year ago), and while planning for a lot more, we decided to officially join our lives and proclaim that for the bigger public. We are getting married on August 9th, and will be out of the usual tech loop and away from other things in life for a few days after that.
The assumption in these editors is to treat all textareas as fields with HTML input by default, so you'll obviously need the HTML editor on them. But this is not the case. In previous times, if you installed an RTE, and went to a block's configuration page, the textarea where you can provide a list of paths on where the block will show/hide was taken over by the RTE. Through time, the RTE authors realized this is a problem and built in tools to limit their reach. If you look FCKeditor's profile editing interface (image on the right), you'll find settings to exclude certain form item IDs from FCKeditor's work. But who knows the form IDs? Well, FCKeditor authors built a tool which tells you about the form IDs on forms, eg. on the block configuration page, it says: The ID for excluding or including this element is: edit-pages - the path is: admin/build/block/configure/user/1. Then if you need to modify your configuration on this field, you need to remember these values, go over to the linked "excluding or including" page and alter the list of items there.
