Rookie mistakes

In another post where I try to explain the motivation behind WP Stress, I listed a series of events that led me to a CMS and, later, to organize training sessions for initiates. As most rookies, I found WordPress as I searched for a tool to answer a specific problem. I needed a simple, affordable and future-proof way of publishing content online, a way to make my business flourish.

As I was not a developer, and web design was not my core strength, I looked for something that I could manage myself, simple enough to understand the mechanics, and to make it work fast. I mean, back in the days, if you were not a web designer or developer, building a cool website could take you a lot of time and/or money. 

As you would expect, learning a new tool, even more when you are not a specialist, it’s hardly achieved without mistakes. Although I now laugh at these mistakes, I also realize that, probably if it were not for this learning from scratch, I would not have the same ability to understand initiates.

For starters, I used no child theme. Which means the changes I made to the theme would be catastrophically lost once I updated. Luckly, updates were not a thing back in the day… Well, not for this rookie.

Language files (.po/.mo) were also a mistery to me, yet to be unveiled. Which means that, before I realise we could actually create our own Portuguese .po/.mo files, I did a lot of translations in the php files. Truth be told, there weren’t that much themes and plugins prepared for internationalization either.

This process of editing php files, as absurd as it may seem right now, was actually my way into code, into understanding which files did what. No, I was not coding, it was more like a trial and error exercise. But made me think how things work in the backstage.

It also made me learn there were other ways to translate WordPress, themes and plugins. And that’s how I found the Portuguese WordPress Community.

Back then we had no GlotPress, so, there was no way to collaborate in an unified system. You couldn’t know if someone was doing the same job as you, translating a theme or a plugin. The first take was a conversation blog where we’d publish the themes and plugins we’d be translating or already translated (it was also common to email the files to the plugin or theme developers). WordPress language files would travel by email amongst a core team of translators and proofreaders.

A new WordPress version was always a stressful period (it still is, btw), but we (almost) always managed to launch the Portuguese localised WordPress version a few hours after the en_US release.

Backups and testing environments were also secondary, not by will but by ignorance.

WP Hive

Multisite before multisite

Before WordPress multisite was merged into WordPress core, there was WordPress MU, a multisite network specific version of WordPress. Only pros would use it, since it needed special configuration.

There were also some others interpretations of the multisite concept. One of those was wp-hive, a plugin that would let you create several sites with just one WordPress install and database. It would create separate folders for each site specific files, like uploads, themes and plugins. It was cool, not having to create another WordPress instance in the server, duplicated files, installs…

The wp-hive plugin was a very neat way to experiment with WordPress. It was so easy that I would create subdomains just for the fun of testing different themes, plugins, and ideas.

The hacked hive

All of this installs lived in a common shared hosting. By that time, my knowledge of server environments was almost none. I knew enough to create email accounts, subdomains and install WordPress. It was not a big surprise when I found out my hive had been hacked. Probably one of my tests with different themes and plugins opened a door for code injection.

Hacked hive

The WordPress ecosystem mas much more disperse, not everything was on, you would find unusual plugins in websites without a rigourous assessment of its credibility. Today is not that different, but there’re more respected places to gather information about WordPress stuff. And to be warned about the dangers of unknown sources.

I did a backup and most of my old sites in this wp-hive install were never live again. I had started working with another company and had no time to recover all the sites in a new environment.

Fortunately, those were not big traffic sites, the majority were isolated projects. But I still have a task to complete: revive my original site.

This issue showed me, the hard way, the importance of:

  • knowing your files sources
  • not using files from sources that don’t seem credible
  • if possible, always using plugins from
  • backing-up
  • using secure credentials
  • securing the local machine (look for virus and malware that can steal your site and FTP credentials)

Leave a Comment