My First Foray into Developing on a Web Platform for Fun and (non)-Profit
A couple of weeks ago, I was looking for a short weekend project to get some experience building on a web platform. I looked at a few possible options and settled on building something for Wordpress, the platform I use for this blog. A friend of mine had a need for a blog he was setting up for his son’s school and it turned out to be the perfect weekend project.
User Stories
My friend told me that a problem they were experiencing with their blog was an inability to add users in bulk to the platform. Basically, they were using an existing plugin to generate newsletters that used posts on the blog as the core content, and they wanted to send those newsletters to an audience that was known in advance, but would not necessarily come to the blog to register themselves.
I did some poking around online and saw several mentions of frustration about not being able to add more than one user at a time to a blog so it appeared there was no existing solution available. I decided the problem was tractable for a weekend exploration project and set out to define a couple of basic scenarios for an alpha release.
First, there should be a “Settings” panel associated with the plugin that should allow an administrator to configure the default role applied to new users. For my friend’s situation, they only wanted to add subscribers, but I envisioned other scenarios were you would want to bulk add authors or editors as well and figured this should be pretty simple to build. In addition to the default role, the administrator may also want to set the delimiters used in the list of new user email addresses. This is a little technical for basic blog administrators, but a list of new user email addresses may be separated by commas, semicolons, etc and this seemed like a nice configurable option to have.
Second, there should be a plugin panel available in the “Users” section of the administrator’s site. The plugin panel should accept a delimited set of new user email addresses as well as allow the administrator to configure which role new users will have on the site.
Iterative Development
I first set out to write the “Settings” panel, which proved to have the steepest learning curve. I had used PHP nearly a decade ago and coming back to the language was interesting because so much has changed. I did a project at work that was rooted in PHP, but that had more to do with platform porting issues and a light application port, so it was nice to be on the other side of the fence. PHP is a very forgiving language, so much so that conventions you expect to work in C/C++/Java have unexpected behaviors in PHP. In addition to getting familiar with the language quirks, I had to get up to speed on the platform and how to utilize the plugin API. Thankfully I found a couple of decent “Getting Started” type guides to help me understand the infrastructure and mechanisms. I would recommend this one for anyone looking to pick up a similar project. Finally, I had to brush up on a little CSS/HTML as well, two technologies I hardly ever touch professionally.
After some trial and error, I had a functional “Settings” panel that would accept various option configuration from an administrator, persist them in the database, report its success and retrieve it upon further visits to the panel. I did some incremental testing to ensure this was very robust.
Next up was the plugin panel itself that would accept input from the administrator, parse it for valid email addresses, attempt to create new accounts for each valid email address in a specified role and email new account information to each email address. This part required diving deep into the Wordpress documentation and implementation. The documentation for Wordpress is lacking a bit as there is a Plugin API and a Function Reference and its not really clear what the distinction is since both sets of APIs are available to developers. Also, the documentation of some functions is just not available to a general audience, you need to be a Wordpress developer to see it, which surprised me a bit.
Regardless, I was able to work around some of these hiccups and figure out what was going on. The plugin is able to discern whether input is a valid email address, and if it is, whether it is already associated with an existing user account. The results are reported back to the administrator after they submit their input and emails are sent to new users with their login and password. The last part I was not able to verify until I deployed the plugin on this blog, as my testbed using XAMPP was not configured with backend mail support (not common for sandboxed dev/test environments).
Feedback from the “Customer”
Between writing the “Settings” panel and the plugin panel, I powowed with my “customer” again to clarify the requirements to ensure I was writing something that would be simple and useful for the school’s blog’s needs. This also gave me a good opportunity to clarify his expectations and explain how the plugin would be most useful if it was complementary to any subscription management plugin, rather than piggyback on its implementation.
Alpha Release
I provided my friend with an alpha release, including known caveats like the specific environment I was using to build the plugin. We quickly discovered some issues in the configuration of the blog’s deployed environment that created some compatibility issues. I managed to resolve this by looking into Wordpress functionality that mirrored what PHP offered without the same dependency on a PECL package.
I did think of a couple of minor revisions to make to improve the delimiter handling that I will add in over the next couple of days. After that is complete, I will submit the plugin to the Wordpress plugin codex and create a Projects tab on my blog to host it with some basic documentation. I will include other projects I build there as well. This plugin is being called “Bulk User Add” for now and I’ll post again when it is available.
Some Thoughts
All told, I might have spent about 10 hours tops on this project. If I had to do something of similar complexity again, I could probably do it in a couple of hours as much of the learning curve was spent on PHP, HTML and Wordpress API/documentation. It was an interesting endeavour, one that I was happy to see end successfully with the “customer”, my friend, more than satisfied with the capabilities and simplicity.
Moving on to other platforms and building more complex Wordpress plugins should be good learning experiences as well. I’m looking forward to it.
Just notes as I read your post…
- The delimiters shouldn’t need to be defined. Commas, spaces, and semi-colons are standard delimiters, your regex should just check for those delimiters by default, allowing the user to mix in any of them as a delimiter.
- I’m curious as to what your email address regex looked like. I’ve found that the regexes “published” on websites typically don’t contain characters like ‘&’, etc. We’ve had to modify our pattern a ton of times to get it just right.
- You might want to change the name of the plugin from “Bulk User Add” to “Giri’s Uber (but first) User Management System of User Managings”. =)
Regarding the delimiters, I forgot to mention this was a requirement from the customer. Like you mentioned there are common delimiters that are used but this was intended to be configurable because the list of addresses could come from a variety of sources.
The email address regex string came from the is_email function in Wordpress:
$chars = "/^([a-z0-9+_]|\\-|\\.)+@(([a-z0-9_]|\\-)+\\.)+[a-z]{2,6}\$/i”;
As far as the plugin name, well, I don’t think it’s much of a management system haha. We’ll see what else comes of it =)
Hmm, unless I’m reading the regex wrong (which is very likely, I’ve always had another developer do the regex stuff), your pattern doesn’t allow for ‘&’s. You should add an allowance for that and some other characters I can’t remember off the top of my head.
That’s still interesting that the delimiters need to be said. Regardless of the source, it would still seem that having commas, semi-colons and spaces be used as default delimiters would be pretty robust and fulfill 90+% of your needs. You could add tabs and pipes (|) to that collection and that should cover 99%. Not to belabor the point, it’s just that I like to see less options, especially when the solution seems easy enough to implement.
I can think of another good plugin you might want to build for WordPress, we should discuss it sometime.
I believe the regex permits what ICANN passes as valid email addresses. & isn’t permitted in email addresses. Given that this particular check has been tested millions of times on wordpress.com and hosted wordpress.org blogs, I’m guessing it’s working.
I have a default delimiter set that already covers the majority of cases, but in case customization is needed, as requested by the customer, it is there as a feature. You need to remember that schools work with a variety of different systems with quite a bit of legacy so I can understand why they might have this need.