I have just come across a great example of how not to deal with users logging in or registering for a site with T-Mobile (UK).
I am on my second phone with them and had an account with them for the original phone, so I tried logging in using my username which I had in an email and my password. It wasn't having it.
So I tried the forgotten password route. This asked for my mobile number and my username. Entered my original number and username. Nope. Entered my new number and username. Nope.
So I tried the forgotten username + password route. This asks for your name, phone number and email. I entered all this information using my original phone number. Nope. Tried again with my new phone number. Nope.
After reviewing and updating Block API for Drupal 7, I saw that there were some fairly big changes made to the way the block system works from a code perspective which meant I have had to change a fair bit of the module for Drupal 7. So rather than having 2 quite distinct bits of code, I will be updating the Drupal 6 version to work like the Drupal 7 version so that the documentation is the same. This not only makes the module easier to maintain from my perspective but also anyone else using Block API.
I have been working on a site for a World of Warcraft guild to get their frontpage up to scratch with their old site which was running the TinyPortal on SMF. With a server change and some mods becoming unsupported, the decision was made to switch to something else for the frontpage. I had only one thing on my mind which was Drupal. But soon found that there didn't appear to be many modules on Drupal.org for World of Warcraft. So far I have created two blocks using the Block API module I developed and will release more when I have written and tested them. Both blocks are set up in one module, which I have called wow_blocks. If you already have a module called wow_blocks, it may be a bit of a mission getting this to work, so you will have to chose one of the modules.
This tutorial will show you how to add new form elements which will be available in $form_state['values'] once the form has been submitted using a submit button by taking advantage of the AHAH helper module.
The AHAH helper module does provide a demo, but the demo shows how to change a few fields depending on a selection made from a select element. The tutorials I looked at online either didn't cover the issue properly or just didn't work.
Recently I wrote a new module called Block API which allows other modules writers to create modules to develop templates for users to easily create new blocks rather than relying on copying and pasting HTML.
The example module included copies the functionality of the core block module. Below I will show how to use Block API to display a specific node as a block with further configuration options available to the user to choose from.
This will guide you through creating a multi-step process of content moderation in Drupal 6. This is a follow on to the guide on Drupal.org about creating a revisioning system and the follow on, on creating a revisioning system with state-based access. Both of which only allow a single step revisioning sytem, i.e. Author creates content, moderator either edits and publishes or sends back to author to edit.
A user submits a piece of content, we will refer to this user as the author. The content is not published and is sent to another user for moderation, we will refer to this user as the moderator.
The moderator can then either set the content from a moderation state back to a draft state for the author to amend or through to a "to be published state".
Once the moderator has checked the content and made amends they can mark the content as ready for publishing. At which point a third user which we will refer to as the publisher, can make further amends to the content and publish it, make further amends and send back to the moderator to check through the changes or mark the content as back to draft to allow the author to change it.