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.
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!
Looks like people are finally realizing the enormous business opportunities lying in doing themes for Drupal sites. There is the http://www.topnotchthemes.com/ team building truly nice themes with support for common modules, knowing Drupals ins and outs.
At the same time http://www.templatemonster.com/ is picking up Drupal in their CMS section, selling Drupal themes for all kinds of focus areas. Although some of their demos have the "Mambo license" menu item running, which is quite frankly not a testament to their understanding of Drupal. However, starting off from a ported theme could still be nice, those buying Drupal themes might not want to fiddle as much customizing the theme further (update: and there are possibly other problems my soft blogging style did not uncover here, see: http://www.drupal4hu.com/node/146 and http://www.drupal4hu.com/node/141 for notes).
If you'd be interested in ported themes though, you might want to just start off from a theme downloaded for free. There is a new site coming up, started by a Hungarian Drupal enthusiast Ádám Boros. He is going through some of the exciting existing HTML templates and converting them to Drupal themes, providing for you to download for free. Why another theme site, you might ask? Why not just submit to Drupal.org? Well, although free to use and take, some of the HTML templates are not released under the GPL, so they are not suitable for submission on drupal.org. This requires people to either host them on their own site, or go centralize to a location. Ádám's new site, drupal6themes.com aims to not only host Ádám's work but also provide a platform for others to submit their Drupal 6 compatible themes and host them there.
I am extremely happy to see all these theming businesses and the expansion of the available themes to come together, and hope the growth is going to be even bigger going forward.
Critical Mass is an event which is held two times a year in Hungary (as well as sometimes more often and at varying times around the world), where bicyclists and other self-propelled commuters take to the streets en masse to demonstrate that biking is a good way to commute. Budapest's Critical Mass grows by each event in size, last fall attracting 70 thousand bikers, this past day having 80 thousand riders throughout the day.
Critical Mass 2008, Budapest (spring) photo by zsoolt
What's great about this event is that the Critical Mass Hungary community site runs all on Drupal for the past few years, and the community is happy about it. It is great to see all these activity helped by Drupal, especially that this fine system is used on many of the other local biker sites for bicycle trading, dispatch riders, bike camps and several bikers associations. Another good cause where Drupal helps build a better world!
Also special thanks for the biker community who brought in some money for our Drupal Conference Hungary 2006 and then bought a camera for the last Drupal Conference 2007 for the Drupal User Group to use. This allows us to post videotapes of the presentations we have at our user group events ever since.
This beautiful Monday morning, a few little presents arrived to the Drupalcon Szeged 2008 website. First entry to the Drupalcon Logo Contest from Ivan Raszl, who based his design on the floral patterns of traditional Hungarian embroidery, porcelain and furniture design. He even went ahead and created some renderings of the logo on several swag and even outdoor advertising. Not that we would be there already to do that for Drupalcons.
In other good news, people from as far as India and Australia are planning to come. Caitlin Johnstone is looking to discuss child care in her forum topic Anyone else looking for childcare? As she explains:
Are there any other Drupal families out there going to Hungary? We thought it would be a good one to bring the kids to since it'll be a bit more intimate than usual, but we need to organise some childcare on the conference days.
Bar bringing someone, I was wondering if we could hire a nanny over there, or perhaps even organise some kid-happy programs if there were enough other families planning to bring their little ones.
Let's see who else is interested in nannies, so that we can suggest and/or help you find suitable service. Reply in the forums.
If you look at the Drupalcon Szeged 2008 website's tracker, you'll see that most announcement posts are attributed to me. This is all too misleading, because in many cases, I am merely channelling information collected and discussed by various organizers to the public website.
This is the first Drupalcon for which the organizers have set up a management website, with the sole purpose to serve the organization team as good as possible, and while it is certainly not perfect, it works well so far. The "Do Drupaltown" website uses the core profile module, the organic groups and casetracker modules, as well as some small helpers like comment upload, upload preview, markdown with smartypants, diff and of course OpenID. Nothing earth-shatteringly special, just trying to work out easy ways to collaborate.
The two basic requirements were to have work groups for specific tasks, in the name of limiting scope and handing out responsibility. An event organized with a thousand attendees expected has so many aspects it is very hard to have a good overview of each aspect. So we have an organic groups setup with some top level groups and several focus groups for tasks like producing (valuable) materials for the registration packages, discussing and solving venue tasks, and so on. Because in numerous cases, we need responsibles to hand out tasks to, organic groups nicely fits with its concept of group ownership and memberships. It also supports mailing updates when new content is published, which is good to drive idle volunteers to the site when things are happening.
Since we are tracking tasks, these also need to have responsibles, an importance level, and a completion status. This allows us to have a running list of important tasks to complete, which helps us focus, know about the status of different jobs and get a distributed team to do that. Case tracker helps us there, it does integration with organic groups, so we can relate tasks to groups, email updates to tasks are mailed and severity and status flags are supported. We also have a patch pending for the views integration to be able to order by task priority, which was a trivial thing we needed to produce lists of tasks from most important down to less important.
Given how distributed our team is (only some people onsite in Szeged, lots of others are around the country elsewhere, while some volunteers from as far as Prague or Belgium), we need a way to reach any given member of the team when we are in a pressing need. We use the core profile module, which provides enough features for us to collect skype names, phone numbers, living locations, and so on, and it builds up a volunteer overview page, which gives us instant access to the contact information of anybody in our team. The only little glitch with profile module is that the number of volunteers grew above 20, so it does not fit on one page by default. Talk about sweet problems...
All-in all, our volunteers are happily working towards completing our goals, and we are marching on to come out with new exciting things for you regularly. Now that the public website of Drupalcon Szeged 2008 is building out, you will notice the volunteers themselves more there too, not just through my filtering.
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.
Given how distributed our team is (only some people onsite in Szeged, lots of others are around the country elsewhere, while some volunteers from as far as Prague or Belgium), we need a way to reach any given member of the team when we are in a pressing need. We use the core profile module, which provides enough features for us to collect skype names, phone numbers, living locations, and so on, and it builds up a volunteer overview page, which gives us instant access to the contact information of anybody in our team. The only little glitch with profile module is that the number of volunteers grew above 20, so it does not fit on one page by default. Talk about sweet problems...