New Search Engine

A slightly early holiday gift from the web team: new search!

Just before break, we finished our migration away from our Google Mini to Google’s hosted Site Search. We hope you’ll find it more reliable, more accurate, and easier to use on your phone. Try it out at, or using the megamenu at the top of most Lane web pages.

Happy Holidays!

Media Server SFTP & FTP support ending the first week of January, 2015

We will be turning SFTP access to files off the first week of January, 2015. After the first week of January, 2015, all files must be managed through Filehost.

The only change to files is that you will add, delete, and update them through Filehost instead of through a ftp client. Everything else stays the same.

To manage your files through Filehost, just navigate into your ‘mediaserver’ folder. That folder is the root of your account. So a mediaserver/foo.txt file can be viewed at

This also applies to and accounts. The username/password for these accounts should be the same as when you used to use SFTP.

Remember that there are several ways to manage files. See

The web interface at is great for single files or deleting a folder. WebDAV and the sync client are best when dealing with many files.

For more information, see:

As with the Media Server, support is provided by the ATC. If you need help, just ask.

Evaluating the new search engine

New Search Feedback

  • We can't always get back to people, but if you'd like us to try, you can leave us your contact information here
  • This field is for validation purposes and should be left unchanged.

Some Announcements

Over the last few weeks, we’ve added some features to Drupal that may interest you.

First, we’ve added some new buttons to the WYSIWYG editor:

  1. The “K” button works much the same way as the Flickr button, and allows you to embed Kaltura Videos (hosted on For more information, talk to Dean Middleton
  2. The map button allows you to embed the new style Google Maps maps. Google changed both the Google Maps interface and the embed codes recently. If you see a white box on the left hand side of Google Maps, you’re using the old version, and should continue to just paste the map link into the WYSIWYG on its own line, like always. But if Google Maps takes up the entire screen, you need to copy the embed code and paste it using the new Google Maps button in the toolbar.

Second, we’ve had some problems with revision messages. Here’s a real life sample of some of the message we’ve seen the last few weeks:

  • z
  • .
  • Revised page
  • Update1
  • page update
  • routine
  • same
  • got it

Clearly, these are incredibly unhelpful. Log messages should be concise and descriptive. Here’s some great ones:

  • Revised office hours and added fall term hours
  • Update reference to Retail AAS
  • added IT maintenance window event spud
  • updated links to event flyers
  • added link to BP040

When we’re trying to figure out when something changed, it’s a lot easier if we can skim through the revision log. And it helps you – that way you can see who else changed your pages, and what they did.

Due to the number of really poor revision log messages, we’ve been forced to add some checks within Drupal for obviously bad ones. If your message doesn’t meet the terribly low bar we’ve established, your node will not save, and you’ll be asked to enter a better message.

Remember, if you find yourself constantly entering messages like “Trying again” or “One more time”, you should try using the Preview button to make sure what you’re adding is what you want. That way you’re not creating 3 or 4 revisions for one small change.

There’s also a couple of people who include their initials with the log message. Although we used to really like having that information when we were using Contribute, we track your login when you make changes now, so there’s no need to also have your initials. Save a few keystrokes!

Finally, we’ve also open sourced a piece of our Drupal Migration. if you visit our GitHub page, you can find the source of our Migration Tracker, which kept track of the old and new URLs, and made it possible for us to migrate over several months, rather than needing to do it overnight.

Filehost has been upgraded to OwnCloud 7

Filehost has been upgraded to the latest version of OwnCloud. Here’s a very brief overview of some of the changes:

  • Responsive UI. Now it won’t look so bad when you are browsing the web ui on your phone or tablet.
  • The left nav bar is now a drop down that appears when you click the menu to the right of the OwnCloud cloud icon.
  • There is now a sidebar on the left that makes it much easier to figure out the status of your shared files.
  • To find the webdav link, just click the gear icon in the bottom left corner.
  • There are now limited odt and doc editing capabilities. Very limited. Just select Documents in the nav menu.

I’d also encourage you to check and update your sync clients if there’s an update available.

A Static Server

As I may have blogged once or twice previously, making websites really fast is important to me. Recently, we’ve made a change that should help us improve the speed of not only, but of many of Lane’s other websites, including this one.

When you request a webpage, in addition to fetching the page itself, you usually end up requesting each individual image, font, css sheet, and javascript sheet. Making those requests is expensive. There’s a sliding window, which limits how many requests you can make at once. So if the window size is 5, but you need to make 6 requests, you need to wait for one of the first 5 requests to finish before you can make the 6th. On the other hand, if you only need to make 5 requests, your browser can start rendering the page a lot sooner.

One way is to combine images into a css sprite. Here’s ours:

Lane's CSS Sprite, which combines social media and other common icons and images from the website into one image.

That’s 15 different images combined into one. And even though there’s empty space on the bottom right, it’s actually usually faster to fetch a slightly bigger image then it is to fetch each icon individually.

Another way is CSS and JavaScript aggregation. Most pages on our website have 35 CSS sheets and 35 JavaScript files – but after aggregation, you only end up requesting 7 of each (there’s reasons why 7 of each is better then just 1 CSS and 1 JS, but that’s outside the scope of what we’re doing here).

But the easiest way to speed up a request is to not make it at all. When you make a request, you send some request headers with it, that tell us things like if you’ll accept a compressed version and what language you prefer. Then we respond with a header that tells you how long you should keep our response cached on your computer. If you need that resource again before the expires time we gave you, you just use the local one, rather than fetching a new one.

In addition to sending headers with your request, and us sending different ones, we also send each other cookies.

A picture of some cookies

baked by

Cookies are always set on a domain. When you log into Moodle, cookies are set on the domain, so Moodle knows on every page load that you’re logged in. But here, on the Lane website, we’re not so lucky, as you can actually use the website on either, or on just So we set our cookies on That little dot before is critical. That tells your browser to send your cookies to all domains that end in

The downside is that those cookies are sent on every request to our domain – even requests that don’t need them, like the request your browser made to show you the picture of those cookies up there.

What does this have to do with static?

We’ve started moving relatively static (unchanging) resources, like the college logo and the megamenu onto the static asset server, which we’re putting on the domain Since these resources are relatively unchanging, we can set a long expires time – maybe 30 or even 45 days in the future (for now, it’s set to 0minutes in the future, for testing). Once your browser has fetched them, you won’t need to fetch them again for a whole month. And because they’re not under the domain, you won’t send any cookies (and we won’t send any back), making the few requests you do need to make even smaller.

If you’re really curious about the inner workings of our new static asset server, I’ve added some extra geeky content to the Our Tech Stack post.

In the months to come, we’ll keep migrating content onto the static asset server, trying to reuse resources between websites, so that the logo you see on myLane is served from the same URL as the logo you see in Moodle, reducing the number of requests you need to make, and making it simpler for us to update things in the future.

New Changes to the Employee Directory

This is just a quick post to point you to the new changes available when you edit your employee directory profile.

First, the office hours field has received a WYSIWYG editor. That should make it much easier to format your hours.

Second, we have added a new Professional Biography field. Basically, it’s a place where you can add extra information about yourself that will help students and your fellow employees accomplish what they need to here at Lane Community College.

I’d also like to note that a most people have no picture in the directory. It’s really easy to add a picture, so I’d encourage you to do so!

In case you’ve forgotten, the link to log into the directory is in the footer of every directory page. It’s labeled “Edit/View your Directory Profile.” Only employees who are in the directory can log in.

Announcing Filehost: Lane’s very own internal cloud storage!

As of right now, every single active Lane Community College employee has access to their own account. They just have to log in with their normal L# and passphrase combination.

What is it?

Filehost is a Lane specific file syncing and sharing service, running on an application called OwnCloud. It is a service very similar to Dropbox, you could almost call it a clone. OwnCloud is an open source application that we manage ourselves, on our own hardware.

OwnCloud’s sync apps keep your files synced across almost any device you have, Mac, Windows, Android, or iOS. To manage sharing files, and single file uploads, there is a web interface accessible from any modern browser.

Details about the service

Log in information:

Filehost log in screen

Other information:

  • How much you can store: 10GB
  • If you need more storage, contact the ATC.
  • If you had more than that in your current Media Server account, your space should already have been expanded.
  • Filehost internally saves deleted files for a time. Don’t rely on it, though.
  • Backups are completed daily and stored for 14 days. If you need something restored that is not in your deleted files section, contact the ATC with the path to your file, and your L-Number.

How could you use it?

Screenshot of Filehost share dialog

  • Share a folder with contents from a project between everyone who is working on that project.
  • Embed an image, mp3, or video in a Moodle course.
  • Share a password protected directory with your students.
  • Keep your Lane related projects synced between your home computer and your work computer, all without involving third party services like Dropbox or Google.

Wait a sec, what about the Media Server?

Embedding media in Moodle courses and sharing folders with students is something already provided by the server. Thus, a really good question arises. Why not just use the Media Server?

The answer: As soon as we can do so without causing instructors and students a lot of problems, we will be retiring the Media Server from service. Don’t panic, you will not be losing any data, and we will make sure to let you know of any major changes before the changes actually occur.

Why retire the Media Server?

The main reason we are retiring it, boils down to security. The Media Server runs on software that is not easily upgraded. Thus, when that software releases a security update, it can take a while for us to get that update applied to the Media Server.

So far we have not had any problems. But, prevention is a much better method than having to fix things after we’ve been hit. So, what we need to do is move the Media Server to a platform that is easily updated. That platform is Filehost.

We also want to provide a better user experience. The Media Server is only accessible with a FTP client. FTP clients are not all that easy to use. The ATC frequently has to help users with them.

Even just the initial set up of a Media Server account is a bad experience on both sides of the system. The user has to talk to the ATC, the ATC has to talk to the sysadmin, the sysadmin has to set the account up, and then the ATC has to talk to the user again. The way Filehost just lets you log in if you’re an active employee, is much better.

Password protecting files on the Media Server is so painful, we stopped telling people we could do it.

All in all, retiring the Media Server will give users a better experience, and make maintenance issues simpler. It’s a win-win for both users and supporters.

What about my Media Server account?

File access

If you have a current Media Server account, you can already access and manage your files through Filehost. If you log into Filehost, you will see a directory call “mediaserver”. That directory contains the exact same content as you would see in your ftp client. Uploading/deleting files via Filehost does exactly the same thing as if you did so via your FTP client.

At this point in time, you are strongly urged to use Filehost for all Media Server file management. If you have issues, contact the ATC.

Eventually we will turn off FTP client access to Media Server files. Of course, we’ll give you plenty of notice beforehand, and you will always be able to manage your files via Filehost. urls

We currently plan on keeping your urls working, even after FTP client access is turned off. The complicated part is that we would like to eventually retire the urls and free up for other uses.

Of course, that would mean a bunch of your links would stop working. So we have to figure out how to turn off the urls without causing you a lot of problems. We’re still figuring that out.

Rest assured, if we ever do figure it out, we will give you plenty of notice.

For now, your URLs will keep working the way they always have.

All that said, it would be awesome if you’d start switching all your links to Media Server files over to links from Filehost. In the long run, sharing via Filehost will provide more features than anything the Media Server urls can do.


If you are running a website in your Media Server account, then sharing the mediaserver folder in Filehost, could open up security issues. Specifically, the way Filehost shares folders would enable people to download your site files. Including any dynamic scripts or other files. So, if you have a website on the Media Server, do NOT share the mediaserver folder in Filehost.

If we do retire URLs, then all sites hosted on the Media Server will cease functioning. Filehost only serves files. It cannot serve websites. If you need a website hosted on Lane servers for functionality not provided by Moodle or, then come talk to us. We do have a solution for you.

Usage Guidelines

Resources at Lane are not infinite. No matter how much we try to make them so. Thus, we ask that you only store college related files on Filehost. Please do not store personal music, pictures, books, etc.

We’d also ask that you make sure to share all your files with appropriate people. In the event you are unable to work, we don’t want essential files trapped in your account when your backup person needs them.

(Side note: in development is a way to share with groups of people, it’s still buggy right now, so we aren’t releasing it, but in the future you’ll be able to share with your whole department at once, instead of selecting each individual member by name.)


Filehost is an awesome new service that should help increase productivity. We hope you enjoy it!


IE8 Support Discontinued

Last month, for the first time ever, Internet Explorer 8 usage on the Lane website ( slipped below 3% overall. Normally, we discontinue support for a browser when it dips below 5%. But IE8, as the most recent version of the default web browser supplied with Windows XP, got a special exception.

But, unfortunately, supporting Internet Explorer 8 requires a disproportionate amount of time, and since that usage continues to fall, we’re making the decision to no longer actively develop webpages for IE8.

We will not be removing any existing support, so the Lane website should continue to look mostly ok in IE8 for some time. But, eventually, it will start to break. For that reason, we recommend you use a more recent browser that does work on Windows XP, such as Firefox, Chrome, or Opera.

Of course, if you are stuck using Windows XP, we also recommend that you consider replacing or upgrading your PC as soon as possible. Microsoft will be discontinuing support for Windows XP this year, meaning it will soon no longer be receiving security updates.

Lastly, there are a couple of applications on campus where the recommended browser is IE8 – notably Banner. If that sounds like you, have no fear! You can continue to use IE8 to access Banner. But you should use one of the other browsers – like Firefox or Chrome – for all of your other web browsing needs.