Hey everyone! I haven’t made any posts in a while. The reason for this is because when I made website changes, stuff stopped working and I spent my time fixing. I’m not sure if this is the most technical post so far but I added GIFs so its OK. Our site is in my hands and I have butterfingers.
Yes I know all of the pretty colors have gone away and everything is set back to default. pretty much went from “Oh wow I get to learn CSS finally!” to deciding which problem to fix first.
Now, all of the problems I was having until now I am not 100% sure what they were all caused by. That being said, every time I filed a help desk ticket with OIT all they pretty much said was “We don’t really work with WordPress, only Drupal so when you have random problems like you always seem to, we can only suggest you disable your plugins and try to work from there.” Solid advice because all of the times I have done that, stuff started to work again. In fact, this is such a regular thing, I used to have to look up how to disable my plugins from the database (normal people with normal problems do this from the admin panel. Since the entire site or just the admin panel would not work, I could disable plugins via SFTP or from the database. The nice thing about the database is I can re-enable the plugins via the admin panel which is way more convenient than messing with remote files.) level but since I have done it so often, I can debug the tour program when they get back.
In the history of this site, outages have occurred because of plugins more than anything else. One might say “Well stop using those plugins!” and others might say “These plugins that routinely kill the site must be poorly developed!” which would be very fair observations. When I find out a plugin has killed the site one way or another, I mess with it a bunch, stop using it, or find a suitable replacement. So yes, I stop using plugins that cause problems.
What about the development of the plugins? To explain that, I first must briefly explain that wmich.edu as a domain is crazy restrictive. Its like asking a 1992 Taurus SHO owner how fast their car is, most will tell you a Taurus SHO is stupid fast. This isn’t the best analogy because having a fast car seems super awesome and having a domain that restricts as much as OIT does is not super awesome. In my opinion, developing for wmich.edu is like replacing one’s front lawn with bamboo so you have to use a machete to get your front door.
Is the way they do that bad necessarily? I don’t manage servers at a sysadmin level but I would imagine a website for a national University not only gets a lot of hits, but people probably try to hack in a bunch. The way I understand the websites on campus, all of the departments do their own development in house. If someone has an insecure site, it could compromise the entire domain in theory. Thanks to firewalls and restrictions, any site that could get hacked into wouldn’t be able to do that much. That being said, I have no idea how the hosting for my personal domains protects themselves since they don’t restrict me at all. At western, it will eat a lot of compute cycles, they’ll lose part of the system for a while, there is a finite amount of memory you can’t use it for everything, are you going to compile for half an hour..
So what does website security have anything to do with plugins? The most recent escapade with website failure fun was with a plugin called All in one calendar or otherwise known as time.ly which happens to be their URL. I personally do all of my testing on a domain that I own because wmich.edu domains cannot talk to other websites from a server level, they can only talk to the database and accept uploads from users like me. On the domain that I own, it can talk to other sites thus it will notify me of updates that will protect me from intrusions and provide those plugins to have updated features including bug fixes. The plugins that cause problems, I can only assume are trying to talk out to other sites too and start causing problems when stuff doesn’t work. Before the latest update, I think it was crashing the site about once a week where I had no notice or warning. When I updated to 2.0.5, it not only did not work, but it took down the entire site/admin panel with it. Everything works fine on my test site and when I put it live…
So all of my faithful readers, don’t grab your pitchforks and chase down the developers of time.ly because my problem is so unique to Western, no one else on their forums is having that issue. My solution as of four hours ago has been to use another calendar plugin that does pretty much every thing time.ly did and more. It was somewhat of a gamble because I wanted all of the information in the system before I started playing around with the display of everything but thankfully I was able to get it to display normally after I had inputted all of the information. I’m done for now but I’ve merely scratched the surface with what this plugin can do so stay tuned for some exciting calendar changes. I can see the headline now:
Calendar page on bronco band site…now in orange!
Anyway, I’m off to work on more fun projects and hopefully, the site doesn’t go down again before I finish messing with stuff.