Programming blog

I'm going to be working with a partner to create a Drupal site for my school. We have a full month to work on the main details of the site, and will work on improving it over the course of the whole year.

The idea is that we want to build a site which will serve as a marketing front-end for the school, and as an way to distribute information to parents and students from the school, and allow teachers to collaborate with each other and their students.

I know that Drupal can do the job. I plan on using this blog to document my process.

Today we started by setting up 2 domains for us to use, one as a back-up to the other, and installing a mirrored Drupal installation on both of them. Plan is to start with a huge bundle of modules (most of which will never be enabled) to remind ourselves of all of the features available to us through the active community at Drupal.org. We don't want to build anything from scratch that exists already.

The major difficulty with the site will be in the intended upgrades. We want to eventually have parents able to monitor their child's progress through their account on the website. So we have a lot of sensitive information that we need to protect, which means access control is going to have to be carefully checked.

As you know, a colleague and I are working on our new school website. This part of a series of blog posts explaining what we have done.

The very first task we did was to look at the information we were provided on the needs of the school in terms of menu layout and functionality. This was actually fairly easily done since we had spent the previous year working in a committee. From this, we decided on a menu structure and overall plan for our site.

Our idea is to segment the site using Organic Groups, largely because it's easy to create access control (just assign users to the groups they are allowed to view) and easy to maintain relationships between the content of the site and it's location within the site. We are also planning on using the Panels module to provide the display of the group nodes and the front page.

We plan on using the Views module to expose our site information, and using custom content types to make it easier for users to submit information for display within the correct view. We may end up using CCK to add some fields to our nodes, particularly for our Alumni users to submit user profiles and for our school bulletin items.

The site is already starting to come together a bit, which is exciting.

David

Some major developments have happened since my last post, and the site is coming together nicely.

One is the development of a theme for our site. We've basically taken the Zen theme and using some CSS and some modification of the .tpl.php files, we have created a decent unique theme for the site. Much of the initial work can be attributed to my partner, but I managed some of the details, especially the modification of the template files. The design for our theme can from in-house, from a graphic designer who created the layout and presentation of the design using Adobe Illustrator. I have to say, .ai files are a pain to work with, glad she was able to export it to a .svg so at least I could open it and view it using Gimp.

One of the less fun things about theme development of course is checking for browser compatibility. We used the conditional commenting technique to add css just for IE (and yech! just for IE 6!). We decided against making our theme work for IE 5, and IE on the Mac is a waste of time. Safari 3 was easy to check for, since it has a Windows install, as was checking Firefox on Ubuntu. However I don't have a Mac around so testing for Safari 2 will be interesting (although necessary given Safari increasing market share).

Another development is the import of the old galleries, a sub-project I was happy my colleague handled. We had to manually find each folder (which were scattered all over the place because of the sloppiness of the old site management) and then import them using the image import module. I tried to use the nodeorder module to arrange the order of one of the galleries but the JS script they use seems to have bugs in it. I ended up having to keep the nodeorder module installed, and then manually arrange the order in the database. Bleh.

We have also started adding the old content from the original site, which has required some formatting. One of the problems we encountered here was that much of the old content is out of date, and uses very poor HTML. I've found myself editing the content quite frequently, and in many cases not importing the content at all. Moving from flat HTML files to a content management system is a tedious business.

We've also gone through and created many, many blocks, to use in our group panels, and almost as many views. We created the blocks using the admin/block/build menu because of the greater flexibility in the input format (including the ability to relatively easily use TinyMCE to create the HTML) and then all of the site blocks are located on the same menu. Our views include some specialized views of OG content (things like Og_single_post and Og_edit_table, etc...) and a few 'Views Bulk Operations', which is a terrific module. We use this so that the process of approving and managing specific site content is a lot easier. For example, in order for images to be used in a Views Slideshow on the front page, we have a form which lists all of the images. Users can toggle between 'promoted' and 'unpromoted' pictures and choose a selection of pictures to be used in the slideshow.

The vast majority of the people who will be using our site will not have publishing privileges, at least initially. The plan is to gradually allow more and more of the staff to be able to publish to the site. To this end we have developed a very simple workflow. Any time a user without the permission to 'publish directly' either creates or edits a post, the post is set to 'unpublished'. We then have a bulk operation where a user can see all of the unpublished content, and choose which of it to publish, and which of it to edit.

We have added a number of different types of content, this simplified the creation of content. Our other alternative was to use Taxonomy to separate some of the different content types (for example Elementary school news, Middle school news, and High school news) but felt this might not be totally intuitive to some users. After watching one of our teachers trying to fill in a form online for almost 20 minutes, I realized that many users do not read the form they are presented, and the taxonomy select might be easy to miss. Rather than spend time tracking down errant posts and assigning them the proper vocabulary term, we decided to go with a different content type, allowing us to use the Content Access module to fix the user permissions to their section of the school.

We are of course, using Taxonomy for managing the 'Image Galleries' on the site, and for restricting access to content. Our content is split into 'Public', 'Private' and 'Restricted'. Content which only meant to be viewed by logged in users is marked 'Private' and content only meant to be viewed by users with the administrator role is marked 'Restricted'.

Today and tomorrow we will be presenting our site, and for the first time getting feedback from some people on the current state of the website. We'll see what modifications we have to make, hopefully it won't be too onerous (like: redo the theme, or we don't like the current menu structure, redo it).

This is a simple module I created which has a very simple premise. You've created a bunch of accounts for some people, and you want them to be able to easily access their account, without you having to know their passwords. You didn't want the users to be notified right away on account creation, for many possible reasons. Maybe it was a development site that you needed to test your user imports, maybe you needed to finish up some quick stuff first, who knows.

So what this module does is allows you to customize a 'welcome to your account' type email in the settings page. You can then go to the user/user menu, where this module has a hook into the user operations drop down. Select which users you want to include, and send them an email, it's that easy.

It doesn't do anything automatically, it requires action on your part. However it does greatly simplify the user experience for finding the site, and logging on for the first time.

Only thing it lacks is a 'send an introduction to every user' which is probably a good thing since you may click it by accident!

Anyway, you are welcome to check it out. I'm not including it on Drupal.org since I just won't have the time to maintain it. If someone else wants to take it over, that's fine with me.

There is a module by this name up on Drupal.org, but a quick check of the issue queue makes it obvious that it is in need of some love.

What my module does is create a Menus tab for each Organic group which only a user with the appropriate permissions can use. Then, each group manager can be in charge of a menu block which only shows up in the context of their group (so on the group home page, and every content item created in the context of the group). The module requires that you give all appropriate users the permissions 'administer menu', but then defines a new permission to prevent user access to the base menu system.

The users can either define a new menu block, or reuse an existing part of the menu structure (which probably needs to be part of a permission but that's a kink to iron out).

The interface is clean and easy to use, I think. Check it out.

This is a simple module that allows users to post responses/reviews of other people's posts. It also includes a simple 5 star voting widget, which degrades nicely when JavaScript is disabled. The posts are limited to the default filter input and are carefully screened for possible xss attacks since it is likely this kind of module could be used for allowing anonymous users to post.

Another feature of this module is that you can use one of your site vocabularies to define in what categories people can vote on. The voting unfortunately does not currently use the Voting Api module. It really should, because then one could define Views of the votes much more easily, and it would allow for a greater generalization of the voting process.

This module has actually already seen use in a couple of places, one a public library (they are using it to review books) and another site is using it to review cars.

Both of the sites have given me permission to release the code. Again, I'm too busy to maintain a module like this, but if someone wants to take up the torch...

This is yet another WYSIWYG module. It has a very simple configuration page, and will currently only show up on node/add or node/edit pages, of the content types one wants. It has a couple of advantages I see over TinyMCE.

1. The code for the editor is open-source.
2. It is a lot, lot smaller in size than many of the other editors out there, which makes it load faster than other editors.
3. The JS only loads on pages that have the editor present, rather than on all pages.

The major disadvantage of course is a much smaller developer team working on it, so bugs and feature requests will presumably take a long time to get implemented.

Anyway, I don't want to maintain this module, so I'm releasing it here, feature frozen.

So my wife and I have decided that we are going to try and be partners in a new business. We'll see how well we work together, we really haven't tried very hard to work on any serious projects (except of course for our son) together before this.

My wife knows a lot about graphic design and what looks good as a result of her training as a landscape arctitect, but knows very little about building websites. I know a fair bit about building websites, but my design sense is horrible. So we combine together these two talents, and we should make a pretty good team.

Instead of trying to build entire websites right now, our plan is to focus on building themes for Drupal 5 and Drupal 6. We'll create a showcase site for our themes, and charge people either a license to use the theme, or the complete copyright to a theme at a much steeper price.

So yesterday we started our collaboration by building a simple theme for our theme shop.

My wife and I each brainstormed a few ideas, and we settled on one of my ideas, with some touch-ups from my wife. I went to work and started installing and setting up the modules I thought we would need.

Installed modules:

• CCK + all default field types
• Imagefield
• Project + Project Release + Project Issue tracking
• Token
• Views + Views Bonus
• Panels
• Path
• E-commerce suit
• Poormanscron

The website portion isn't yet totally complete, but my wife created a layout, which I have turned into a theme. One of the fun aspects of this theme is the front page rotating image preview, done by customizing the html displayed by the view (essentially minimizing it as much as possible) and some jQuery fun.

Check out the site at:

http://unitorganizer.com/skindrupal/

So I thought I should give more detail on how to create a theme for Drupal 5.

What I basically did was copy page.tpl.php, node.tpl.php, block.tpl.php, box.tpl.php, comment.tpl.php and template.php from the Garland theme. I then also created a file called page-front.tpl.php. This gave me a basic framework with which to work.

For the creation of the theme for the Skin Drupal site, the first thing I did was rip out all of the html between the body tags in the page.tpl.php file. I then looked at the picture my wife gave me, and mentally divided it into regions.

From this picture, you can see it could be easily divided into 4 blocks, which is essentially how I created the html.

First I inserted a wrapper div, to make it easy to center the display of the site for people with browsers with resolution greater than 1024x768. We decided, by doing some research online, that a theme that was 960px wide by about 500px tall was ideal for display in most people's monitors. We'd be leaving those poor 800x600 people out of the loop, but that's only 10% of the market, and not likely to be the people looking for themes at our site (developers tend to try and use the best tools at their disposal).

Inside the wrapper div, I inserted two sibling divs to divide the site into the header and main regions. Since the content of the header was so simple, I just inserted 2 divs for the right and left portions of the header and the same for the main portion.

The 5 rotating image blocks, I quickly realized I would have to position absolutely on the page in order to make the fade in and fade out work. This presented problems later and led us to eventually scrap this theme, but more about that in a future post. Anyway, to allow for this, I opened up my blank template.php file and created a themename_regions function, and created 5 more regions for my site, calling them easy to remember things like box 1, box 2, box 3, box 4 and box 5. Before I went any further, I created 5 views to match these blocks and used the block administration page to match the blocks to their position on the front page. I went ahead and created some filler content, so we'd be able to see these blocks at work.

It was pretty simple to set some default blocks for the right column of the main page, and then I went ahead and worked on the css for the theme, which is remarkably simple since our layout is so clean and easy.

Fix the width of all of the blocks, fix their height, add float left to most of them, and float right to the right column, and we were set. Then I used absolute positioning on the blocks and wrote the JS script to fade them in and out. jQuery is amazing, I have to say, this script was a breeze to write. If you examine the source of the page, or use JSview, you can see the name of the JS file, which you can safely view in your browser. You'll see that it's pretty short.

I kept the default html for the box, block, comment, and node files, but used a views theming function inside my template.php file to greatly simplify the html presented by the views (since all I really wanted to see was the thumbnails). Then Tada! I had a really simple plain theme. The idea of the theme is that it looks essentially unthemed, and that our themes will be ways to spruce up the site.

So our new site already has a new theme, which is just a modified version of the old theme. It looks pretty good I think.

The idea is, instead of fading out the backgrounds of the preview images, we leave them in place, and fade out the images. We also reduced the number of images previewed to 3, and arranged them in a column. Finally, my wife had a great idea of moving the menu to beneath the images, so now our menu block is at the bottom of the page.

This is an extremely easy theme, and it even works in IE 5.5 (with a minor adjustment for the logo, which I haven't done yet).

One column, centered horizontally, with header, main, and footer sections divided vertically. No sidebars at all, and extremely easy to retheme later. The JS had to be rewritten, nearly from scratch, but I think it works a bit smoother now, less jerkiness because of the fewer number of elements involved.

Check it out at http://unitorganizer.com/skindrupal

Dave

So I love the Panels module. It gives me much, much greater control over where I want to place my content, and how I create my blocks. It's stupendous.

It has a serious problem though, the actual construction of content is not meant to be done by a beginner. The form includes many unnecessary elements for a novice user and the process is confusing. Worse still, you can't use either the IMCE module or any WYSIWYG editor when creating custom panes. This is a serious issue for many of my users, most of whom will be publishing to the web for the first time.

So I wrote a module which takes the process of custom pane construction, and tries to simplify it as much as possible. The basic idea is, people navigate to a Panes tab, where they see all of the displays associated with this group (or one display in the case of a panels node). They can then choose to add panes to the display, and be sent to a separate form, or edit the custom panes that have already been built. Since this is a separate form, the users have access to a WYSIWYG editor and the nice IMCE pop-up for adding images.

I think this will make managing custom pane content much easier for most of my users. We'll see, I'm going to let my partner know about it, and see what he thinks.

Screen shots:

Main pane edit window

Add pane window

Edit pane window

Notice the use of a WYSIWYG editor in both the 'Add pane' and 'Edit pane' forms (and the link to the IMCE image uploader). This is what really lowers the difficulty of adding nice custom panes to a panels node or an Og panels page.

There are 8 different basic usable website themes I can think of. I've listed them below. My intention is to find minimal mark-up that will produce these themes, with as wide a range of browsers as possible support.

One column	Three fixed columns
Three column fluid center	Three columns - fluid left
Three columns fluid right	Two fixed columns
Two columns - fluid left	Two columns - fluid right

Does anyone have any suggestions of an Open Source solution to these themes? I'm sure they have all been created before. Why re-invent the wheel?

Check this out!

This is a script written by John Bezanis which takes 6 images, specified by GET parameters (his own words) and turns them into a spinning cube. You can click on a face of the cube and it will spin around into focus. Click again and the cube continues spinning.

It's currently displaying 6 images from a course in my online MA where we have to analyze an e-Learning platform using these 6 facets.

Someone mentioned in one of the Drupal groups that they had created a very simple script to check how popular search terms, unique for IP address. In other words, how many different unique visitors have searched for a particular word. I just took their script and converted it to a simple module. Can't take much credit for this one.

This is my BookGUI module, including the most recent updates (which are actually almost a year old). I don't consider it stable for a except for a development environment, but maybe someone can iron out a couple of the kinks I gave up on.

This allows you to edit the structure of a book (AKA the Book module) as well as add/delete pages to the book on the fly, all via an Ajax management page.

It's huge flaw is that it doesn't check for the number of pages that it's going to load. I really need to build some kind of paging system or something similar into this structure. Maybe only load the structure of the book, and none of the content? Content could be loaded on the fly via Ajax...

Anyway, check it out if you like, it's released under the GPL.

One problem with Drupal is that the UI sucks for beginner users. They have great difficulty finding all of the most important administrative menu items they want to use. Since Drupal tends to group administrative items by general functionality and by module, it can tricky working where something is located for a beginner. Not to mention the fact, many beginning CMS users are terrified to death of 'clicking the auto-destruct link' by mistake and screwing up their work. This fear is not ungrounded, as many Desktop applications have a strange red X in the top right corner of the page that is terribly destructive when accidentally clicked (assuming one is not used to reading dialogs carefully before clicking Yes).

So the solution in Drupal is simple. Create a page where all of the most useful administrative items are linked, and make sure that each type of functionality is in blocks which are displayed only to the user who has access to do that item.

This is a module to help non-coders add help text to the top of any path, much like the core Help module does. One problem with the core Help module is that it relies on using hook_help to add the help text to the top of the page. This means that if you want to add help to a page which does not already have it, you need to create a custom module. This means that only the developers of the site can easily add help text, although once the text is added, a user with sufficient privileges could 'translate' the help text string and reword it however they like.

This is a barrier of use for non-coders. My wife wanted to be able to add help text to pages, so I created a module which I call 'Add Help' which allows her to search for a path, and then add help text to that path.

Here is a screen-shot of the "Search for Path" form:

Here is a screen-shot of the "Add Help to Path" form:

There are some minor problems with the implementation, for one there is no way currently to keep track of which pages to which you have added help text so you have to keep track of this yourself. A second problem is that I haven't figured out how to execute php code properly in case the user has chosen the php filter.

Anyway I'm happy to release my code under the GPL, hopefully I'll find time to upload it to Drupal.org as well.

This module let's you take a Podcast view you have created (or probably ANY audio podcast) and allow the JW Media Player 4 module (from the SWF tools module ) to play the audio feed as a playlist, automatically embedding the player as a block. Note that this is built for Drupal 6.

It does not have a lot of configuration options yet, you pretty much need to open up swf_playlist.tpl.php and modify it to suit the location of your feed.

swf_playlist.tpl.php

I am working on a website called Pedagogle.com which is intended to be a file sharing website for educators. The plan is, upload and categorize resources, and if enough people do this, and we have enough resources, then we end up with a website where teachers can go to find resources easily. The problem is that it takes a long time to upload and categorize each file, which leads to frustration from users. So far hardly any files have been uploaded, mostly because I think the process is a bit too difficult for the average teachers, and is definitely too time-consuming.

So I'm developing a module which will cut down the time it takes to share resources on my site. The basic work-flow I envisioned is, a teacher creates a ZIP archive for a folder of digital resources they have created, and uploads the ZIP. They then are presented with a form where they categorize all of the resources and save them to the database, with the option of deleting any files from our server right then that were included in the ZIP archive by error.

The first step in writing this module was to decide on how this was going to work conceptually for the user. It occurred to me that some users might not want to complete the categorization all at the same time, so that the files should be unarchived and stored in a temporary folder on the computer while the user is in the middle of the categorization, and that the process should be one that the user can come back to later if they like. This meant that the URL for the uploading of the ZIP should be different than the URL for managing the ZIP files to make the UI a bit easier to manage.

I implemented hook_perm() and hook_menu() in my module first like so:

I decided that even though my module was for a specific website, I should build it with some generalization in mind, just to make it easier to use the module for a different site. This is why I have a menu entry in my hook_menu() for a settings page.

Once I had my menu entries sorted out, the next step was to build both the forms for each path, but also the submit functions for these entries, which are the most difficult part of this module. The form for the settings page was extremely easy, especially as I could let Drupal handle the submission of the form by running it through system_settings_form.

The upload ZIP form was also very easy, I just had to remember to make the form have the right information initially, so hence $form['#attributes'] = array("enctype" => "multipart/form-data");.

The hard part about the ZIP upload form was the validating function and the submit function. I decided the best way of handling this section would be to extract the ZIP during validation (after verifying it was a legitimate ZIP archive) into a temporary folder and then go through each file and check the extension, and remove all files with improper file extensions immediately. In the submit handler, I save the information about the directory for later, so that the user can come back to the next step, and then redirect the user to the next form.

Once the files are sorted onto the server and stored in a location which is difficult for the user to access, we then want the user to decide on a categorization for each file and give each file a quick description. Since I've stored the names of the temporary directories in my database at the previous step on a per user basis, this allows me to keep each set of uploaded files separate, and allows users to come back to the final form whenever they want. I decided on a gigantic table for my form with the vocabularies as select elements, the description for each file as a textfield, and then a checkbox next to each file name in each table so that the user could choose which files to either save permanently or delete.

Theming this form was relatively straight forward, I just converted by fields into individual rows and sent off most of the form to be themed as a table. At this stage I also added a CSS file and a JS file for later customization which I suspected was going to be necessary.

The next step was to build the submit function for the form. A validation function was unnecessary in this case since I had already validated the file extensions, and my site fixes the input filter for the description at the default filter. Also, the user doesn't actually have access to the file locations, so I wasn't worried about the files being switched somehow at this stage. My submit function basically splits into two cases, one where the user wants to save the file permanently, and one where the user wants to delete the file. In both cases, the final step is to check if the file is in an now empty sub-directory and delete that directory. One issue I am still having is creating a function to check if the entire temporary directory is empty, and removing it if it is.

I decided to use node_submit and node_save here to save the node information rather than drupal_execute because I have found the first two functions easier to work with, and they serve my purpose well. Finally, I was unsure if the validation on the file field would work properly given that the uploaded file being attached to the node wasn't in the official temporary directory. In any case all of the right hooks seem to fire using this code, and my users get points (using the User Points module) as expected.