After 16 years, I was back in Brussels for another FOSDEM last weekend. Back then, as the lead maintainer, I presented about the brand new Drupal 6 version. Now I revisited the pieces that made the Drupal 8 Multilingual Initiative super successful (dedicated post about that coming soon). That reminded me how much I used this website and other custom websites to support initiatives I worked on, and how I neglected to take care of the site in recent years. I wanted to move a bit forward, and kind of got carried away in the best way possible.
(Disclaimer: Dries did not ask/order/suggest/request me to post this neither to make any changes whatsoever.)
I was reading Drupal Confessions with great interest, because my primary job for quite a while now is to help enable the best efforts in the Drupal community to work together to reach new heights. I am really privileged to be able to do this and make a living out of it, it is the job I always dreamed of. I also hope that I am being useful to the Drupal community in doing so. I kept nodding in agreement with the open letter's statements on diversity so I could not get rid of my cognitive dissonance on their connection with reality for several days now. The open letter says "We ask you to fight for us, Dries, to protect us from intolerance, harassment, smearing, bullying, and discrimination, no matter why or where it originates from."
As someone who is getting a paycheck at least indirectly from Dries in the past 10 years, and working as directly with him as possible in Acquia's Office of the CTO for the second half of that period, I have the opportunity to look at his practices in terms of diversity. Which would be the most observable group to learn more from if not his personal department where he directly appoints people?
In the past 5 years I've been closely working with Dries as a remote employee in the Office of the CTO at Acquia, which consisted of 15 people at most at any given time. In this time I worked with at least the following types of people directly in this group (in random order): blind, stutterer, person with ADHD, person with serious sleep problems, person with even more serious sleep problems, divorced, gay, bi, lesbian, asexual, polyamorous, gospel singer, BDSM, religiously raised, atheist, clinically infertile, cosplayer, very tall, short, people from Eastern Europe, Western Europe, US and India, native-borns, immigrants, people in offices, people always working remotely, capitalist, socialist, pacifist, people from a military family, adopting parent, transgender, people with tics, people who don't drink alcohol, etc. The teams I worked on usually had relatively high percentage of women in technical roles. My current team is 50% female, and 1/3rd of the department overall is female. This could not happen by accident.
While none of this represent the whole rainbow of humanity, and it could definitely be further improved, our limited group of 15 people already covered outstanding diversity in my view. Also this is a group that cares, we discuss and live through our struggles and support each other on every step where we can. I would challenge many of those signing the open letter to practice this kind of diversity in their teams. I for one really enjoy the varying values that people brought in and am sad that some of those great people have left to pursue other technical challenges.
In this five years, I never experienced that when hiring people either of these things were considered as a negative or that any person was treated or felt treated badly for any personal life matter. Neither that any of the amazing people who unfortunately left and are covered in the list left because of any of those.
Given that I just cannot get over my cognitive dissonance. Who are being convinced of what?
I finally stopped putting it off and took the opportunity to test myself on the Acquia Certified Developer exam. To be honest I put it off for quite long. As a household name in the community I had fears it will prove I am not good enough and funnily enough, I did worst on back end development (ooops!) and 10% better on site building. My overall result is actually the same as Angie Byron at 85%. I'm flawless with fundamental web concepts at least. Ha!
As a computer science major who transferred into more of a mix of development, leadership, events and content production, I don't have much of an experience with tech certification exams. My only encounter was with the CIW certifications 13 or so years ago, which I took back in the day to be able to teach the CIW courses at a local private school. Judging from that experience and common wisdom, I expected paperbook style questions where I need to know the order and name of arguments and options on
l() as well recite row styles of views and available options of date fields. The reality cannot be farther from that.
It was about time for both moves, right? Yeah!
I've first experimented with moving to Drupal 7 on a copy of my blog this January, and that went relatively well. I've had issues with one node module update function and non-unique entries in my files table, but the inconsistent data issues I fixed myself, so the update went smooth. However it did not go live due to hosting and other issues. Of course I don't need to look too far for hosting, Acquia provides fantastic hosting offerings, and just using the cloud hosting product for this migration turned out to be a pleasure. The version control based automated deployment, drag and drop workflows and the availability of command line tool power combined made me able to migrate my blog in a couple hours (with the DNS turnover taking what felt like lots of time after that).
As with all updates, I took a long look at the modules I'm using, and decided to drop some. I've dropped the Feeds module setup for twitter aggregation that I've set up in 2009. I still intend to tie in twitter, but that setup was too much for this simple task. I might end up porting the Aggregator item promotion module that was originally written for the drupal.org redesign but then went unused, to Drupal 7. I've also dropped tagadelic and my flickr feed.
On the other hand, I tried to give more strength to the useful content I have, so decided to create a book module powered compilation of my multilingual Drupal 7 article series for easier navigation. I also believe that this simple configured version of the Bartik theme gives more room to my content and is overall cleaner and more professional compared to what I had before.
Hopefully I'll have some time to tinker with this new setup as time goes and improve it continually. So far I'm definitely satisfied with the results and believe it will be better for my readers as well with the speedier service and slick look.
I'd like to hereby thank my previous provider, hoszting.com for the hosting space they've provided me with over the years.
Back in the day when I was a college student, I was participating in "technology roadshow" events around the country presenting Drupal to various people. At one occasion, I presented to primary school and high school teachers and surprisingly, one of the teachers from my old high school was there, interested in the topic. We explained with my co-presenter István Palócz, that Drupal is free (as in speech and in beer), and that they can just install that for their school (as István did at that time), and use as an intranet or their public facing site.
I've been involved with Drupal localization since the early times I'm with Drupal and was looking at ways to keep improving language and translation setup. Still, if you need to install Drupal 6 localized, you need to download Drupal 6 in English and when prompted in the installer, go and grab a package for your language. That has a structure resembling Drupal core itself, and if you extract it to the right directory, each translation file will fall into place. Then if you go back to install Drupal, it will go localized.
While many people learned the tricks of the trade, this is not entirely easy. Extracting packages to the same directory as Drupal core is not easy on the Mac, where this ends up by directory overwrites by default. It is a confusing experience for newcomers on various operating systems, because merging two packages by extracting to the same directory is a (clever but) foreign concept. But if you think of it, we tell you to download a file from a well known place, let Drupal know about it and then import it. Why wouldn't the installer download the file and import it for us? With the advancement of http://localize.drupal.org/, the contributed module and theme translations are also decoupled from the projects, so there is even more user effort in obtaining translations for them, while this could all be automated.
This thinking drove to the birth of the Localized Drupal install profile, which is now available in proof-of-concept form for Drupal 6 and 7. The user interface for the installation could definitely use some polish as we need to let you choose from the 70 languages available on localize.drupal.org, but honestly, localized installations should not be harder then this. Let's take it for a spin!
Installing Localized Drupal 7.x-dev
In both versions, you'll be presented with a "Localized Drupal" selection among the install profiles. You need to select this to take advantage of the automation provided. This is due to the architecture of installation profiles. A library component is planned for this profile, so that other distributions can include the code needed to start installations off in a foreign language, but for plain Drupal core installation, you'll need to choose this separate profile.
You'll need to choose your language of course, but you should not be required to do anything else beyond that. This is it.
Localized Drupal 7.x-dev just installed
While this might provide immediate installation simplicity, for contributed modules to provide similar ease of localization installation and updates, Jose Reyero is hard at work on the Localization update module. Think of this as the install and update module for localizations. The Localized Drupal install profile is moving towards including and utilizing Localization update for an overall pleasant localized software experience. As soon as you add a couple contributed modules and a theme, you'll find it much easier to manage interface localizations with Localization update compared to trying to make it work manually. Oh and it works with Drush too.
Feedback on the install profile as well as the update module and the concepts and approaches is welcome.
It is that phase of my life! I'm just turning 30 in a month, working with Drupal for 7 years and just had my third Acquia anniversary a week ago. Time to look back and evaluate how things went, all the good and bad things; even better if the wisdom can be shared with others. This was part of my thinking when I submitted the session titled "Come for the software, stay for the community" for Drupalcon Copenhagen.
Ever since Drupal uses major versions for compatibility changes and minor versions for bugfix and security updates (since Drupal 5), it was most often the case that a new minor Drupal release included bugfixes and security fixes packaged into one update.
Early on in the development of Drupal Gardens, it was clear that we needed some type of simple Views-like functionality. You know, letting users set up simple lists of content beyond what is included with Drupal 7 core, but simpler than the Views UI which can be quite intimidating to first-time users. Drupal Gardens' goals include making Drupal easy to use, and that sometimes comes with feature sacrifices. You cannot do everything you could do with a self-hosted solution, but you can do most things easier. If you exceed what Drupal Gardens can do, no worries, simply export your code and database and adopt any Drupal 7 module.
So when looking at our options for implementation, we had the obvious choice to roll our own code and live with that or postpone this feature to get released with Views D7. There is some very nice discussion going on around the Views D7 UI at http://groups.drupal.org/node/64143 and it is evident it is not a small task. For Gardens, we needed a very easy to use UI with a limited feature set. And of course there is a module for that, its called Simpleviews, from Jeff Eaton himself.
We decided to contribute to the community efforts within our limited scope, so we took Simpleviews and upgraded it to Drupal 7 and posted it for review in the issue queue. But Simpleviews depends on Views, right? So without a Drupal 7 version of Views, how useful could that all be? Whether by chance or Jeff Eaton's genius, Simpleviews is actually a pretty standalone module. It only requires Views where it clears the Views cache. The architecture of Views lends itself very well to these kinds of alternative interfaces because it works with array dumps, so an alternate UI module can just have its own ways to generate these arrays.
The original Simpleviews UI screenshot from the module's page
Simpleviews itself stores all simpleview settings in a database table and generates Views arrays out of that. So if we don't have Views, we can just look at the settings in the database and generate output based on that. This way we get the best of Simpleviews by being forward compatible with Views if we later decide to include Views in its entirety, while we can have a very simple and lightweight module to generate output for the small use-cases we cover today. Because Simpleviews is indeed very simple, the backend for generating pages based on the settings there is also surprisingly simple.
My initial version of this backend module was 167 lines with plenty of code comments, which covered all kinds of funky Simpleviews features, except exposed filters. Honestly, we attempt to practice restraint around adding more features to it, but currently it already grown to 460 lines to support some additional things like taxonomy term based filtering and style support for blocks. It is still a little-bitty module compared to Views.
What are we going to do with this feature in the future? Well, we are still not decided yet. We certainly want to provide a lot more Views-like functionality and features this year, but we are starting with design and UX first -- and then we will decide what back-end supports it best. We might use all or some of Views in the future, we might tone down its UI, we might use another alternate UI, we might keep using an alternate backend. It is an ongoing discussion at the Gardens team at this stage. I believe that there is no point in publishing our current backend module on drupal.org given its interim nature, but that does not make it closed source or unreleased. Any Gardens site that is exported will include a copy of this module, and it is released under the GPL.
What do you think about our approach? How would you make the Views user-experience so easy anyone could use it without getting help? If your suggestion pertains to the Views module itself, please contribute to the existing groups discussion, otherwise leave a comment. Thank you!
At Acquia, among other Drupal 7 UX improvements, we've been working making the overlays work as designed by Mark Boulton and Leisa Reichelt. The plan includes a header with two levels of fixed items, which all invoke overlays (almost full window popups), showing above the current page. Instead of reinventing the wheel, we started working towards porting the existing Popups module to Drupal 7 and implementing the Drupal 7 overlay looks via a skin, so we can leverage the existing work, testing and wisdom from the module.
Due to how hard JS is to debug still with Firebug, we faced some issues, but given that we are over those, we have the basic overlay looks ready and facing some other engineering problems which are pretty much standard with how the Popups module works. For integration purposes (and because our proof of concept version of the header did not look as good), we worked with Young Hahn's header patch. You can find my modifications to that to work with overlays on the issue. While Young's patch does not yet map to the D7UX plan to have a fixed set of top level items and a fixed set of lower level items, redefining the D7 admin information architecture, for working out the overlay, it is pretty good as it is now.
Since we were working on (a) porting Popups module to Drupal 7, (b) create a d7ux skin for it, (c) a header which we did not use in this experiment, and Young Hahn was working on a header which needs a patch and images added, I've decided to pull together a quick Drupal package for your testing pleasure. The distribution includes a D7UX install profile which should be used so that the proper modules are set up. It also includes the latest header patch from Young's issue (which has my popups class modifications) and the images and sprite from there. The ported Popups module and the D7UX skin for it is also included.
While I am searching for the best ways to collaborate on the overlay (and possibly also on the header), so we don't need to work back and forth in issue queues, possibly stepping on each other's toes, I am also sharing the D7UX Popups module theme as a separate package, so those fond of applying patches and adding up images from different sources can keep up with development.
There are some pretty significant known issues with the overlay/popups. The biggest one being that since the overlay page is loaded into the same DOM tree (same HTML document) as the rest of the page, ID collissions can easily apply. If you load up a node edit form on a page with a node edit form, #node-edit will appear twice. Behaviours rightly assume that an HTML ID will ever appear once, so they do not expect this situation. This breaks some behaviors. Also, since Popups modules opens new popups on clicking on new links without closing the previous ones, this can also happen if you open two node forms in the popup in a page view. There are also smaller styling problems (eg. overlays on lower layers move up a few pixels when new popups are opened), but we should focus on the significant issues first.
I am looking at breaking down the Popups module (again) to core patches so its parts can be included in core. That would assume that the basic working of it (loading up new HTML-particles into the same HTML document) can be made work without major issues. The great maintainer of Popups module, Tao Starbow worked on quite a few core patches, but unfortunately those got the fate of the overdebated. The issues were split up, then some of the individual pieces were discussed to be over-generalized and in other areas, the scope of Popups in core was narrowed considerably to some confirm forms. No doubt Tao got burnt out from there.
That was way before Mark and Leisa suggested using the overlay technique for the Drupal 7 administration UI. I hope we can revive and refocus some of the issues and get this effort going faster, so we can focus on usability of the actual admin screens showing up in the overlays. Rendering API, JS and CSS wizards welcome! Look for my upcoming blog post on a plan to get this into core!