Programming blog

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.