As we looked at how we would upgrade all of our Drupal 6 sites to Drupal 7 we realized we had a big problem. Big as in over a thousand individual Drupal sites. We have become the victim of our own success in that we made it too easy to create new Drupal sites whenever we received a request, without first asking if a new site was really necessary. Drupal itself scales very well. It can handle much bigger sites than we currently have. By creating so many smaller sites we were actually making it harder for people to get around on our pages because larger sites became fragmented with no global navigation between the various units. It also made it harder for people to share data across sites, which caused unnecessary duplication of data input. Finally it created a lot of administrative overhead for CWS to keep this many sites upgraded.

We made it a strategic direction for Drupal 7 to begin consolidating as many small sites into their parent units as possible. We knew the first issue we would have to face is how to divide up the authoring responsibilities while maintaining ownership for different parts of a site. It turns out one of the reasons we currently have so many sites is because different people are responsible for content creation and wanted to make sure other people would not be able to modify their work. While this problem could easily be solved by just getting some agreements between the various authors on a larger site, we wanted to be able to assure people that we could prevent this possibility through Drupal permissions. We also knew that people wanted the ability for their sites to have some distinctiveness. While all of our Drupal sites adhere to the branding guidelines set forth by Web Communications, there is still room for sites to provide certain characteristics unique to their department or unit. We set out to find a solution for this.

What we came up with is a Drupal module called “Organic Groups”. The organic part does not mean that the groups were grown with abundant amounts of compost, but rather that they are flexible enough so that groups can be configured in a variety of different ways. For example we knew that colleges would need to build groups for their schools, departments, and programs whereas administrative sites would have a variety of working units that will need groups. After some testing we were confident that the Organic Groups module was going to suit our needs and so we started the work of communicating with people about our plan, and get some sites on board.

Central Web Services is a devision of Media Services which is in turn part of Information Services. There are a number of other units under IS including Enterprise Computing Services, Network Servies, and Technology Support services. When we began the task of updating the IS site using Drupal 7 it was agreed that we would consolidate a number of separate websites into the IS site using Organic Groups. The IS site is organized around the services that we provide. Each service is a group. Each group is also part of a service category. We are still in the process of converting all of this to Organic Groups but it looks like its going to work very well.

On the academic side of things we also have been working with the College of Liberal Arts to upgrade and consolidate their sites. We currently have the parent college site in Drupal 7 and are working with them to migrate the departments one a time from the old Drupal 6 sites. For a college the groups map nicely to departments which group into schools. Each department can have it’s own set of rotating features, highlights, directory listing etc. The department and school name also show up as the site name along with the college. Departments can have their own content editors, or and editor can work for several departments. There can also be college wide editors who can help with all of the departments if that is the way they want it.

Art department site name showing the school and college

Department name becomes the main site name, while the College and School names are combined above, with each linking to its respective front page.

Once we have completed CLA and IS we will begin working with other departments to consolidate and upgrade sites to Drupal 7 at an accelerated pace. The end result will be better websites for everybody.

smiley face at a bottom of a page pictureIf you have turned on Jetpack on your site, and are collecting stats, at the very bottom of your site you might notice a little smiley face.  If you are like me, you will find this just a little bit annoying.  How did it get there?  Is this a bug?  Is there something wrong with one of my posts?  The answer is no.  It goes back to using Jetpack and collecting stats. Since you are using the power of the WordPress cloud at wordpress.com when you connect Jetpack, WordPress inserts this to indicate stats are being collected.  Well and good, but if you are not in a smiley frame of mind, it’s very easy to fix.

jetpack-stats

To take the smiley off your page, go to the Jetpack dashboard, and click on the Configure.  In the configuration options you will see a checkbox to “Hide the stats smiley face image.”  Just check that and save and you are smiley free, and free to smile.

configuring jetpack smiley on or off images

 

With this next update of WordPress, we have updated WordPress core as well as plugins, and have introduced a new plugin called Jetpack.

What is Jetpack?  From the makers of Jetpack, they say “Jetpack supercharges your self‑hosted WordPress site with the awesome cloud power of WordPress.com.” 

From our standpoint it is a number of WordPress modules that will add some benefit to your site, including site subscriptions, posting a blog post via email and more.  But to use Jetpack you have to understand the peculiarities and actually see if some of the features will work with the theme that is being used.  In a nutshell, the theme has to be able to support Jetpack.

Jetpack Modules

We are outlining some of the steps and peculiarities that we have encountered in our testing with the OSU Responsive theme which is the primary theme we are testing against at this time.  All other themes are unsupported for Jetpack at this time.

Steps to use Jetpack

1.  First you will need to connect to wordpress.com, which means you need a wordpress.com account.

Best practice for departments and organizations.  Create a wordpress.com with a generic account.  That way it can stay with the organization rather than with an individual.

Why do you need a wordpress.com account?  The plugin itself uses wordpress.com’s cloud infrastructure to do some of the processing, and where we can offload some of this is a good thing.

2.  Then connect to Jetpack from the Jetpack Dashboard.  Once you connect to a wordpress.com account, you will see the Connected in your Jetpack screen navigated to from your Dashboard.

 

 

 

3.  Next is to look at the variety of options and activate the ones you would like to use.  Please note that not all of these might work with the theme that is being used.  For OSU Responsive, WordPress.com Stats, Subscriptions, Carousel, Like, Post by Email, Sharing, Contact have all been tested in our limited testing capabilities.

Please note the Contacts feature of Jetpack is not compatible with the Sociable plugin.

You can disable Sociable under Plugins menu located on the left in your administrative menu.

So you get all that done and you decide you don’t want to use one of the features any more.  But where to turn it off?  It wasn’t intuitive when I first went looking for it, that was certain, but a quick Google search found the answer.

Jetpack Configure Button for Deactivating

Once a Jetpack feature is activated, there might be a configure button there.  If it is clicked, it will expand the area, and it is in that expanded area that the Deactivate button will be.  Why there?  I don’t know but after using it a few times, I was able to manage remembering where it was the next time around.

Overall it looks like some good pieces are there.  As you are using this, remember to keep in mind everyone.  There are accessibility policies to keep in mind, as well as just a general sense of if you really will be using  a a feature that is activated.  As we get more information we will put up, but the best thing right now is to visit the Jetpack site for more information.  We’ll be writing more as we use the features ourselves.  As always we would love to hear your feedback, so try out the contact form that we’ve just put in as part of the Jetpack feature set and send us some feedback about your experience with Jetpack.

In the intervening time between our blog posts, we still have some work to do to fix the Responsive menu structure.  More than one level deep in a menu and it isn’t too useful and on the mobile side, the mobile menu has a bug we know about that does not expand it beyond a certain length, making part of the menu not visible.  That fix is in the works.

At this point, however, we want to give you the ability to take off with Jetpack.

One of the issues that had plagued EvalS (an evaluation performance application/portlet) from the beginning was a performance issue. EvalS was the first jsr 286 that we wrote for the Luminis portal. During the first several releases we worked hard to improve the performance by reducing the # of queries and caching whenever possible. In the past, whenever a person would first load the portal page containing EvalS it would take about 5-6 seconds for it to finish loading the page.

This EvalS performance defect affected all users, only after their initial login. This type of performance was not something we were proud of, so over time we worked on improving the code base, and performance of the backend code. A few months ago, we dedicated some resources to finally fix the problem once and for all.

Our initial assumptions were that the EvalS specific code was slow due to it not being optimized for the number of employees and jobs at OSU. This assumption proved to be incorrect once our development environment included enough random data to match the amount of records in production. After a careful analysis of EvalS and the differences between production & development, a small piece of code external to EvalS, but which EvalS relied on was the identified as the culprit.

The problem:
When a person first accesses EvalS, the application needs to figure out the ONID username of the person. It was this piece of code causing the problem and slowing down the application for the person when they first logged into the application. We never expected this piece of code to be a problem, that’s why we didn’t look into it at first.

The Luminis portal doesn’t store the ONID’s username in the User_ table of the portal. Instead it uses a random # and stores it in the “screenName” column. This is the column where the ONID username would usually be stored. We use an sql query to translate between the random Luminis # assigned to each user and their ONID username. One of the joins this query was using didn’t contain the necessary indexes. This was making the query slow.

The solution:
The fix was rather simple once the culprit was identified. The owner of the external query created a new table that we queried instead. This table contained the necessary data along with needed indexes. EvalS now queries this table and the speed has improved drastically.

We should have challenged our assumptions when we were troubleshooting this performance issue, but we have learned some valuable lessons from our mistakes, which will be helpful in the future. In current and future projects, we now test & analyze the performance of the application early during the development stages. Our development environment now includes enough random data to match the amount of data in production and allow for growth.  Moving forward in this way allows us to demystify application behaviors.

 

vote button with text "primary election ballot opens at 10pm april 9th" and "general election ballot opens at 10pm april 21st"

It all started with a simple question, “Can CWS help us build a website that our student body can use to vote with in our April elections?”

The question, posed by ASOSU Organizing Coordinator, Drew Desilet, came to CWS in mid-February.  “When it came time to look at building or buying a new voting system for the student government elections, it was clear we had two options. We could choose to buy an outside product that came pre-made to someone else’s standards and needs, or we could work with our own CWS partners on campus to build us something to suit our needs.” he explains.

It should be clearly understood that the delivery of a complex, finished website or web application within a two-month timespan is a mighty tall order.  Additionally, there were a few tricky specifications that the site needed to meet, one of which includes the ability to limit the voting population to a specific segment of the OSU community, namely, Corvallis campus students.

Ultimately, the answer given to ASOSU was “Yes, we can.”

It did take a few extraordinary elements to get it up and running on such a short time-line, though:

  • Great customers who provided exceptionally clear specifications
  • A rockstar programmer who didn’t miss a step from the beginning to the end of the project
  • A diligent project manager who smoothly coordinated all those extra things that threaten to derail a web-development project
  • The OSU Drupal profile, combined with the Election module, a special contributed module that can be found at drupal.org

“We’re very pleased with the way this project played out.” states Jean Waters, CWS project manager.  “Using the Election module really helped us get this project up and out in such a short time.  In fact, there are still some really nice features that came with it that we haven’t even had a chance to fully examine yet.”

The Election module is based on a new Drupal 7 concept known as “Entity”.  This is still a fairly new concept to the Drupal team here at CWS, but team member Ricky Middaugh was up to the task. “It was a unique challenge, having to work on something in Drupal that I didn’t know a lot about.” comments Middaugh.  “But I’m really pleased that we were able to provide something useful to OSU.”

And the ASOSU provisioned gift just keeps on giving, explains Jos Accapadi, Associate Director of CWS. “Thanks to ASOSU’s willingness to experiment with us, the groundwork has been done, and now we’ll be able to quickly spin up sites for other political organizations here on campus.”

Desilet agrees. “We’re already working with CWS to make system improvements for future years – mobile capability, streamlined candidate entry, candidate profile pages, and a few other minor changes – the voting system has worked out very well for our needs in the ASOSU, and it’s our hope and plan to continue using it for years to come. It’s a system other groups on the OSU campus, or really even the entire Drupal user base, can use for a voting system in the future. It would be nice to see this used across the university for any type of voting, and make it as common to ONID users as BlackBoard is now, or Gmail is to come.”

The new voting site has already passed the Primary election test, during the week of April 9th – 12th.  “So far we’ve had 2,118 voters run through the system without any hiccups of which to speak. Modifications for us between our first Primary election and our General election were minor, and largely administrative based. Therefore the tool the students will use will look and feel the same as the first time they used it just weeks before, however it will work even better for us as election administrators.” says Desilet.

The site will be ready for use for the General election, starting Sunday, April 21st, at 10 p.m. and running through April 26th.  Voting will be open to Corvallis campus students.  To get there, just go to http://asosu.oregonstate.edu/elections and click the big vote button.

 

 

You just put the finishing touch on your Drupal site, all the images are just right, the calendar feed has your events displayed and every bit of content is informative and engaging. It sounds great, but here are some things you should know about live sites and some checks you should do for your site before deployment.

  • Links, images and navigation, these are the cornerstones of a good site. We have some ‘best practices’ items you should check before pushing your site live.
  • Menus – part of the navigation system your visitors depend on in order to find relevant content on your site.
  • Brand Identity Guidelines for OSU web content. Does your site measure up to University expectations, we’ll show you how to find out.
  • Do you have contact information? It can be very aggravating if a user doesn’t have a way to reach out to someone in order to have a question or concern addressed.
  • What do you need to do after your site goes live? Yes there are things you should check after your site is moved to production.

All of these items and others are covered in detail at http://oregonstate.edu/cws/training/book/drupal-deep-dive/osu-drupal-site-procedures/drupal-deployment-checklist.

 

CWS is happy to present Doug Fir, the latest theme in the OSU Drupal 6 distribution.

the web, table, and phone views of doug fir
Doug Fir – What Responsive Looks Like

Designed by WebComm and engineered by Central Web Services, Doug Fir has been developed similarly to OSU Standard in regards to configurable theme options, integration with Google Analytics, and layout regions, but it sports a fresh, clean look which is consistent with the default theme that will be supplied in our upcoming OSU Drupal 7 distribution.

Using Doug Fir provides us with two distinct advantages:

  • It allows OSU Drupal 6 sites to look like OSU Drupal 7 ones from the front end.  What this means is that you don’t have to panic if you’re not ready to roll into OSU Drupal7, instead you can just easily switch the theme out by following the Switching to Doug Fir instructions found in our CWS Training site. (We realize that sometimes these things can seem tricky.  If, after reading over the instructions, you still feel nervous about making the switch, just submit a Help Ticket to us and we’ll be happy to lend a hand.)
  • The bigger advantage to using Doug Fir lies in the fact that the theme is responsive.  What this means is that the display will automatically adjust, as needed, to fit the screens on your mobile devices.  It doesn’t matter if your device is a tablet or smartphone, the responsiveness of Doug Fir will give you a nicely formatted appearance.

Want to see for yourself how a responsive theme works?  It’s really easy to do.  Just go to a site with a responsive theme and resize the width of your browser window.  You’ll immediately see how the layout responds.  Take a look at a couple of early adopter sites who so graciously assisted us in the development of this theme: OSU Admissions and TAC (Technology Across the Curriculum).

So let’s talk Drupal 7, and some bits and bytes about Drupal in general.  Central Web Services maintains a central Drupal installation.  Like any piece of software, it has multiple versions.  Drupal 5, 6, 7, and 8 which is in development.  The CWS stable version is Drupal 6.  Drupal 5 is no longer supported.  Right now we are getting numerous requests for Drupal 7.

We want to let you all know that we are actively working to get Drupal 7 tested, documented, and functional for the needs of OSU.  Well, why can’t I just get it now, it’s just a download, you ask?  The answer is, while if you were hosting on your own ISP this would be the case, the OSU infrastructure is such that we have to ensure security, reliability as well as integrations with other solutions, such as authentication, themes and modules in use by OSU CWS Drupal sites.  We have a number of concurrent activities happening to make progress toward rolling this out for the University, including actively working on the theme necessary for Drupal 7 (yes we have to rewrite the theme to work for new Drupal versions).  This is in partnership with the rock-star team over in Web Communications.

Now more importantly, what we are trying to do with Drupal 7 is reduce our site footprint and number of individual sites.  Can you believe we have over 400 sites?  That becomes a maintenance and support headache.  With Drupal 7, there will be a new feature called Organic Groups.  This will allow us to have a smaller subset of sites, and areas and departments within the same site but still allow the finer grained control that some of you desire.  With Organic Groups, you will be able to take control of the portion of the site that is your relevant content, and have control so others cannot access that portion of the site as a Drupal administrator to modify something in error.  This is where we want to go and what makes sense for Oregon State University.

So when will this be done?  With Organic Groups, we are in the pilot stage with Information Services, and then we are going to ensure we have it done right by piloting the College of Liberal Arts.  Doing this we will ensure we understand the technology well enough to teach, document, and support it going forward so people are not left out on their own to figure things out.

Individual main colleges in working with Web Communications can look at Drupal 7 with the Doug Fir Theme (the theme that we have available for Drupal 7), and then incorporate changes for Organic Groups as we roll that out.  Science and Liberal Arts main college sites are already in Drupal 7.

Departments however, we will not be rolling out with Drupal 7 at this time, as they are to be incorporated into Organic Groups, working with your colleges, once we roll out Organic Groups.

For those sites that are in Drupal 6 and want to look like the main college sites that are using Drupal 7 Doug Fir, we are working on a version of Doug Fir for Drupal 6.

What is Doug Fir?  So besides being an evergreen confier species, Doug Fir is an OSU responsive Drupal theme.  This means that the site resizes depending on the device that you are on.  Liberal Arts is a good site to see using this theme.

For us it is imperative that we do this right and do not add to the overhead and support it would take to enable OSU.  This is why you might hear us say that we are not providing Drupal 7 to individual sites at this time.

Our rough timeline as of now is:

  • Spring and Summer to test and roll out Organic Groups.
  • Winter:  Migrate Drupal 6 sites to Drupal 7
  • 2014 Drupal 6 moves to maintenance fixes only
  • 2015 End of Life (EOL) Drupal 6

With all of this we are re-architecting the infrastructure, and then we will have Drupal 8 on the Horizon.

We hope this information helps you to be aware of the progress we are making.

On Monday, February 18th, if you hadn’t seen information about or attended the training sessions, Central Web Services and Media Services released a new version of Kaltura’s MediaSpace.  This is version 4 of MediaSpace.

The new version of MediaSpace, OSU’s open source and cloud-based media solution, integrates many requested features and some important new functionality, including privacy / access control, captioning, HTML5 support, and improved layout.

One of the best ways to understand the new features is to watch the video in MediaSpace about the new version.

Every department hopes for collaboration and cooperation among all of its members. Here at Central Web Services we are working towards making that a reality. In September, our office had a face lift. Out went the dull grey cubicles and in came new wooden desks and an open work space. The removal of the cubicle walls created an open and inviting workspace. Here are some pros and cons we’ve noticed since the redesign:

 

Pros

  • More space in the office
  • Easier to talk to one another
  • Collaboration among different areas within the department is easier
  • The office appears brighter and more inviting
  • Seeing who’s in the office at a glance

 

Cons

  • Nosier at times
  • No cubicle walls to hang things on
  • Spontaneous drop-ins by visitors can cause more disruption then previously

 

Although there was some hesitation on taking down the cubicles, we all agree that the change in the work environment has helped strengthen the team dynamic.