Jan 10 2006
Jan 10

Just a quick note: Drupal 4.7.0 beta 3 is available now, fixing more than 100 bugs since the last beta. If you have any further issues or suggestions for 4.7 — now is the time to speak up, file bug reports, post patches etc.

I haven't had too much time for Drupal development recently, but I guess I should really start updating the poormanscron module now (finally!) and help with getting the German translation up-to-date...

Jan 08 2006
Jan 08

I recently made my first cron contrib module for Drupal, DB Maintenance. Since the DB Maintenance OPTIMIZE TABLE query locks the database tables it queries, I don't want just anyone to access cron.php anymore. The restriction I added was for the Apache .htaccess file that manages the clean URL rewrite rule.

<Files cron.php>
  Order deny,allow
  Allow from 207.7.108.211 127.0.0.1
  Deny from all
</Files>

207.7.108.211 is the current IP address of deekayen.net, which is needed instead of 127.0.0.1 when you run cron.php with lynx or wget as the documentation strongly suggests, which means 127.0.0.1 isn't the remote IP when Apache receives the request. I only put in 127.0.0.1 so in the future, if I need to access from localhost for some reason, I can.

Jan 07 2006
Jan 07

Langemark's Cafe is Gunnar Langemark's personal/professional website. It syndicates content with a focus on Information Architecture, Semantic Web, Web2.0, User Experience - and Drupal!

Langemarks Cafe - Drupal Information

He features quite a bit of Drupal related news, inlcuding this story mentioning Advanced Web Design. Thank you, Gunnar!

As you would expect, his website is powered by our friend Drupal. His Drupal category has an XML feed available for those who are interested.

Jan 07 2006
Jan 07

After I was back from a short vacation without Internet access, I was surprised to see a post by Robert Douglass titled "Uwe Hermann's Drupal article in PHP Solutions is out" on the drupal.org main page. At that point I didn't even know that the article had been published ;-)

Robert wrote a short review of the article which outlines the main content. In contrast to my last article which was a general introduction to Drupal, this one concentrated on some specific (probably more advanced) topics instead: multi-site install, l10n+i18n, search engine optimization, and AJAX(-like) user interfaces of the upcoming Drupal 4.7 release.

The printed article should be available in multiple languages (German, French, Polish and Italian, at least). There might be a free online version as soon as the next issue of PHP Solutions is published, but I'm not entirely sure.

Thanks a lot to Robert Douglass for the review and to Drupal's Benevolent Dictator for Life Dries Buytaert who reviewed an early draft of my article and provided helpful suggestions!

Jan 04 2006
chx
Jan 04
Posted by chx on 4 Jan 2006 at 16:15 UTC

Someone under the pseudonym "Liz0ziM" sent a false security alarm to BugTraq without first contacting the security team:

http://www.securityfocus.com/archive/1/420671/30/0/threaded

This vulnerability is fixed in Drupal 4.5.6, 4.6.4 and onwards. Drupal's new XSS filter mechanism takes care of all vulnerabilities listed on http://ha.ckers.org/xss.html (and even more).

If you have already updated to at least 4.5.6 / 4.6.4 then you are safe and you do not need to take any action. If you have not updated yet, then we advise you again to do so ASAP.

Dec 21 2005
Dec 21

CNet is running a story about GoodStorm, a site built on Drupal and the open source ecommerce package I authored. Very impressive indeed! Way to go Team GoodStorm.

Dec 13 2005
Dec 13

Yay. Ruby on Rails 1.0 has been released 39 minutes ago. I will probably check it out for real now (although I usually use Drupal for web development work, of course).

They sure have some funny quotes on their website ;-)

“Ruby on Rails is astounding. Using it is like watching a kung-fu movie,
where a dozen bad-ass frameworks prepare to beat up the little newcomer
only to be handed their asses in a variety of imaginative ways.”
--Nathan Torkington, O'Reilly Program Chair for OSCON

Dec 01 2005
Dec 01

You might have already noticed, but I'll re-iterate nevertheless: the Drupal project has released Drupal 4.6.4 and 4.5.6 which fix three security vulnerabilities. Everyone running a Drupal site is advised to upgrade, as always.

Multiple people were mighty busy yesterday preparing, finalizing and testing the patches and advisories. I was one of them, although I was more like lurking around trying to look busy ;-) Anyways, I have sent the respective advisories (DRUPAL-SA-2005-007, DRUPAL-SA-2005-008, DRUPAL-SA-2005-009) to the "usual suspects" today: Bugtraq, Full Disclosure, and the php-sec mailing list. The advisories have already been picked up by Secunia and a bunch of other security sites...

Btw: I finally received news that my domain was transferred to my new web hoster today, which led to a short downtime. Everything should be fine now. If you notice any problems, please drop me a note.

Oct 24 2005
Oct 24

I never thought I'd be doing what I'm doing right now. I'm at work in my underwear, pillow marks on my face and am eating breakfast while posting a blog entry. Yup. I'm a work-at-home freelancer now.

There's nothing about my university job I didn't like. My peers were great to work with and had a real collaborative spirit. I had a kick-ass office that allowed my inner-introvert to hide and crank out Drupal code. And of course the job security and benefits would make any family man sleep soundly at night. So why the job change?

Last weekend Cori and I jumped in the car and saw our friend Stuart once again rock the inner chambers of the Omaha Healing Arts Center. If you've never seen Stuart play, besides performing he'll purposefully and obviously try to connect with you during the show. He doesn't stare up at the ceiling or close his eyes when he plays. He looks at the audience. He looks at you.

During the performance all I could think about was here's a dude who's living the way he wants to live: intentionally and aligned with the Bodhisattva vows. It blows me away when I think of the courage it takes to sometimes perform in a bar full of drunk people and sing songs of mysticism and love. That's some serious Buddha nuts.

Which leads me back to my resignation from the university. Sure my job has the tangible perks but I want to be closer to the Mystery. I want my heart to be as happy as the rest of me was at the day job.

So, here I go. Into less comfortable territory but with more conviction then I've had before. Let's see what unfolds, shall we?

Oct 22 2005
Oct 22

Here's a bunch of smaller updates which probably don't warrant extra blog posts, but might be interesting nevertheless:

  • On the right-hand side of my homepage you now have three new blocks which should simplify site navigation. Each contains a weighted list of tags (tag clouds) for my blog, my podcast, and my photoblog, powered by Drupal's tagadelic module. Of course, the "traditional" navigation menu is still there.
  • There's also an RSS feed for comments on this site now, courtesy to Drupal's Comment RSS module.
  • On the lower left-hand side of my homepage, there's another new block. It shows where the visitors of my site come from in (almost) realtime. This is a service provided by MapStats (I already talked about it earlier).
  • I have uploaded updated versions of my bashrc, vimrc, and muttrc config files.
  • My podcast is now listed in iTunes (thanks Daniel Reutter for adding it). You can subscribe by clicking on this button: Subscribe to my podcast in iTunes!. The amount of people who subscribe to my podcast have almost doubled, figures went up from 30 subscribers to more than 50 today! If you're reading this and subscribed through iTunes: thanks ;)
  • My video iPod will (probably) be shipped on October 31, and it'll take a few more days until it arrives. Arghh, /me wants it now!
Oct 06 2005
Oct 06

The annual report from usability expert Jakob Nielsen:

  1. Legibility Problems
  2. Non-Standard Links
  3. Flash
  4. Content That's Not Written for the Web
  5. Bad Search
  6. Browser Incompatibility
  7. Cumbersome Forms
  8. No Contact Information or Other Company Info
  9. Frozen Layouts with Fixed Page Widths
  10. Inadequate Photo Enlargement

I agree with all of them, especially number 3 (Flash). I'm starting to like most of the AJAX sites popping up around me, but I have yet to find a Flash site which I really like.

Oct 01 2005
Oct 01

Green Leaves
Two Flowers
Pipes

Bear in mind, I'm no professional photographer or something — I just happen to own a crappy 1.3 MegaPixel camera and take photos with it from time to time.

The photoblog is (again) implemented with/on my existing Drupal site by abusing the taxonomy system.

Comments are welcome.

Sep 15 2005
Sep 15

Yesterday, I launched my own podcast (I had threatened to do so earlier). In an unsurpassed effort of creativity I named it Uwe Hermann's Music Podcast ;) This is a pure music podcast (no talking / ranting by me), featuring freely available (mostly Creative Commons licensed) music from various artists and various genres, see my announcement for details.

On the technical side, I have integrated the podcast into my existing website and blog (which is powered by Drupal 4.6.3). The podcasting was possible almost out-of-the-box (as most things are, if you use Drupal). I only applied this small patch which creates an <enclosure> tag for every MP3 to which I link in the respective node. I use the standard "blog" node type to create the podcast entries, put them all in the category "Uwe Hermann's Music Podcast" which I have aliased to http://www.hermann-uwe.de/podcast. The RSS feed for the podcast is simply the standard Drupal feed for that category, which I aliased to http://www.hermann-uwe.de/podcast/rss.xml. Simple, eh?

As I only link to external MP3s that's all I need. If you want to create your own recordings for your podcast, I recommend the audio module by Colin Brumelle of Bryght.

Of course, as I based the podcast on Drupal, you can comment on any podcast "show", refer to them via trackback etc. etc.

I'm eager to hear your opinions, comments and suggestions. Oh, and please feel free to suggest free music which you like. If I like it too, I'll happily play it ;)

Sep 14 2005
Sep 14

A lot of people have already blogged about the new Planet Drupal. It's about time to get my act together and blog about it, too.

I have been submitting a few patches for Drupal's aggregator module recently and working closely together with Dries (Drupal's Benevolent Dictator for Life) to create the planet. He mercilessly reviewed (and applied!) my patches, commented on my ideas and suggested lots of improvements. Without him the planet wouldn't be here today.

As I already stated in the original announcement, we run the planet using Drupal, of course (dogfood etc.), and not the (otherwise quite nice) PlanetPlanet, which most other planets use.

The now improved aggregator module is capable to create a Planet site like Planet Drupal in a few minutes and mostly out-of-the-box, requiring no changes to the code. There are a few minor issues which we need to sort out, but the Planet is there now, and you can subscribe to it in any RSS feed reader.

Sep 03 2005
Sep 03

Ingoldesstat-finden Logo

I have recently built a homepage (based on Drupal, of course) for quite an interesting not-for-profit project called Ingoldesstat-finden.

Some history background:

A document of Charlemagne ( or Charles the Great) from 806 mentions for the first time a "Kammergut" (estate) he owned, namely Ingoldesstat — which later became the city Ingolstadt (not too far away from Munich). Yes, that's the Ingolstadt you know from Mary Shelley's novel Frankenstein. Ingolstadt will celebrate the 1200th "birthday" in 2006...

The project:

The aim of the archaeological project Ingoldesstat-finden is to find the exact place where the first settlers of Ingolstadt lived. Some recent findings indicate that the original Ingoldesstat was not where the city center is today...

The project, lead by Hans Strobl, has many volunteer participants, ranging from archaeologists, historians, art restorers, designers, photographers, videographers and — finally — a computer science student who created their website ;-)

There's a photo gallery which documents the excavations, findings, activities and people behind the project. I also set up a group blog so that all people involved can blog about what they do... It was a lot of fun for me to work with these people to get the site up and running and I'm curious how it will develop — my hope is that it will become a lively site with lots of discussions.

The thing that fascinates me most about this project is that so many citizens of Ingolstadt take part, help with excavations, wash findings, take photos etc. etc. I'll probably also take part in some of the archaeological stuff in the future. Expect to see me "digging in the dirt" soon, in the truest sense of the word ;-)

Aug 27 2005
Aug 27

drupal.org has moved to new servers today. After a short downtime the site was up again and faster than ever.

As I reported earlier, Drupal asked for donations for new server hardware. And received them. Lots of them. The server move today was the first step to put that money to good use. More will follow.

Aug 22 2005
Aug 22

I played a bit with the colors of my blog theme. I'm no usabiliy expert, but I think it's a bit cleaner now and looks better.

Please report if I have broken something.

Aug 17 2005
Aug 17

I cleaned up my blog a bit, today (various smaller updates, removed spam comments and trackbacks from my moderation queue etc.). While I was at it, I also tried some new Drupal modules:

Funny new stuff. Tell me how you like it.

Aug 15 2005
Aug 15

Everyone using Drupal should upgrade ASAP to the new Drupal 4.6.3 (or 4.5.5 if you're running 4.5.x), as a serious security vulnerability has been found in the third-party XML-RPC library Drupal ships with. I sent the security advisory to Full-Disclosure, Bugtraq and the phpsec mailing lists, so hopefully everyone will notice and upgrade.

Aug 09 2005
Aug 09

I released a first version of my Drupal security.module yesterday. The module is sort of an intrusion detection system for Drupal sites. It helps the site admin to check and ensure the security of his Drupal installation. Read my original announcement for more details.

The code is in ALPHA stage, so don't expect everything to work, yet.

Jul 14 2005
Jul 14

Drupal Donations Thanks Poster

Lots of good news for the Drupal project:

The future looks bright...

Jul 10 2005
Jul 10

The Drupal website has been down for two days now. They haven't received a response from support and hence cannot fix it (sounds familiar to me).

On the long run, Drupal will migrate to the Open Source Lab (OSL) which offers lots of services and already hosts many popular Open Source projects like Mozilla, Apache, and Debian.

To be able to do this, they need a new server (free rack space and bandwidth are provided by OSL) for which they are seeking donations now.
It's also planned to create a non-profit organization which will hold the funds, so the donations will be tax-deductible...

Jul 03 2005
Jul 03

The Bryght guys (a bunch of very competent Drupal developers) seem to have a lot of fun while coding...

Jul 01 2005
Jul 01

As most of you probably noticed, the design and structure of my homepage and my blog changed quite a bit a few days ago.
That was me upgrading to Drupal 4.6.1, which makes my life a lot easier, has a bunch of new features (e.g. my blog now has del.icio.us-like tags) and bugfixes, and most importantly fixes a serious security issue.

Two days ago I tried to help a bit with the new Drupal 4.6.2 release, which mainly fixes two major security problems. The first one is an issue with incorrect input validation, resulting in the DRUPAL-SA-2005-002 security advisory. The second one fixes a problem in the XML-RPC library shipped with Drupal (and Wordpress, and PostNuke, and...), resulting in DRUPAL-SA-2005-003.
It was quite a fun experience for me, the release was coordinated and discussed on IRC, we had lots of peer-review of the advisories and release-announcement, testing the patches etc. Thanks to all who participated and made this such a great experience.

Jun 24 2005
Jun 24

Woah, three of the modules I've written for Drupal are among the top 12 downloaded modules.

May 05 2005
May 05

Druplicon
I'm happy to announce that my (German) Drupal article has now been translated (not by me) and will be published tomorrow in Issue 55 of the (English) Linux Magazine.

It doesn't appear to be available online, unfortunately.

Apr 06 2005
Apr 06

Jonathan Chaffer has written a very interesting article which explains how the CMS Drupal (which powers this site, btw.) uses many OOP principles and Design Patterns without using PHP's class keyword. It's written purely procedural, while still using the best features the OOP world has to offer.

The main message IHMO is this: OOP != classes.

Mar 26 2005
Mar 26

I was having trouble getting SSIs to work on this site. Usually my host is good about stuff like that, but maybe they were having an off week. Unfortunately, I really wanted to include a list of links on my sidebar, but didn't want to hardcode them in as I expect them to change fairly frequently. I needed to find a work-around.

I went looking for a solution on some of the MT sites I'd discovered, but didn't find anything that really satisfied me. I didn't want to set up another blog. SSIs weren't working. I was stumped.

Then I reread parts of the MT manual and saw the answer. Modules. Wow. I was wondering what those things were.

All I had to do was format my two lists (with <ul> and <li>, but no other code). Then I created separate module templates for each list. Finally I put the line

<$MTInclude module="NameOfMyModule"$>

on each of my templates where I wanted a list to appear. And that was it.

Now each time I want to updated a link list, I only have to change the one module and my list will be updated throughout the site.

Cool.

Mar 23 2005
Mar 23

For a number of years now I've been a Gossamer Threads' Links devotee. Some people sit around on Sundays doing the crossword puzzle. I like messing with the code in Links. There are all sorts of fun mods to add to the basic script, and I have to admit I've tried most of them. But lately, with a new business, I've been too busy to fiddle with codes and mods. In fact, I've gradually weaned myself off Links. I was feeling pretty good about it, too.

So, wouldn't you know it? About a month ago someone suggested I subscribe to their RSS feed. Huh? It sounded like something from the ICU ("Oh, yes, they finally took Harold off his RSS feed. He'll be eating solid foods again any day now.") Then Nick Usborne of Excess Voice did a piece on RSS and invited people to try signing up for Bloglines and giving his RSS feed a try.

A little uncertainly, I bumbled through the Bloglines registration, not sure what the heck they were talking about half the time. Would I find myself on life support by the end or, worse, inundated with spam? But once I saw some of my favorite e-newsletters listed, I started to get the hang of it. Pretty soon I was signing up for feeds right and left, feeling like a kid let loose in a candy store—Yeah!, I'll take three of those!

Well, of course, this only made me more curious about this whole RSS thing. Who is putting out all this information? Why do they do it? How do they do it? "Blogging"? You're kidding, right?

Still, I can't very well call myself a proficient web designer if I don't even know what a blogger is, can I? So I decided I'd better find out what it's all about. Better yet, let's see how they do it. In fact, let's take a look at some of the software they use like WordPress and Movable Type. What's that you say? Configurable? Plugins? You mean… [brief moment of respectful silence] Mods!?

And so, another MT addict is born. I'd finally kicked the Links habit, only to be introduced to Movable Type. Plugin heaven.

It's a dangerous world out here.

Mar 16 2005
Mar 16

drupal.org currently carries a story by its author Dries Buytaert where he compares the popularity of CMSes (and blogging systems and forums) using the Alexa traffic ranking service. There's several nice graphs included, so have a look.
Also, there's a similar service called g-metrics.com which can be used to create nice graphs from the number of hits Google returns for a given keyword. See the graph for Drupal for an example.

(via Peter van I. via email and drupal.org)

Mar 11 2005
Mar 11

Druplicon

I am somewhat proud to announce that an article written by me about the free CMS Drupal, has been published by the German Linux journal Linux-Magazin. It's available in their Sonderheft Linux-Magazin 2/2005: Web Edition (a special issue about web publishing).
Unfortunately the article is not available online, so you'll have to buy the magazine to read it.

My article gives a broad introduction to Drupal, covering the installation (and some troubleshooting) as well as the basic concepts like nodes, users, roles, permissions, themes, modules etc. I briefly introduce some important contributed modules, explain how one usually installs modules and give a short overview of what will be new in the next release, Drupal 4.6. There's also a tiny section about the history of Drupal, and I provided links to some interesting Drupal-stuff like the Custom Blocks repository (which has recently moved, so the URL in the article is wrong), the Drupal Theme Garden and the Drupal API documentation.

If you happen to have read the article, I'd be happy to get some feedback.

Mar 09 2005
Mar 09

The first release candidate of of Drupal 4.6 is available. You can already check out the soon-to-be-released new version of Drupal, but bear in mind that some bugs and issues will have to be resolved until the final release.

There will be some great new features and improvements, check out the ChangeLog.

Jul 24 2004
Jul 24

My latest Drupal project is a collaboration with John VanDyk, author of the Metadata Plugin for Manila. John also wrote a great walkthrough of Drupal's life-cycle that's worth reading, especially if you've never stepped through Drupal before. I've known and worked with John for many years, and this project is something we've wanted to build for quite a long time. It's a metadata-centric approach to content management.

Most content management systems use metadata only at the presentation level, lumping it in the same category as 'user navigational aids', such as breadcrumb trails. We feel metadata can easily drive both content AND functionality given a solid framework of schemas, metatypes and actions. In otherwards, metadata becomes a collection of tools used to shape the presentation and behavior of your site. Drupal has a foot forward in this arena with the taxonomy module. Our goal is to extend taxonomy module in three areas:

  1. Open vocabularies. User's should be allowed to add terms if they have permission to do so.
  2. The ability to render terms as any HTML form field, instead of select boxes only.
  3. If a vocabulary is storing numeric information, it should be stored in the database as a numeric type. The same holds true for string terms.

On a larger scale, we're also creating the ability to add metadata schemas to existing node types. We're not declaring new node types, but extending them with user-defined attributes (aka vocabularies). Say for example you want weblog entries with 'word of the day' and 'song of the day' features, here's how you'd do it:

  1. Add a new metatype (aka vocabulary) called 'word of the day'. Choose the string data type and specify that it should be displayed as a textfield. Optionally assign actions to the metatypes, such as validators and display properties. Do the same for 'song of the day'
  2. Create a new schema that extends the original blog node type. Name it and add your two metatypes.
  3. All schemas you create are visible on the 'create content' page. Click on your new blog schema and you'll notice the 'word of the day' and 'song of the day' form fields are present. Your blog entry is the same as any other blog entry except you've extended the definition of what it means to be a blog. The behavior of this metadata is much like the current behavior of taxonomy views, allowing you to list all content with like terms.

And there's no reason why you can't have multiple blog schemas as well! Now that makes life interesting, doesn't it? Imagine a corporate intranet where each department wants to use blogs to track different types of information. Schemas would make this approach much easier than manually writing different blog modules for each department.

Hold on, there's more. Once a metatype is created, it can be attached to any number of schemas. For example a keywords metatype will probably have the same function for most schemas. It is even possible to have hierarchial metadata values since we're building on top of Drupal's taxonomy system.

So far I have been very surprised how little the Drupal core code has been modified for this project. At this stage I can't offer any timeline on when we'll be finished, but if you're coming to OSCON, look us up and we'll be glad to show you a demo :-)

Jun 24 2004
Jun 24

The img_assist module has been added to the Drupal contributions repository and with it several updates.

  • Previewing image thumbnails can be filtered by image categories so you don't have to view them all at once. (screenshots)
  • The generated code snippet can be viewed before it is inserted. This allows you to manually copy the code and paste it somewhere else.
  • There are now Drupal 4.4 and CVS HEAD versions of this module.

Here's the official Drupal project page to download the module.

Jun 09 2004
Jun 09

The latest module i've concocted for the next release of Drupal is designed to make adding images to content easy without getting too caught up in HTML. It acts as a frontend to image.module, and thus does not upload images by itself. Here are the screenshots.

So what makes this different from all the other image-adding modules? I have no idea, i didn't look. But here's a list of things this one does:

Quickly add images

Step 1. Choose a thumbnail
Step 2. Click 'Insert image snippet'

Add borders, captions, adjust alignment and more...

With no need for any third party libraries.

Resizing maintains aspect ratio

When resizing an image, the dimensions of the image are locked by default in order to maintain the aspect ratio.

You control the output

The HTML code snippet generated by this module is user-defined. For example you can make all your images float to the right by default, or even link to the larger image.

Track where images are used

This module records to locations of all the links it generates. This allows you to generate blocks that inform your users where else this image appears. You can do this by enabling the 'Image reference' block. The block will be visible on the node/view/ page of any image with references.

Creates pure HTML with no Drupal filters

Previously in order to add an in-line image to a node you either had to use an image filter or straight HTML. This module creates the best of both worlds. The end result is HTML that does not need to go through the Drupal's sometimes expensive filtering system. And better yet, if you ever update your original image with a new one, the image links will still work. This is because the generated code snippet is using a reference to the image ID instead of the actual file.

Image Preview

You can view what the image will look like before changes are committed.

Only an interface

This module does not upload images, it only inserts images that are already on the server into content such as blogs and stories or any node type. This makes it a great interface for the image module.

So, in order to use this module, either you need the aforementioned image module installed or you need another module that does the following:

  1. Stores images as nodes
  2. Creates a database table called 'image' with at least the following column names:
    • image_path: the path to the image from the Drupal root.
    • width: image width
    • height: image height
    • nid: the node id of the image. Images must be nodes.

And now the download link:

Jan 06 2004
Jan 06

This tutorial is designed for the CVS HEAD tree as of Dec 30, 2003.

This tutorial assumes that you have successfully installed drupal and are ready to creat your first user account. If you haven't made it this far yet, be sure to revisit the INSTALL file that comes with drupal as well as the online documentation.

Creating the superuser account

The first step after a successful installation is to create the superuser account. This account allows an user to bypass all Drupal permissions and perform any action on the site. Only one account can be the superuser account, and it is strongly recommended that this account is used only when necessary and not for everyday use. The first account you create in Drupal will be the superuser account.

Go to the main page of your Drupal site and click the Create new account link


Click the Create new account link

Enter an username and E-mail address for the superuser, which in most cases be yourself. After clicking the Create new account button and submitting the information, you receive a special message about the power of the account just created and a login button to click and enter the site.

After you login, you probably want to change your password to something that's a bit more personal. Change your password and any other account settings you wish. When you're finished here, we jump into administering the site.

Where's the Admin Interface?

The admin interface is accessible in your user block which organizes all the actions you can perform on the site. Since your the superuser, you have access to the admin interface via the Administer link.


Accessing the admin interface.

You'll notice that in the admin interface the site still maintains the same look and feel of the current theme.

Since your logged in as superuser, you get the 'Administer' link which is the entry point into the admin interface. Go ahead and click on it. By default the admin interface displays a briefing of the most recent system events on your site. These are called messages, and will come in very handy when users are reporting problems and detecting suspicious activity on the site.

Underneath the Administer navigation tree is seven links. Here is an overview of each section:

  • content- manage all content that has been posted to the site. You can also navigate to a particular item of content and edit from there as well. In most cases this is an easier approach unless you need to do batch content editing. You can also set global properties for your content here, such as which content types (such as books, stories, and pages) have comments or revision control enabled by default.
  • comments- By default the comment module is enabled in drupal. Here you can manage and moderate comments.
  • accounts- Create and modify users, user groups(in drupal it's called roles), and set role permissions. We'll visit this section shortly.
  • configuration- This is the most important part of the administration interface for the administrator. You control site-wide settings, themes, blocks, the installation and configuration of modules, as well as filters for submitted content. Get familiar with this section, folks.
  • taxonomy- Manage how content (even images) are categorized.
  • messages- Detailed site monitoring statistics. The initial admin screen is the brief version of what you see here.
  • help- Drupal documentation.

Setting Permissions

Drupal's default install is locked down pretty tight and nobody except the superuser has permission to view content. If that doesn't float yer boat, then let's take a look at changing it.

Navigate to administer » accounts » permissions. This page shows rows of permissions that each role can perform. By default there are two roles: anonymous user and authenticated user. The anonymous user is any user that visits your site and is not logged in or doesn't have an account. So with a clean drupal install, nobody can do 'nuthin except the superuser. The authenticated user role is the default role a user is assigned when after they create an account.

If you want a site that's open to the public, you'll want to check the access content permission under anonymous user. Most permissions can be divided up into two categories: access and administer. Access permissions control whether or not a role is allowed to view some form of content. Administer permissions generally control features such as modifying and configuring a feature. Be warned that some permissions are dependent on each other. For example, if you check 'administer site configuration' but not 'access administration pages', you'll never make it to the site configuration interface. Currently the only way to figure out these dependencies is through sheer determination and common sense.

A Crash Course in Module Management

You've probably already got a couple of modules you want to install or uninstall. To do that go to: administer » configuration » modules. If the 'status' column is checked, it means the module is installed. To disable it, uncheck the column. To enable a module, simply check the column.

What really happens when I enable a module?

Each module has the ability to build it's own configuration page. These pages live under administer » configuration » modules. Usually after you enable a module, this is the first place you want to look in order to tweak the new component.

A module also has the ability to add it's own permissions into drupal. For example, adding the path module will create two new permissions for you to manage.

Modules can also add new filters, blocks and even their own independent links. Sometimes after you install a module, you mat need to go to the help link and learn more about the newly enabled component.

Matt, respond to these questions:

I installed Drupal, but I would need some more detailled Tutorial, than the Documentation on this website. I could create some pages and they are visible in the main navigation block, but I don't know how to deal with Taxonomy, how to link the pages between each other...Is there a very basic Tutorial about using Drupal somewhere? Thank you very much!

I would also include a "usual suspects" sections for trouble shooting errors. Things to answer questions like "Why does it keep going back to the front page" and "I didn't change module X but now it suddenly stopped working."
--
c0c0c0 (aka "Dan")

From working with people, it is my experience that the first thing they want to do is (1) add some content (typically a static page) and (2) link to it from their main page.
--
Dries Buytaert :: http://www.buytaert.net/

Jan 01 2001
Jan 01

The theming guide for Drupal 8 will get you started in the basics for theming a Drupal site. But, once you’ve learned the basics, what best practices should you be applying to Drupal 8 themes? There are lots of popular methods for writing and organizing CSS. The basics of CSS, of course, apply to Drupal.

  • Don’t get too specific
  • Place your CSS in the header and JavaScript in the footer
  • Organize your CSS well
  • Theme by patterns, don’t go top down
  • Preprocess your styles

Use configuration first

When it comes to Drupal, there are some common mistakes that happen when a front end developer doesn’t know Drupal. In general, apply your classes in configuration. Do not fill your Drupal theme with custom templates like you would for WordPress. Template files, especially with Twig, have their place. But, configuration should be your primary tool. My favoriate tool for applying classes is Display Suite and Block class. Panels is also good. And, fences isn’t terrible.

By applying your classes in configuration allows you to easily edit, reuse, and apply classes across every type of thing in Drupal. If you apply your classes with templates, it’s difficult to apply them across different types of content without cutting and pasting your code. However, don’t be afraid to use some presentational logic in your Twig templates.

Be careful what you target

In Drupal, there are many times where the only selector you have that will work is an ID. If you have this problem, Don’t use it! Never, ever, ever, apply your CSS with ids in Drupal. This is true for every framework, but in Drupal it’s a bigger problem because IDs are not reusable, they are hard to set, and they often change. A backend developer will not be able to apply your styles to other items without fixing your CSS for you. Don’t write CSS that you know a PHP programmer will have to rewrite because you don’t want your PHP programmer writing CSS.

Use view modes

Make sure to target your styles to reusable elements. So, avoid node types because those aren’t reusable on other nodes. Instead, use view modes and configuration to apply selectors as you need them.

Avoid machine names

This relates back to avoiding IDs. Machine names in Drupal sometimes need to change, and they are not reusable. So, don’t target them. Instead use view css, block class and configuration to apply classes to your content.

Don’t get too specific

Drupal 8 markup is better, but Drupal is still very verbose. Don’t get sucked in by Drupal’s divs. Only get as specific as you need to be. Don’t replicate Drupal’s HTML in your CSS.

Apply a grid to Drupal

Choose a grid system that allows you to apply the grid to any markup like Singularity or Neat. While you certainly can Bootstrap Drupal. Using Bootstrap on Drupal requires a heavy rewrite of the HTML which will break contributed modules like Drupal Commerce in obscure, hard to fix ways.

Use a breadcrumb module

Do not write advanced business logic into your theme templates. If your theme is programming complex features, move that code to a module. Or, install modules like Current Page Crumb, or Advanced Agg to handle more complex functions. This isn’t WordPress, your theme shouldn’t ship with a custom version of Panels.

Don’t hard code layouts

Use {{ content }} in your templates and let the View Modes, Display Suite, or Panels handle your layouts.

Don’t use template.php

If you need some ‘glue’, write or find a module meant for it. Drupal is built by many, many tiny modules. Learn to love it because well-written modules are reusable, maintained for free and always improving. Custom code dropped into your theme makes for hard to maintain code.

Jan 01 2001
Jan 01

Breadcrumbs are a pain point in Drupal 7. If you don’t know how breadcrumbs are supposed to work, go read this. The crumb should start with home and continue through to an unlinked crumb of the current page. Crumbs were implemented poorly, and breadcrumbs were difficult to modify in a module. Further, they were based on items in the menu. The breadcrumbs didn’t even allow you to edit the home title or include the current page title as an unlinked crumb. So, if you wanted breadcrumbs on a Drupal site, the first step was to choose 1 of 10 different modules to build them for you. Making matters worse, some themes decided to program breadcrumbs for you as well. If you’re stuck with a Drupal 7 breadcrumb problem, use a module I help maintain, Easy Breadcrumb. Trust me. I’ve got this for you.

Drupal 8 vastly improves breadcrumbs, but core still gets them wrong. They are based on the current page path exactly like Easy Breadcrumb in Drupal 7 which is a huge improvement. So, what did they get wrong? The current page title is missing. Bummer. So close. But, not hard to fix. So, lets do it! If someone tells you to program the breadcrumbs into your theme, don’t listen to them. They are doing it wrong. Themes should work with markup and presentation. They shouldn’t implement complex, reusable logic.

Drupal 8 has refactored breadcrumbs making them much easier for developers to extend or replace. This new architecture makes it easy for us to correct Drupal 8’s breadcrumbs. Unfortunately, the code from Larry’s post is a bit out of date and doesn’t work anymore. So, lets look at the code pulled from my module Current Page Crumb module that adds the current page title to the breadcrumb.

This code extends the PathBasedBreadcrumbBuilder core class to add the current page title to the breadcrumb. Since everything else needed for the breadcrumb is handled by the parent, line 31 does almost all the work for us. From there, we just need a few lines to add the current page’s title. If you’re looking for more examples to completely replace the core breadcrumbs with a custom builder, check out the Drupal 8 version of Easy Breadcrumb which does just that.

Jan 01 2001
Jan 01

Don’t store site configuration in the database during development because putting configuration in the database makes configuration difficult to track in version control. Instead, use the file system! Putting configuration in a database also makes it more difficult to restore, compare, sync, deploy, modify, and review the site config. Drupal 8 uses Yml files for configuration which are a perfect format for file-based configuration. In fact, this is the only method for storing configuration in BackdropCMS because BackdropCMS uses JSON files to store site configuration. Drupal uses Yaml to store your configuration the database, but storing Yaml in files was the default method for Drupal 8 when CMI was released. Many posts have been written about the default workflow for configuration. But, the promise of file-based workflow is more efficient.

Configuring in Files Workflow

When Drupal stores configuration files in the file system, all you do to save your work is run a git commit because as soon as you click save in a form, Drupal writes your changes to the configuration folder. Once your work is in code and committed to version control, you can publish those on GitHub and open a pull request to review your work before deploying it to production. This workflow is possible with database configuration, but it requires extra steps with Drush that can lead to errors and differences between environments.

Don’t Modify Production

No matter which storage you use for configuration, you should not edit your configuration in production. Instead, you should install the config readonly module in production and make all of your changes in your local environment. Clients who don’t install Drupal locally can make configuration changes in development. Using a host like Pantheon makes it easy to deploy files from development to production.

So Why Does Drupal Store Config in the DB?

I prefer keeping configuration in the file system, and BackdropCMS agrees with me. But, a few smart core developers don’t see it that way. So, why not? Drupal 8 is slow. And, some poor web hosts might allow the public to read configuration files.

Early in the release cycle the install process was slow. So initially, moving configuration into the database made running the installer a bit faster. However, file-based configuration in the current release of Drupal 8 doesn’t make the installer visibly slower. So, this isn’t a problem for our workflow.

The second concern with file based configuration is the desire for security through obscurity. Since we are storing configuration outside the webroot, and our web server should also be configured not to display configuration files, this isn’t an issue.

Another concern was that file configuration might encourage people to edit their configuration. Since this workflow is for programmers, this is an advantage of our workflow.

Advantages of Database Config Storage

Storing configuration in the database on production has some minor advantages. So, leaving the configuration in the database on production is reasonable. Storing in the file system means you have to sync the file system in multiple web server environments.

Storing config in the database allows you to attach metadata to the configuration so that you can timestamp it, assign an owner to it and create a revision workflow for configuration.

How to Enable Config in Files

The easiest way is to use the Drupal8-base installer which will enable file storage for configuration out of the box. Alternatively, you can export your site configuration from the database and then follow these quick steps to enable file-based configuration storage on an existing Drupal site.

Jan 01 2001
Jan 01

These core concepts apply to Drupal 8 site builds. However, many often apply to the other major web framework from WordPress to Node projects. Many of these ideas are documented on Drupal.org as well. I’m rewriting them here because I disagree with the documentation in several key areas.

Use The Same Development Environment

Everyone on your team should have exactly the same development environment. Using the same development environment ensures that the project runs exactly the same for each team member working on a project. You can do this with Vagrant, Ansible, or a Brew script.

Backups? Put The Database in Code With CMI

Configuration Management in Drupal 8 allows you to quickly store database settings in code. Further, content should come from a single reusable source. We use Google Docs API, others use Profiler. The key is keep your test content in a shared, predictable place.

Drupal.org recommends that you backup your files and database. Since all of your code is on Github, and your database is in your code, Backups only matter in production. After a project launches, your hosting company should be providing backups. If your host isn’t taking care of this automatically for you, then switch to a web host like Pantheon, WP Engine, or Site Ground. All provide automated backups. Site Ground gives you per file recovery while Pantheon focuses on CMS backups for code/files/database in an easy to restore tool.

Never Hack Core (or Contrib)

Don’t change the framework. Instead, write your own code as a module. Pantheon, doesn’t follow this rule, and it creates a lot of extra work for them. But, they have an entire company of developers to maintain their fork of Drupal. The rest of us should stick to the official release. This is true no matter the framework you’re in. If you hack WordPress, your project will fail during automatic updates!

Use Test Sites

Your hosting company should be providing 2-3 sites for each production site automatically. If your hosting company doesn’t give you test sites, switch to Pantheon or WP Engine. You should make all your changes in your local environment first, test them locally, and then deploy them to test in production servers on a test server.

Use Configuration Before Code

Instead of hard coding a class or a snippet of logic into a theme, set these values in configuration and then apply the configuration with code. This allows your code to change in the future without being rewritten. This also leads us to choose high quality, well maintained modules to build our sites out of. Reusing code is one of the most basic steps in writing quality software because reusable code will have fewer bugs and more features.

Instead of writing a massive “glue” module, break up functionality into reusable modules and use configuration to apply advanced functionality so that each module is more powerful and easier to modify without rewriting the code.

Avoid Too Many (Poor) Modules

For those of us who work on large scale Drupal sites, we’ve learned that hundreds of modules can work together to produce an amazing, large-scale software project. When building enterprise Drupal sites, it’s more important to avoid using 1 poor module than it is to avoid 30 well built modules. This too many modules advice leads programmers to favor programming their own modules over reusing modules. However, avoiding contributed modules means you end up rewriting basic Drupal features in every new project.

This includes your custom modules

Drupal.org only talks about contributed modules, but this too many modules advice holds for custom modules as well. The more custom modules you write, the more work it takes to maintain and modify your website. Instead of writing a large collection of custom modules, or a single giant glue module, consider publishing your modules on Github. This will encourage you to create reusable code that has configuration needed to make them reusable and future proof.

Follow Coding Standards

You can automatically check and repair your code for Drupal with Code Sniffer.

Up next, controversial configuration practices for Drupal 8 that will improve your workflow.

Pages

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web