This site is managed with Drupal, a content-management system (CMS) that facilitates the creation of portals and community sites.

In this page we describe how we went from the default drupal configuration (left) to what you see now (right). We hope you find it useful!

We do not pretend to replace the help info and handbooks in the drupal web site, just to explain our experience and discuss the decisions we took during the process.

Feel free to ask how we configured any part of the portal that you are interested in

Selecting a CMS

---

Drupal is not the only free CMS available. For simpler sites (i.e. more blog-oriented), WordPress can be a better option. The most typical alternative to Drupal, though, is Joomla. You can find a lot of partial comparisons between the two. We chose Drupal because it seems to be more customizable and offers a more fine-grained control of all aspects of the site. Check the existing comparisons to see which CMS is more appropriate for you.

Selecting a hosting service

---

A list of companies able to host drupal sites can be found here . We chose lunarpages to host this site (if you are looking for a hosting service, please take a look at them following the link below). The reason that convinced us was the really good technical support they have, which is, in the end, what saves your time.

Whatever company you choose, our recommendation is that you opt for a virtual private server or a dedicated server. A shared hosting service will be cheaper but you may experience a lot of problems and limitations when running Drupal.

Installing Drupal

---

Installation went smoothly, once we discovered why we were not seeing the initial drupal installation web page. First we thought that we had uploaded the drupal files to the wrong directory but then we found out the reason was much simpler. Our homepage folder had a default index.html file that came with the initial hosting setup. Therefore, when writing the url for the domain homepage, the index.html took preference over the Drupal index.php file. Once we removed that file everything was fine.

Setting the template

---

Drupal comes with a small set of predefined templates. Many more are freely available on the web but be careful if your site has a commercial aim since some explicitly prohibit that.

To install the template you just need to upload your template files to a new sites/all/themes folder. Be sure that the template matches your drupal version. Most likely, when trying to install your new template you will see an error similar to : “SAFE MODE Restriction in effect”. To avoid this you should turn off the SAFE MODE option of your PHP. For Plesk users, the easiest way to do this is to select the domain, click setup and uncheck the check box with the label “php safe mode on”.

Some templates come with instructions on how to configure the blocks in Drupal to get the right appearance in the template. For instance, in our template, the primary links are disabled in the blocks menu but as you can see they appear anyway in the top of the page, because the template explicitly adds them when executing its page.tpl.php file.

width="550px"/>

Setting the footer and other site information

---

To change the footer simply update the information in Site Configuration->Site information

Drupal and SEO

---

There is a lot of information out there about how to make Drupal more SEO-friendly. Basically we just need to worry about improving the URL structure and adding metadata description to the pages. For this second aspect, we just need to activate the meta tags module.

For the URL’s part, Drupal already comes WITH the clean URLs activated by DEFAULT (meaning that NO params ARE shown NEXT TO the url) but you should still take SOME TIME TO improve them. FOR instance, the initial url OF our home page was http://www.modeling-languages.com/node/1 (NOT very exciting!).

You can use the PathAuto MODULE TO automatically CREATE alias FOR your urls. We ARE USING the DEFAULT alias creation options FOR ALL pages EXCEPT FOR the FIRST-LEVEL ones WHERE we preferred TO manually define the alias. Unfortunately, the CURRENT version OF the MODULE overwrites our USER-defined VALUE every TIME we edit the page so we need TO keep entering it again. This MODULE should be used WITH the GLOBAL Redirect MODULE TO redirect the old page url TO the new one TO avoid HAVING duplicated pages.

USING images IN the nodes

---

There ARE several modules TO WORK WITH images (Image, ImagePicker, ImageAssist). The one TO use depend ON your specific needs. FOR instance, if you want each OF your images TO be an independent node THEN you should use the Image MODULE.

IN our CASE, after trying them, we have opted FOR USING …. NONE!
We find easier TO just upload the image files TO the target folder (under the sites/DEFAULT/files directory TO be a little BIT organized) AND manually link TO the images IN the editor. FOR the upload you can use ANY ftp software OR activate the upload core Drupal MODULE.

Changing the DEFAULT editor

---

The DEFAULT Drupal editor allows TO WRITE the content IN HTML (WITH SOME simplifications). It IS also possible TO use a visual editor. IN our CASE, we use the TinyMCE editor. TO install the editor, install FIRST the WYSIWYG MODULE AND THEN the editor. Finally, associate the editor TO one OF the INPUT filters AND that IS it! (if you still don’t see it check the permissions).

width="550px"/>

Using an editor facilitates the writing of long posts with lists, links,… However, nothing is perfect. This editor has the annoying characteristic of sometimes removing manual editions done to the HTML code. We’ve ended up defining a new FULL HTML INPUT format ON which the Editor IS NOT associated AND that we use WHEN we prefer TO directly WRITE the HTML code FOR the node.

Do NOT forget TO CHECK the continuation OF this post IN the SECOND part OF this series!