Category Archives: Uncategorized

Embedding Google calendars in WOU WordPress pages

This is a question that’s come up several times as people are migrating departmental sites into WordPress. It seems WordPress doesn’t like iframes, and they don’t consider that a bug. While I agree there are still a few security concerns with iframes, they aren’t nearly as much of a scream-and-run-away as they were in older browsers.  WordPress still considers them too much of a risk, and won’t let anybody except a global administrator put an iframe into a post or a page.  If anybody else does, that code just gets stripped out when they save the page. And if an admin does put in an iframe, as soon as anybody else edits the page, the code gets stripped. That’s why some people were seeing calendars disappear.

Luckily, someone wrote a WP plugin that lets any editor put in iframes as shortcodes. That plugin is activated on all our sites. So here’s what you do to get a google calendar embedded into a WP page:

  1. Get the iframe HTML code:
    In Google Calendar, look in the My Calendars sidebar for the calendar you want to embed in WordPress. In the dropdown menu for that calendar, click settings to go to the settings page. On that page will be a snippet of HTML code you can use to embed the calendar. That snippet will look something like:

    <iframe src="" style="border: 0" width="800" height="600" frameborder="0" scrolling="no"></iframe>
  2. Put that code into WordPress:
    Edit the page where the calendar needs to display. Paste in the HTML snippet, delete the </iframe> from the end, and change the angle brackets to square brackets. The snippet should now look something like:

    [iframe src="" style="border: 0" width="800" height="600" frameborder="0" scrolling="no"]
  3. That’s it!
    Just hit Update on the page to save it, then view it.  If you don’t see the calendar, let me know.

Oh, and this trick works on any iframe, not just Google calendars.

IP address detection in PHP

In PHP, the standard way to get the user’s IP address is from the $_SERVER[‘REMOTE_ADDR’] variable.  Unfortunately, that doesn’t work on our main webserver.  That’s because that server is really several servers sitting behind a special server called a load-balancer.  When anyone goes to, they are really going to the load-balancer, which hands off the request to one of the actual webservers.  This is a fairly common setup in the web world, because it means the whole website will no longer go down if a single webserver fails.

Unfortunately, there’s a drawback.  Because of some peculiarities of our network setup, when the load-balancer passes a request to one of our webservers, that server sees the load-balancer’s IP address instead of the actual user’s.  If you code in PHP on our server, you may have noticed that $_SERVER[‘REMOTE_ADDR’] always has one of four specific IP addresses. (Though you might expect only one from my oversimplified description just now.)

Luckily, we now have a workaround. Dave McEvilly figured out how to have the load-balancer include the user’s actual IP in a new, custom variable when it hands the request to whichever actual webserver it chooses.  So the normal ‘REMOTE ADDR’ variable still has one of those same four addresses, but you can use $_SERVER[‘HTTP_WOU_REAL_IP’] to get the IP of the user who made the actual request.

I know this was a pretty technical post, but as always you can contact me with questions at


It’s already added to the standard template, so after you have called the topinclude file, you can


Tap-tap-tap… is this thing on?

*blink* *blink* Wait, what?  It’s September? Can’t be! 

But… you’re telling me it’s the end of September? Stop joking around, that’s not funny! 

…waaaait, where did all those students come from?

So yeah, joking aside, it’s been a while.  I’ve been neck-deep in LDAP server migration stuff for way too long.  The migration scripts I thought would just take a couple of weeks actually took a lot longer than that, but at least they’re working now. Any new users, or changed to existing users, are now copied nightly to the new servers.  Same with groups.  And I just figured out a way to make the user script a lot more efficient; it used to take like half an hour and now it’s down to three minutes and change, so we’ll be able to run it more often.  I’m tempted to do the same with groups, but it’s already not very long so I’m not sure if it’s worth it.

That’s all for now.  I still can’t believe we’re almost to October!

Current project

My main project right now is redoing the Calendar of Events submission and admin system.  The old form was long and intimidating, while the admin side was clunky and annoying.  The underlying database is set up in a weird way, too, but I figured I would just have to work around that.  Turns out I probably would’ve been better off redoing the whole thing from scratch; as it is, I had to make several changes to the table structure, which means every place that displays events has to be changed to reflect that, which was exactly what I was trying to avoid by working with the existing database in the first place.  At least it’s ready to go now.  Well, I’ll still need to change some style elements and improve the client-side form validation, but that’s not hard compared to the rest.

Google+ at WOU!

Google finally decided we were a real, live university instead of (apparently) some sort of evil front organization bent on sneaking underage people into Google plus.  I’d pretty much given up on this so it caught me by surprise when I happened to check again today; looks like this has been turned on for a couple of weeks now.

So now when you’re in your WOU gmail, you should see a “Join Google+” item when you click your address in the Google menu bar, like this:

Click it to go to the Google Profile creation page.  Your name should already be filled in; just choose your gender and uncheck the “Tell other websites my personal information” checkbox, and you’re good to go!

OK, OK, that checkbox isn’t actually called that, but that’s what it amounts to as far as I can tell.

Stay tuned for more about Google+ at WOU!

X drive troubleshooting on Windows

For those of you who edit parts of the WOU website, here are a few steps to try if you run into errors like “Can’t connect to site” or “Local root folder is missing” or just “File not found” when you try to open up Contribute or Dreamweaver. If this happens, it generally comes when you’re first starting Dreamweaver, or first connecting to a site in Contribute.

Of course, the first thing to check is that the page or site actually works on the web. It’s pretty rare, but sometimes there may be a problem with the webserver itself or with the page file or folder. Most of the time, though, this happens because the X: drive on your computer (or the terminal server) isn’t connected properly.

Here’s what to try…

First, a bit of explanation. 

You can skip to “Troubleshooting instructions” below if you just want to know what to do, not why. 

Still here?  Great!  Web pages on our site are just files stored on our network, and in order to work with them, your computer needs a connection to the right network location.  For historical reasons, Windows uses single letters (followed by colons) to refer to network connections, just like it does for hard disks, DVD drives, USB sticks, and so forth that are physically connected to your machine.  To Windows, these are all just different locations that contain files.  Mostly, the particular letters don’t matter; they’re just labels for convenient access.  Here at WOU, we use X: for the website.  Every time you log in, if you have web editing permissions, your computer should automatically connect (or “map”) the X: label to the network location where the web files are kept.

If that connection isn’t made properly, or is lost for any reason, your computer can’t find the files.  As far as it can tell, they just don’t exist. Of course, they almost certainly still do exist, and the network location might even be available; it’s just that if that X: label isn’t mapped, Windows is helpless and can’t even take the first step towards finding the files you need.  (By the way, even though X: and the others are nothing more than labels, they’re usually still referred to as “drives” whether they are mapped to an actual hardware drive, or a network location, or anything else.  I’ll be using that terminology for the rest of this post.)

Troubleshooting instructions:

The first thing to check is that the X: drive is correctly mapped. Make sure you do this on the computer where you were getting the error, whether that’s your office machine, a terminal server, or whatever.  Open “My Computer” from the Start menu and look for a drive labeled “WOU Website (X:)”. If it is there, double-click it; that should open up a folder window with a lot of subfolders inside.

go into it and look for the “las” folder and make sure you can go into it as well. If that works, then the error has probably already corrected itself; if Dreamweaver still won’t work, even after quitting and restarting it, please let me know.

If the X: drive isn’t there, go to the Run command in the start menu and enter “\\\wou_website$” (note that those are backlashes, not normal slashes, and the dollar sign at the end is necessary.) This should open up a folder window in the same network location to which the X: drive should be connected. If it does, please make sure you can go into the “las” folderas well. If that works even if there is no X: drive, it means that the login process did not correctly connect the X: drive. If a logout and login doesn’t bring the X: drive back, or if the X: drive comes back but Dreamweaver still gives you an error, please contact me and include any error messages you saw during the process.

If entering the network location in the Run box doesn’t make a folder window show up, please email me the error message, and if there was no error, please describe the behavior instead. Currently, a few people have reported seeing a login box pop up when they try to connect, but that it won’t accept their login; that is a symptom of a specific network issue we have seen once last week and once this week. Normally this fixes itself in 10-15 minutes, but if you don’t want to wait, or if it is still demanding a login after that time, please call the UCS Service Request Desk at 88925 and explain what is happening. You should be routed to either Brian Berkley or Dave Diemer; one of them should be able to fix the problem. If you aren’t seeing this specific behavior, contact me instead, and only go to the service desk if I’m not available.

Hopefully this will help; if you have any questions, or see any problems not mentioned here, please let me know.

It's taken longer than I thought to find a secure way to automatically create new pages, so that lockdown will probably be in place for another week or so yet.

However, there is a workaround, at least for Dreamweaver users. If you use Contribute,
Go ahead and go through the process to create a new page, and even though you will get an error at the last step, the database record for the page will still be created, and you should see it in the list of pages for that site.  Move your mouse pointer to the Edit link for that page, and you should see the URL at the bottom bar of your browser.  If it isn't visible, go ahead and click on Edit and look at the URL of the edit form itself.  Note the page ID at the very end of the URL.

Next, go into the X: drive via your My Computer folder and navigate to where you want the new page to be created. Copy an existing page and rename it to the exact name you entered in Websmith when you created the page record there. Open the new copy in Dreamweaver and then switch to Code or Split view.

Here is the part that is a bit tricky. In the first two or three lines of code, you should see a line that looks like:

$PageID = 1234;

Instead of "1234" you will see the page ID of the page you copied. Change this to the new Page ID you noted above. You will also need to change the ID in two more places in the code; two or three lines below the PageID you just changed, and also just a few lines before the very end of the file, you should see a line that look something like this:

Again, you will see the old page ID instead of "1234". Where this line says "standard", the line you are seeing may have a different word, and where this line says "topinclude" the line near the end of the file will say "bottominclude". In both of those lines, change the page ID to the new one.

Note that even thoush these lines are technically HTML comments that would have no effect on anything, they are actually special, and Contribute users won't be able to edit the file unless they are correct.

Then you can save the file, switch back to Design mode (or whatever mode you normally work with), and edit the file to remove the content from the old page and put in whatever you need. From that point it should work just like any other WOU page.

If it doesn't work, or if this is too much trouble to be worth it, you can also just contact Danielle or I after you have gone through the Websmith step and let us know which exact page you in your Websmith listing is the one you need created. We should be able to get it done quickly.