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="https://www.google.com/calendar/embed?src=swartzer%40mail.wou.edu&ctz=America/Los_Angeles" 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="https://www.google.com/calendar/embed?src=swartzer%40mail.wou.edu&ctz=America/Los_Angeles" 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.

Update: IP address detection in PHP

We now actually have an even better workaround for the IP address problem I talked about last time.  Near the top of any PHP page,  include the following line:

require_once('wou_web_patch.inc.php');

After that, the normal IP address variable $_SERVER[‘REMOTE_ADDR’] will hold the actual IP instead of one of the four load-balancer addresses.  $_SERVER[‘HTTP_WOU_REAL_IP’] will continue to hold the real IP as well, but you should use the normal variable whenever possible.

By the way, the patch is already included in the WOU standard template, so if you are using those topinclude and bottominclude files, you only need to include the above code if you need the IP address before you call topinclude. Since it uses require_once(), there will be no conflict when the topinclude calls the patch again.

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 wou.edu, 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 swartzer@wou.edu.

 

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

 

WordPress automated upgrades

When we upgraded to WP 3.8 right around the new year, I noticed that it promised to automatically apply security updates.  Sure enough, we now have 3.8.1 without any of us having to lift a finger.  It’s always nice when something works like that.

If any of you still have WordPress sites on our server that are not part of the main install at wou.edu/wp, please be certain that they are upgraded to the latest version!  Un-maintained WP sites are a serious security hazard, and unfortunately we’re going to need to be a little tighter about separate WP installations.  If you have a site like this and want to move it to the central installation, we can help you with that; just contact me at swartzer@wou.edu.  Also, if you know of one of these separate WP sites that isn’t needed anymore, let me know and I’ll remove it for you safely.

And now, WordPress!

Due to a teeth-grindingly annoying legal issue, we suddenly can’t use any google apps outside the core package for anything WOU-related.  One of the ones we lost is Blogger, so now we’re using WordPress.

The migration wasn’t particularly hard, except for posts that contained images, i.e. not very many of mine.

I moved the blog last Tuesday, and by Sunday I already had four spam comments.  How did I know they were spam? Well, the standard “I liked this post which I will not talk about specifically” sort of wording is probably a giveaway to most people already, but here’s the real clincher: because I forgot to set a theme after importing, this blog was not visible at all in normal browsers. Pure white screen, until a few minutes ago.  So, the comments must’ve come either from a robot reading the source code directly, or one posting automatically to the comment submit link.  Spammers, gotta love ’em. If by the word “love” you actually mean “loathe”, that is.

Anyway, enough of that.  Gotta get more work done.

New phone, and vacation!

So I finally got my Galaxy S3 the other day.  I’d been holding out because as soon as I ordered it I’d lose my unlimited data plan; Verizon is evil, and my previous contract expired five days after the cutoff date they set for people to renew and keep unlimited data.  (mutter, grumble)

I like the phone so far; my only gripes are that its rounded corners make it easy to slip out of my hand, and that you can’t mount it as a USB drive for file transfer.  I’ll solve the first problem with a rubberized skin, but the second apparently has no solution unless I put an entire custom ROM on the phone, which I’m not ready to do just yet.  It does mount as either a camera or a media player, so you can transfer files, it’s just really, really slow.  And it has this nice “feature” where you can still access the storage from the phone even while it’s connected to the computer… just don’t do it with a file manager app or you risk borking your filesystem.  I lost a ton of stuff that way, and had to re-transfer it.  Moral of the story: don’t do anything with your phone while it’s connected to your PC.

Oh, and I’ve got the next two weeks off for vacation.  The first week is actually furlough, so I’m contractually obligated to not even think about work.  I figure it’ll take me that long just to unwind and decompress.  Then that second week will feel like an actual vacation.

See you on Monday the 29th…

Not to toot my own horn or anything…

Yeah, whenever anybody says that, they actually mean they *are* going to brag about something, I know.  I think I just did something kinda cool, though.  See, one of the departments has a few pages of their website on a third-party webhost, due to a long and complicated story that I’m not going to get into because this is already going to be a long explanation.

This hosting company is flexible enough that Danielle could make our template work over there, but there really wasn’t any way to include the departmental navigation files from our site.  They’d just have to edit both the local copy for their pages on our servers, and the hardcoded version on every page on the other web host.  Making it worse was the fact that the webhost only allows a certain number of edits before they start charging every time a file is changed (which still boggles my mind.)

Ordinarily we could just use curl() or the like to fetch the file from our server, but this company doesn’t use PHP.  They still run ColdFusion, of all things.  If ColdFusion has a way to fetch and include offsite files, I don’t know it. But I figured out a way to use jQuery and JSONP to have the pages on the other host talk to our webserver and get the sidebar include file they need.  They just need to source a JS script from our site, and it reads variables from the page to know which navigation files to include.  I could’ve hard-coded it for this one department, but I hate doing that when I can make a tool that can be used again.

But, security! I hear some of you saying.  You’re right that it’s a bad idea to let people fetch files off your site based on javascript code; anybody can mess with it using Firebug or some such, and change the variables.  That won’t work too well here, though; it’s locked down to specific folders and filename patterns (no slashes or .. for instance) plus there are a couple more secuirty features I’m not going to talk about.

If you want more detail, email me.  That’s all for now.

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!