We’ve all now attended the Project Management Essentials training, so we’re hoping that the processes we learned through that will help us to be super-efficient. We’re also using some new project tracking and wiki/collaboration software, so expect a post from Matt on that soon.
Currently in the works:
Distributed Content Management – allowing users to authenticate to the site through LDAP and edit/create content. This is tricky because we need many levels of permissions and roles, and we need to make sure that the publishing workflow is set up correctly to notify content managers of new and updated content. We’re hoping to roll this out soon because it’s been a long time coming, but we’re switching from Workbench to Revisioning because of a conflict with the Workbench module, so that’s set us back some.
Map & Virtual Tour – Fixing and vastly improving/developing a new campus map and virtual tour. This project is in its infancy but promises to be really great for prospective students.
Updates to Majors & Programs – Fixing some issues, rearranging some content, and improving the search/filtering functionality so that site users can find what they’re looking for more easily.
We’ll also be working on some Cascade updates, WordPress additions, a new social feed for Admissions, a revamp of our internal menu system in Drupal, and a responsive design for our Drupal site. Not to mention the coming of Luminis 5! It’s definitely going to be a busy summer in Web Services.
Something so small and silly, but that can break a site. I forgot this last week and ran into some trouble. When you’re writing a module file, never put a closing
tag at the end of the file. My editor did this automatically, and I didn’t run into trouble until later, and I realized what the culprit was. A rookie mistake, but easy to make – and luckily, easy to fix. The issue it was causing was adding a blank link to the top of our xml news feed – which caused errors in reading it. The two seemed unrelated, but that was the fix. Deleted the closing tag, and the feed was fine.
Today I was trying to override the html output of the Custom Breadcrumbs module, which put a double right arrow quote, or », in between the breadcrumbs, along with strange spacing. I couldn’t find where in the module this was being output, so I went looking through the core functions, but that’s super tedious. So I thought, “well, let me just search for the double quote and then I can see where this is being output!” So I searched for the html encoding string, which is
Yeah, no relevant results, mostly just jQuery files and a couple of .inc files. But of course, searching for the actual character led me to the theme_breadcrumb function. I overrode the function in template.php, where I was able to wrap the output in a span and add a class so that the spacing would reflect our styles, and change the divider. And now I know. Drupal core doesn’t user html encoding in its files.
Our site suffers heavily from an incomplete and in some places non-existent ID (Information Design) process – the process of figuring out what needs to be on the site, where, why, and how it will be organized. And then we wind with problems like this. We have a set of pages with this word in their path, so this whole section is:
/thisword is also a page. But it’s a blank page, with no information, only created to be part of the menu structure. And it’s accessible to users, because the breadcrumbs go:
Home> Thepagebefore > Thisword > Current
So you can click on it and get to this empty page. Our current breadcrumb implementation is a custom one (not built by our current team) and is not extensible enough to allow for items in the breadcrumbs that do not exist as a page in the path (as it pulls by path and not from the menu.) Luckily, there is a module, Custom Breadcrumbs, that will allow us to do just that. It is set up to follow the menu in all instances, but you can override individual paths and set your own breadcrumbs – for instance, adding a non-linking “thisword” in the breadcrumbs. It’s not fully implemented yet because I have to reconcile the module’s attempts at styling with our own styles, and they are set up differently, but the functionality is there.
However, the lesson here is that if you complete an exhaustive ID process, you will not wind up with empty pages that only serve as an item in the path to identify the section of information that follows it. In fact, this entire section came after the fact and had to get thrown on – more ID work may have avoided this problem entirely.
We’ve discovered that our site (sadly) has an issue with CKEditor and Webkit – A known issue in webkit browsers for quite some time (http://dev.ckeditor.com/ticket/8266). This is really irritating because many of our content contributors are going to want to paste from Word. And because Word has such horrible markup, CKEditor has issues and adds in empty paragraph tags all over the place. Luckily, the solution is as easy as using Firefox to update the site, but of course that’s not super convenient if it isn’t your browser of choice. I’m going to keep an eye on this issue and hope to find a real fix or better work-around soon.
We are currently trying to add more content managers to our Drupal site so that the University can be more responsible and active in keeping the website up to date. We’re starting with University Communications and the news team. I made a Content Manager role and a News Editor role for them. The problem with Drupal is… permissions. So many permissions. Our site has 338 permissions. Each of these has a checkbox. For each role. So, creating this in my local install, then in our staging instance, and then on the live server would be very, very, tedious and probably give me carpal tunnel.
Matt, our resident expert, has been long touting the virtues of Features – the ability to export just about anything from Drupal and then import it as a module, thus saving lots and lots of work. However, roles don’t export very well. The first time we tried it, we checked off all the permissions, and on import, lots of things got messed up. The next time, Matt suggested we try installing the Role Export module and only export the permissions that were needed by the new roles. We enabled Role Export on the staging site, enabled the Feature, and all was well! Test accounts were made, and hopefully the news team will soon be able to work in the Drupal site. Ideally, we’re working towards having faculty be able to update their own profiles (and only their own profiles), thus cutting down on content entry work for our team.
We’ve been working on ways to better track our issues and projects while we update and change things. One neat integration that we implemented today is Bugherd (which we are using for issues within the Drupal site) and Github (where we keep our code). We can now fix Bugherd tickets and close them just by mentioning them in the commit message to Github.
“Use commit hooks to update bugs quickly from commit log messages. That way, you can say things like “Changed X to Y, this fixes BH-123″ and it will update your BugHerd bug #123 with that message, and change the state to done. “
Matt also integrated Github with our chat client, Hipchat, so that we are notified of commits and merges, so we can see what the others are up to and when we are ready to push and go live with changes, which is really useful.