DEV Community: Eco Web Hosting

Seven Easy Ways to Protect Your WordPress Site

Eco Web Hosting — Fri, 17 Apr 2020 13:26:11 +0000

WordPress is the most popular content management systems on the Internet. If you’re looking at any website, there’s a 35% chance that it’s built on WordPress.

And because it’s so popular, it’s also an easy target for hackers. If there’s a way to get in, you can be sure that it’s already been exploited.

So you need to make sure that your WordPress setup is as airtight as possible. Here are seven tips to help you keep your WordPress secure.

Update everything

Whenever there’s an update, update. Get into the habit, no matter how small the updates are. Update your plugins. Update your themes. Update the software. Keep everything updated.

These aren’t just vanity updates to make a developer feel better about themselves — most of the time they’re fixing security issues. Or they’re fixing bugs. You want a smooth-running WordPress installation? You update.

Check your passwords and change them if necessary

Are you using the same password across multiple sites? Or do you think you’re being clever and are changing the number at the end? You don’t even need to check HaveIBeenPwned — you know that password’s been cracked somewhere.

You need to make sure you have a unique password for your WordPress administrative account on your site. Luckily, WordPress makes it easy to generate one, but then it’s a matter of remembering it. Look into password safes like KeePass, 1Password, or LastPass and make sure you keep that safe and secure as well.

Review who has administrative privileges

Did you give a developer admin rights on your WordPress install to fix something? What about people who have left the company? Do you even have an account with an “Admin” login?

All of these are easy ways for people to get into your site. Go through your list of users and if there’s anyone on there who shouldn’t have rights to your site, set them to “No role for this site”. That means that even if they log in, they can’t do anything on the site, and, if you’re running a blog with individual authors, it’ll still keep them listed as the author of articles.

And if you’ve actually made an administrative account with the login of “admin”, please change it. You’ve pretty much just left your front door open there.

Make sure you’re using legitimate plugins and themes

Cracked versions of plugins and themes just lead to more problems, not just because you’re pirating software from an already fragile industry, but you’re also opening up your site to anything and everything. If you can’t afford that particular plugin or theme, look at the free alternatives — often, you’ll find something that works even better than the paid version.

And always make sure your plugins or themes are available on WordPress.org — if the company has vetted them, you can be sure they’re safer than the rest.

Set up two-factor authentication for your site

Two-factor authentication is where after you enter in your password, you then enter in another code provided by another system, whether it’s an authenticator app on your phone, a key fob, an email sent to your main account, or a fingerprint ID scanner.

Two-factor authentication makes it more difficult for people to get in using your account. If you want to make sure your WordPress site is secure, it’s a great way to add in an extra bit of security. There are several plugins you can use, as seen in WordPress.org’s Two Step Authentication article.

Take regular backups

No matter what you do, you still run the risk of being hacked. That’s where regular backups come in — an easy way to restore your site back to its original glory. Our Managed WordPress packages come with daily snapshot backups, or you can purchase snapshot backups for our Web Hosting packages separately. You can also manually back up and restore your site and database.

Keep aware of what’s happening

Keeping everything updated is a good start, but keeping informed of what’s happening in the WordPress world is also immensely helpful. Wordfence, a WordPress security plugin, has a detailed blog where they write up vulnerabilities and patches that they have found. WordPress.org’s article on Hardening WordPress is also a great read, getting into much more detail than I can in this post.

Update your site — no, really

Honestly, I can’t repeat this enough. So many of the hacked websites we see are because someone hasn’t updated their version of WordPress. Keep it updated, keep it safe.

And if you’ve updated to a recent version, there’s now a fantastic feature on the dashboard — Site Health Status. With that, you can check the status of your site, see what needs to be fixed, and help make your WordPress site even better.

I hope this helps you keep your site safe and running smoothly!

Written 15 April 2019 by Kate Bolin, our Marketing Director, originally on the Eco Web Hosting blog.
Cover image by Jason Briscoe on Unsplash.

Our Guide to Remote Working

Eco Web Hosting — Fri, 20 Mar 2020 09:38:13 +0000

With the ongoing pandemic, a lot more people are remote working. This is new for many of you, but it isn’t for us.

From the very beginning, we’ve been a remote-working company. And while we might have occasionally worked in coworking spaces or gone over to coworkers’ houses, self-quarantining isn’t that much of a change for us – we’re already working at home.

So, since we’re old hands at this, we thought you’d like to know some of the tricks we use to keep working.

Wake up at your normal time

If you’re used to waking up early for your commute, stick to that schedule. Sleeping in might seem to be one of the perks of working at home, but if it’s only temporary, you’ll end up regretting it when you have to go back to the office.

Plus, it gives you a chance to break up your day into Home Time and Work Time. Take a shower, change into new clothes, enjoy a nice breakfast, get into the office mindset, and you’ll be ready to go.

Set aside your own place to work

If you have a home office, that’s great – it’s a great way to separate out your work life and your home life, and you just need to make sure you’re at your desk at the start of the day. But if you don’t have the space for a home office, make sure you work in a different location than you normally sit when you’re lounging around. A different spot on the couch, the dining room table, whatever. This seat is for Serious Work, the other is for Fun.

Take breaks, and set alarms if you have to

You might get into the zone, being ultra-productive since you’re not getting interrupted by coworkers, but you still need to take breaks and you still need to stop at the end of the day. Set alarms if you have to – I personally really like Workrave, which makes sure you look away from your screen, stand up on a regular basis, and take breaks. And at the end of the day, close down your computer, and set it aside.

Don’t worry about getting sidetracked

It’s going to happen. It happens in the office too, and think about how much time that takes up. Do you fret about time spent at the coffee maker? That conversation you have with a coworker about who would win in a fight – astronauts versus cavemen?

A lot of the time, you’re spending more time worrying about getting sidetracked than you would spend actually being sidetracked. Spend that five minutes looking up the most haunted prison in the USA, go “Oh, that is interesting,” then move back on to your code.

Wear what you like, but wear something different

Working from home also seems to be the perfect opportunity to spend all day in your pyjamas, being ultra-comfy and never wearing trousers again.

But that just means it’s even more difficult to split between Work Time and Fun Time. So while you don’t have to put on the full office wear, putting on fresh clothes in the morning will make it clearer that you’re getting ready for work. I might be wearing leggings instead of jeans, but I’m still getting dressed.

Make sure you eat well

Just because you’re sitting at home and can eat nothing but chocolate biscuits doesn’t mean you should. Make sure you have good healthy food with plenty of variety so you don’t get bored. Make sure there are plenty of vegetables and fruit as well. I like to make ramen because it looks fancy, but it really easy to prepare.

Seriously, just put instant ramen, chicken pieces, a poached egg, and spring onion in a bowl. You spend more time waiting for the noodles to soften than you do preparing the rest.

And watch out for getting food delivered – you might think it’s a great way to enjoy treats, but those delivery costs will start to rack up.

Don’t get distracted by housework

During work hours, you are there to WORK. Getting distracted by how the carpet needs hoovering or those dishes in the sink or tidying up that coffee table will just eat up too much time that you’re supposed to be working.

That doesn’t mean you can’t do any chores – I regularly pop in a load of laundry while preparing breakfast, then hang it up to dry during my lunch break – but if you think that doing one thing is going to start you cleaning the entire house, take a breath, and let it go.

And don’t forget to have fun!

Listen to that cheesy pop on high volume. Sing along. Talk to yourself. Wear a wacky hat. Do push-ups against the wall. Dye your hair. Yeah, you’re working, but you’re also at home, and who’s going to stop you?

I hope these tips help, and that you’ll have a great and productive working-from-home life!

Written 18 March 2019 by Kate Bolin, our Marketing Director, originally on the Eco Web Hosting blog.
Cover image by Roberto Nickson on Unsplash.

Five WordPress Tools for Developers

Eco Web Hosting — Fri, 21 Feb 2020 16:01:49 +0000

WordPress is popular as a CMS, and not only are designers being asked to work with it, developers are as well. And while, as a content management system, WordPress does it seem like it would make it easier, the challenges of customising WordPress to meet a site’s needs can be difficult.

Here are five tools we’ve found that should be able to help you with your WordPress development, whether you’re building an entirely new site, working with an existing one, or just trying to add more features on your own site.

User Switching

When you’re building a plugin or a site, you might want different features for different users, and having to constantly repeat the process of logging out and logging in under a different user can take up a lot of time.

User Switching lets you instantly switch between user accounts, letting you check features and permissions for all your different user types.

WP Reset

Need to wipe everything and start again? WP Reset resets your site’s database to the default values, removing all customisations and content and leaving you with a mostly clean and empty site.

It has a built-in snapshot feature that saves your existing site before you delete everything. However, you’ll have to remember to create that snapshot because once you hit that button, it’s gone. And it won’t delete media files, site title, search engine visibility settings, or plugins. But when you’re looking at thousands of posts, it might be an easy way to clear everything out.

Activity Log

If you have several people working on your site remotely, manage a team of developers, or just have a tendency to forget what you did the night before, Activity Log is a great little plugin that gives you plenty of information about what’s happening on your site.

Whether it’s seeing who’s activated a plugin, double-checking when you changed that one setting, or making fun of that colleague who took 20 minutes remembering their password, Activity Log gives you the details you need when you’re working with WordPress.

Toolbelt

An all-in-one plugin that provides day-to-day functions you need on your site, packaged together with a focus on privacy and speed. Whether you want to lazy load images, add in a quick cookie banner that points to your privacy policy, or tweak your admin panel to make it a little more usable, Toolbelt has plenty of options available to make your life easier, and includes the impact on loading times as well.

It’s a fairly new plugin, so we’re hoping for even more features in the future. And we’re using it on our blog, so let us know what you think!

FakerPress

You need to populate your test sites with content, it’s a pain to keep doing it by hand, so why not use FakerPress to give you everything you need?

Get posts, images, users, tags, comments, and more, and then quickly and easily get rid of the content after you finish. It’s great for when you’re checking your blocks and making sure everything’s working just as it should be.

With these tools, I hope you’re able to make short work of some of the trickier problems WordPress developers face. Good luck, and have fun!

Written 4 December 2019 by Kate Bolin, our Marketing Director, originally on the Eco Web Hosting blog.
Cover image by Joshua Aragon on Unsplash.

How We Built Our Own Prerenderer (And Why) - Part 2: How

Eco Web Hosting — Wed, 12 Feb 2020 14:05:35 +0000

How hard could it be?

Though I generally always feel daunted when I look at other people’s code, after looking through the prerenderers I found on GitHub, the basic premise seemed fairly simple. Essentially, a local server instance would be started up, with the docroot of the site being set as such on that instance. Then, a browser client/DOM library would be loaded up, navigate to some provided routes and request them from the server instance. Finally, the markup from the responses to those requests would be saved to a file.

As the build process for Vue is a Node one, remaining within the Node environment seemed sensible. Node already has well-established server capabilities, further extended by Express. So that’s our server. Many of the existing prerender libraries used Puppeteer, an API library that allows communication with a(n optionally) headless Chromium browser instance. Puppeteer has methods that allow you to navigate to a page, wait for specific elements to load before continuing the execution, and save the generated HTML. So that was the client sorted.

And writing the generated HTML back to the file system could be done using Node’s existing fs library, which is file creation taken care of.

Basically, the prerenderer needed to pull together the functionality of three different sets of libraries – a server, a client and a filesystem lib. The rest would just be configuration.

Our implementation: A tale of three classes

For those of you familiar with the British indie music scene in 2006, let’s Skip to the End. For everyone else, let’s preview the result and then look through how we got there.

What was a hypothetical project became an actual thing that Eco Web Hosting now uses. Here are the lines that call it in our build script:

const SpaPrerenderer = require('spa-prerenderer');
const prerenderer = new SpaPrerenderer({
   staticDir: __dirname + '/../ewh-main-site/public_html/vue/dist',
   routes: [
       '/',
       '/vps',
       '/contact',
       '/web-hosting',
       '/status',
       '/domain-names',
       '/agreements',
       '/agreements/cookie-policy',
       '/agreements/fair-usage-policy',
       '/agreements/privacy-policy',
       '/agreements/security-and-data-processing',
       '/agreements/terms-and-conditions',
       '/agreements/third-party-processors',
       '/reseller-hosting',
       '/about',
       '/managed-wordpress'
   ],
   outputDir: __dirname + '/../ewh-main-site/public_html/vue/dist/',
   waitForElement: '#app',
   useHttps: true,
   supressOutput: false,
   reportPageErrors: true,
});
prerenderer.init();

There are three statements over 28 lines. Statement #1 includes the prerenderer for use.

Statement #2 instantiates it with a configuration that provides an input directory, the routes to prerender, an output directory, the ID of the element the prerenderer should wait for the generation of before saving markup, whether or not to use HTTPS on the local server instance the site is served to the renderer from, whether or not output should be suppressed and whether or not errors from the input pages are reported.

Statement #3 triggers the prerendering.

What each class does

Since the prerenderer was initially planned for use only by ourselves, we knew that it would be used in an up-to-date Node.js environment, meaning I could use nice, clean post-ES6 syntax. Of course, I could have used Babel with that to transpile down for compatibility with older versions, but it seemed like needless bulk when there are few circumstances this would be run in a pre-ES6 environment.

One post-ES6 syntax feature I used was the JavaScript class syntax, which provides a cleaner way of writing JavaScript’s prototype-based inheritance.

Here’s the difference that little bit of syntactic sugar can make to legibility:

I divided the project between three classes. Options (for validating prerenderer options), Server (the server) and Prerenderer (the client, containing the calls to Puppeteer).

Prerenderer would be the only class instantiated externally. Options and Server exist for Prerenderer to work with. The instance of Prerenderer would be constructed with the desired options, those options validated by a method of Options and an instance of Server started and stored as an instance variable.

Options just contains a static method to validate the object passed to it and throws an Error or TypeError in the event of an invalid value:

static validate({
   staticDir,
   routes,
   outputDir,
   waitForElement,
   useHttps,
   supressOutput,
   reportPageErrors,
 }) {
   if (staticDir === null) {
     throw new Error('staticDir must be explicitly set.');
   }
   if (!path.isAbsolute(staticDir)) {
     throw new Error('staticDir must be an absolute path.');
   }
   if (!Array.isArray(routes)) {
     throw new TypeError('routes must be an array.');
   }
   if (typeof useHttps !== 'boolean') {
     throw new TypeError('useHttps must be a boolean value.');
   }
   if (typeof supressOutput !== 'boolean') {
     throw new TypeError('supressOutput must be a boolean value.');
   }
   if (typeof reportPageErrors !== 'boolean') {
     throw new TypeError('reportPageErrors must be a boolean value.');
   }
   return true;
 }
}

Server would be constructed with two of the options passed in from Prerenderer — staticDir, which is essentially the document root for the site, and useHttps, which is a boolean flag that dictates whether an http or https server is started. Both are passed in the server options object:

 constructor(options) {
   this._options = options;
   this._expressServer = express();
   this._nativeServer = null;
 }

Server essentially wraps an Express instance and augments it with a method to dynamically create a self-signed SSL certificate for it if an https server is required. The server is then started using the init() method:

init() {
   const server = this._expressServer;

   server.use(express.static(this._options.staticDir, {
     dotfiles: 'allow',
   }));

   server.get('*', (req, res) => res.sendFile(
       path.join(this._options.staticDir, 'index.html')),
   );

   return new Promise((resolve) => {
     const tlsParts = this.generateSelfSignedCert();
     this._nativeServer = this._options.useHttps === true ?
       https.createServer(
           {
             key: tlsParts.key,
             cert: tlsParts.cert,
           },
           this._expressServer,
       ).listen(
           this._options.server.port,
           () => {
             resolve();
           },
       ) :
       this._nativeServer = server.listen(
           this._options.server.port,
           () => {
             resolve();
           },
       );
   });
 }

This is how the server is then instantiated and initialised by the prerenderer constructor:

constructor({
   staticDir = null,
   routes = ['/'],
   outputDir = '.',
   waitForElement = null,
   useHttps = true,
   supressOutput = false,
   reportPageErrors = false,
 } = {}) {
   Options.validate({
     staticDir,
     routes,
     outputDir,
     waitForElement,
     useHttps,
     supressOutput,
     reportPageErrors,
   });
   this.routes = routes;
   this.staticDir = staticDir;
   this.outputDir = outputDir;
   this.waitForElement = waitForElement;
   this.useHttps = useHttps;
   this.supressOutput = supressOutput;
   this.reportPageErrors = reportPageErrors;
   this.port = portfinder.getPort(3000);
   const serverOptions = {
     server: {port: this.port},
     useHttps: useHttps,
     staticDir: staticDir,
   };
   this.server = new Server(serverOptions);
   this.server.init();
 }

Once a Prerenderer object has been successfully constructed, it should have a running server as a Server object instance variable. Prerendering can then begin.

Once the prerenderer is constructed

I divided the prerenderer’s functionality into three further instance methods. These are all called from the asynchronous init() method:

async init() {
   await this.startBrowser();
   await Promise.all(this.routes.map(async (route) => {
     route = route.startsWith('/') ?
       route :
       `/${route}`;

     const targetBase = this.outputDir.endsWith('/') ?
       this.outputDir.slice(0, -1) :
       this.outputDir;

     const target = `${targetBase}${route}/index.html`;

     if (this.supressOutput === false) {
       console.info(chalk`{blue {bold Prerendering }${route}}`);
     }
     const content = await this.getMarkup(route);
     if (this.supressOutput === false) {
       console.info(
           chalk`{green {bold Prerendered} ${route}} {bold.blue Saving…}`,
       );
     }

     this.saveFile(content, target);
     if (this.supressOutput === false) {
       console.info(chalk`{green.inverse {bold Saved} to ${target}}`);
     }
   }));

   await this.browser.close();
   await this.server.destroy();

   return true;
 }

The method first calls startBrowser(), which starts a Puppeteer instance and assigns it to the instance variable browser.

Next, await Promise.all() is used to run an instance of getMarkup() for each route in parallel, and then calls saveFile() after the markup for each respective route has been retrieved. Only when each of those asynchronous fetch/save routines is successful (resolves) or fails (is rejected) will init() move onto the next statements, which close the Puppeteer instance followed by the server.

Here’s how the three methods that init() calls work in a little more detail.

Starting Puppeteer with `startBrowser()`

startBrowser() fires up an instance of Puppeteer. Since Puppeteer will be accessing only our local Express server (which may have a self-signed certificate), the --ignore-certificate-errors is included to prevent Puppeteer complaining that the certificate isn’t signed by a recognised CA:

async startBrowser() {
   try {
     this.browser = await puppeteer.launch({
       headless: true,
       ignoreHTTPSErrors: true,
       defaultViewport: null,
       args: [
         '--ignore-certificate-errors',
       ],
     });
   } catch (e) {
     throw e;
   }
 }

Getting the routes’ markup with `getMarkup()`

getMarkup() opens a new tab in the Puppeteer browser instance startBrowser() created for the route it is getting the markup for and then navigates to it.

If reportPageErrors() has been set to true, it outputs any errors from the source script if they exist. If the waitForElement option has been set, it waits up to 60 seconds for that HTML element to be generated.

Assuming no errors have been thrown, it then returns the markup:

async getMarkup(route) {
   const s = this.useHttps === true ? 's' : '';
   const url = `http${s}://localhost:${this.port}${route}`;
   const page = await this.browser.newPage();

   if (this.reportPageErrors === true) {
     page.on('pageerror', (err) => {
       const errorHint = this.waitForElement !== null ?
         chalk`This may prevent the element {bold ${this.waitForElement}}` +
         ` from rendering, causing a timeout.` :
         '';
       console.error(
           chalk`{bgRed.white {bold Error from the page being rendered:}}`,
       );
       console.error(chalk`{red ${err}}`);
       console.error(chalk`{red ${errorHint}}`);
     });
   }

   await page.goto(url, {timeout: 60000});
   if (this.waitForElement !== null) {
     await page.waitForSelector(this.waitForElement, {timeout: 60000});
   }
   return await page.content();
 }

Saving the routes’ markup using `saveFile()`

saveFile() takes content and saves it to a file path using Node’s fs library:

 saveFile(fileContent, filePath) {
   const pathComponents = filePath.split('/');
   pathComponents.pop();
   const dirPath = pathComponents.join('/');
   if (!fs.existsSync(dirPath)) {
     fs.mkdirSync(dirPath, {recursive: true});
   }
   if (fs.existsSync(filePath) && !fs.lstatSync(filePath).isFile()) {
     fs.unlinkSync(filePath);
   }
   fs.writeFileSync(filePath, fileContent);
 }

Wonderful. In the context of the init() method that calls it, the file path will be whatever the outputDir value is, suffixed with ‘index.html’.

But will it blend?

To make sure my initial enthusiasm hadn’t been pure folly, I thought perhaps it might be wise to write some tests.

I’m a great fan of code that reads like human being language, and for this reason, I used the Mocha test suite with the Chai assertion library, which allowed me to write tests like this:

   describe('prerender output', async () => {
     it('should save index.html to the correct path', async () => {
       await httpPrerenderer.init();
       fs.existsSync(`${outputDir}/index.html`)
           .should.be.true;
     });
     it('should match prerender input', () => {
       const output = fs.readFileSync(`${outputDir}/index.html`, 'utf8');
       output.should.contain(
           '<section id="dynamic"><h2>Dynamic bit</h2>',
           'Actual output does not match expected output',
       );
     });
   });

The results were promising (though the tests were a bit slow due to the inherent overhead of DOM rendering in a headless browser via Puppeteer):

Hot diggity dog. And the http:// URL in the prerendered source?

Gone. Success!

Open sourcing the results

Writing a new prerenderer for the purpose of banishing a mixed content error on our own site is all well and good, but it felt a little selfish to keep it to ourselves. For this reason, I’ve published it on Eco Web Hosting’s brand new GitHub profile and as an npm package for the world to use (and scrutinise).

This is my (and Eco Web Hosting’s) first foray into publishing open source packages so please, install, test, fork, adapt, report upon! Contributions and feedback are more than welcome.

Note:

Looking back, I could have submitted a pull request in the original prerenderer plugin to add the missing https toggle feature, though before embarking on this project, the source code made little sense to me. Ironically, it’s only having completed my own version that I now see my efforts might have been better directed at contributing to the original. Hindsight is, as they say, 20/20.

Written 12 February 2020 by Andy Dunn, our Senior Technical Lead, originally on the Eco Web Hosting blog.
Cover image by Fatos Bytyqi on Unsplash.

How We Built Our Own Prerenderer (And Why) - Part 1: Why

Eco Web Hosting — Wed, 12 Feb 2020 14:05:28 +0000

Context: We built a Vue site

Recently, we built ourselves a lovely new site using Vue.js. We wanted to be able to easily build reusable components and generally provide a speedier experience for users navigating the site.

As with almost any design decision, there were trade-offs. The main one was the kind we like to call “find-a-solution-that-seems-easy-on-StackOverflow-and-then-spend-a-week-trying-to-iron-out-the-bits-that-don’t-work”. Namely, the site needed a prerenderer in order to be read by some search engines.

When looking at the problem objectively, this was just a case of methodologically breaking any problems down and working through them, one-by-one.

But really, it was more a case of sinking into a minor existential crisis, questioning my career choices and deciding whether I should, in fact, pack it all in, buy a trawler and spend the rest of my days getting lashed by briny mist in the North Sea.

A cup of tea and a Hobnob later, I considered the possibility that I was being a little dramatic and got back to the drawing board.

What is prerendering?

Web terminology sometimes feels deliberately ambiguous. Is prerendering something that happens before rendering, or rendering that happens before something else? What is being rendered? Markup? DOM nodes?

When we talk about prerendering websites, we’re talking about generating the static page source that is served to the browser, which will build the Document Object Model (DOM), which is then painted to make the web page users see.

If your website has just a few static HTML files, where no content changes when served, there is no prerendering to do. The pages are already prepared for service.

So say you have an HTML file containing the following:

<!DOCTYPE html>
<html>
<head>
        <title>Prerenderer test</title>
</head>
<body>
        <h1>Prerenderer test</h1>
        <section id="static">
            <h2>Static bit</h2>
            <p>Nothing dynamic here…</p>
        </section>
</body>
</html>

A browser would render this HTML something like this:

Thrilling stuff.

Then say you then add some JavaScript to add some elements to the page, so your file now looks like this:

<!DOCTYPE html>
<html>
<head>
        <title>Prerenderer test</title>
</head>
<body>
        <h1>Prerenderer test</h1>
        <section id="static">
            <h2>Static bit</h2>
            <p>Nothing dynamic here…</p>
        </section>
        <script>
            window.onload = () => {
                const body = document.querySelector('body');
                const section = document.createElement('section');
                const h2 = document.createElement('h2');
                const p = document.createElement('p');
                section.setAttribute('id', 'dynamic');
                h2.innerHTML = 'Dynamic bit';
                p.innerHTML = `But here, everything is generated dynamically.`;
                body.append(section);
                section.append(h2);
                section.append(p);
            };
        </script>
</body>
</html>

Your page would render like this:

Ooo-ee. That’s the stuff I got into web development for.

This is a pretty basic example. Single Page Application frameworks, like Vue.js, React.js and Angular, take dynamic rendering and do something much more useful with it.

Vue.js apps are dynamically rendered

Our old website was a fairly traditional affair. You’d go to ecowebhosting.co.uk, a PHP page would be requested, assembled, and the fully-fledged markup would be returned.

Our new site doesn’t do that. Instead, it serves a small HTML file that acts as a mounting point for other DOM nodes.

It also contains JavaScript that has the entire remainder of the site served in that first request (save for static assets like images).

When you navigate around the new site, bits of that JavaScript are being executed, updating and re-rendering the markup of the page in the browser. This is why it feels fairly speedy. The browser doesn’t need to send new requests for pages each time the URL changes, as it already holds most of the site locally.

This means the source for each page looked the same. Something like this:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width,initial-scale=1.0">
    <meta name="theme-color" content="#577e5e">
    <link rel="manifest" href="/manifest.json" />
    <link rel="apple-touch-icon" href="/logo_192px.png">
    <link rel="icon" href="/favicon.ico">
  <link href="/0.js" rel="prefetch"><link href="/1.js" rel="prefetch">
  <link href="/10.js" rel="prefetch"><link href="/11.js" rel="prefetch">
  <link href="/12.js" rel="prefetch"><link href="/13.js" rel="prefetch">
  <link href="/14.js" rel="prefetch"><link href="/15.js" rel="prefetch">
  <link href="/16.js" rel="prefetch"><link href="/17.js" rel="prefetch">
  <link href="/18.js" rel="prefetch"><link href="/19.js" rel="prefetch">
  <link href="/2.js" rel="prefetch"><link href="/20.js" rel="prefetch">
  <link href="/21.js" rel="prefetch"><link href="/3.js" rel="prefetch">
  <link href="/4.js" rel="prefetch"><link href="/5.js" rel="prefetch">
  <link href="/6.js" rel="prefetch"><link href="/7.js" rel="prefetch">
  <link href="/8.js" rel="prefetch"><link href="/9.js" rel="prefetch">
  <link href="/app.js" rel="preload" as="script">
  </head>
  <body>
    <noscript>
    <strong>
        We're sorry but the Eco Web Hosting site doesn't work 
        properly without JavaScript enabled. Please enable it to continue.
        </strong>
    </noscript>
    <div id="app"></div>
    <!-- built files will be auto injected -->

    <!--JavaScript at end of body for optimized loading-->
    <script src="https://cdnjs.cloudflare.com/ajax/libs/materialize/1.0.0/js/materialize.min.js"></script>

    <script>
    document.addEventListener('DOMContentLoaded', function() {
        const sideNav = document.querySelector('.sidenav');
        M.Sidenav.init(sideNav, {});
    });
    </script>
  <script type="text/javascript" src="/app.js"></script></body>
</html>

Yet a browser’s Inspect tool would show the dynamically generated markup:

All’s well that ends well, right? The browser runs the JavaScript, the JavaScript constructs the view and the user is shown that view. What’s the problem? Well…

Most search engines don’t run JavaScript

Moz.com did some research in 2017 to see which search engines correctly index JavaScript, and found that just Google and Ask did. At the time of writing, this was the most recent evidence I could find. Bing does index synchronous JavaScript, but it does not wait for asynchronous JavaScript to finish loading.

It’s tempting to discount users of other search engines, ‘cause everyone uses Google now anyway, right? And what kind of maniac uses Bing, anyway? Unfathomable though it is, it seems that people do actually use other search engines. StatCounter reported that in the second half of last year, Google had 92.65% of the global search engine market share. 92.65% is a high number, but 100% it is not.

Since Ask would appear to be included in “Other” in this graph, I’m going to round down the “not Google or Ask” share to an estimated 7%.

That’s 7% of your potential customers who will never see your beautifully crafted new site, let alone convert into sales. So yeah. Looks like we can’t neglect other search engines. Not even Bing.

Two ways of indexing dynamic pages

What’s the answer then? There are two common solutions to this problem. Both involve rendering the site before it is served from the server. One is Server-Side Rendering (SSR) and the other is prerendering.

On server-side rendered sites, the HTML is rendered (you guessed it) on the server and sent back to the client. This general idea is much the same as a PHP site assembling the HTML to serve, only it’s the JavaScript that does it. But once the site has loaded to the browser once, further navigation changes are made client-side.

SSR, therefore, allows a speedier first load, with search engines reading the requested content as if it were a static page. Dynamic data is readied in advance, so the site retains the reusability and snappier user experience that SPAs have after the first load completes.

But it can be a bit of work to implement, and also be overkill if dynamic data doesn’t need to be prepared in advance for a particular route in a Single Page App.

Prerendering, on the other hand, generates a static HTML page for each route of an SPA when the app is initially built, rather than whenever that route is requested.

This is easier to implement than SSR, and the static page is ready to be served whenever the page is requested, but it does also mean that there’s no ability to dynamically prepare markup in advance within the same route.

Since we would only have varying content that didn’t need to be dynamically prepared in advance, prerendering was our answer.

Prerendering one’s woes away

To our collective delight, it seemed prerendering was a problem for which many solutions had already been provided. Not being fans of reinventing the wheel for the sake of it, we were happy to go along with what the Vue.js documentation recommended — the prerender-spa-plugin.

Integrating it was to be a fairly simple task, in theory. It could be installed via npm and then configured via our Vue.js app’s Webpack configuration file. We just had to provide the site’s docroot directory and an array of the routes to prerender.

We got the prerenderer working, and all was good until we noticed something we could not ignore.

Curse of the mixed content warning

There was a blight in the browser console, and it was a mixed content warning.

Yet the element in question loaded just fine.

And the inspector showed it loading over https, just like the rest of the site:

<iframe 
style="position: relative; height: 240px; width: 100%; border-style: none; display: block; overflow: hidden;" scrolling="no" 
title="Customer reviews powered by Trustpilot" 
src="https://widget.trustpilot.com/trustboxes/54ad5defc6454f065c28af8b/index.html?templateId=54ad5defc6454f065c28af8b&amp;businessunitId=582d86750000ff000597a398#v-6df015a4=&amp;vD20690f8=&amp;tags=ewh-gc&amp;locale=en-GB&amp;styleHeight=240px&amp;styleWidth=100%25&amp;theme=light&amp;stars=5" 
frameborder="0">
</iframe>

The source told another story though:

<iframe 
frameborder="0" scrolling="no" title="Customer reviews powered by Trustpilot" loading="auto" 
src="http://widget.trustpilot.com/trustboxes/54ad5defc6454f065c28af8b/index.html?templateId=54ad5defc6454f065c28af8b&amp;businessunitId=582d86750000ff000597a398#v-6df015a4=&amp;vD20690f8=&amp;tags=ewh-gc&amp;locale=en-GB&amp;styleHeight=240px&amp;styleWidth=100%25&amp;theme=light&amp;stars=5" 
style="position: relative; height: 240px; width: 100%; border-style: none; display: block; overflow: hidden;">
</iframe>

The prerendered markup’s source URL for the widget was http, but once all the scripts on the page executed, the DOM was ‘hydrated’ with the correct https:// source URL.

Besides looking unprofessional to any console adventurers, as Chrome’s Lighthouse pointed out to us, it could incur an SEO penalty.

It seems that TrustPilot’s Trustbox widget script itself created the iframe element with a source relative to the protocol the site was being served on and that the prerenderer served the site over https on a local server during the build process.

To fix it, we had a few options, though some felt rather hacky (post-build search and replace), while others relied on the addition of an https-served prerender that there didn’t seem to be much appetite for from others on the original project.

I began to get ideas.

Next: Andy gets into the details of how he built our own prerenderer, and the issues he faced...

Written 5 February 2020 by Andy Dunn, our Senior Technical Lead, originally on the Eco Web Hosting blog.
Cover image by Fatos Bytyqi on Unsplash.

Alt, title, and your images

Eco Web Hosting — Fri, 24 Jan 2020 16:42:23 +0000

Most people like having images on their website. It helps make the site more interesting and gives the users something nice to look at. And if you’re running an e-commerce site, your images can make or break your business.

And most people know that when you have an image, you need to include attributes for the image. There are enough articles out there that say that, as well as a wide range of accessibility and search engine optimisation checkers that point it out.

But I’ve been noticing something recently that keeps coming up – people will include a title attribute, but not an alt attribute. Or have both saying the same thing.

(Sometimes they’re called “alt tags” or “title tags” as well.)

So I did some reading, dug into the HTML standard, and here are my recommendations for image attributes.

What’s the alt attribute?

The alt attribute is text describing what the image is. If all your images suddenly disappear, the alt attribute can still tell your users what’s going on.

<img src="cat.jpg" alt="A small orange kitten walking through grass">

They’re absolutely vital for screen readers and users who cannot download images. Without an alt attribute, it’s like the image isn’t there. Or, worse, it’s just the file name.

What’s the title attribute?

The title attribute is also text describing what something is, but it’s much more all-encompassing. You can have titles on links, abbreviations, fields, whatever.

<img src="cat.jpg" alt="A small orange kitten walking through grass" title="Photo by AndriyKo Podilnyk on Unsplash">

<p>I used to write a lot of <abbr title="HyperText Markup Language">HTML</abbr>.</p>

It usually shows up as text when you hover over something, like so:

Why does this matter?

Titles are great to have. You can do a lot with titles and it gives a lot of further information that isn’t absolutely necessary to have in the main body of the text.

Alts, however, are vital. Not just for accessibility reasons, but for search engine optimisation as well.

Search engines read alt attributes, not title attributes. They count towards your keyword strategy, your content strategy, and your ranking overall.

What if the image is just decorative and doesn’t mean anything?

Decorative images are great for the look of your site, but if you put an alt attribute in all of them, you’d run of the risk of your site sounding like this:

Drawing of a cat Cat treats
Drawing of a sale sign Sale now on

You can use empty alt attributes to make the images essentially disappear.

<img src="cat-icon.svg" alt="">

How can I make sure I have alt attributes?

If you’re writing your pages yourself, you just need to remember. Every image has an alt attribute. It'll be hard work at first, but you'll get into the swing of things.

If you’re getting your pages from another source, you can run browser auditing tools – Firefox has the Accessibility Inspector, and Chrome has Lighthouse.

Run either against your site, and it will tell you which images are missing alt attributes. Then it’s just a matter of writing up descriptions of your images and making sure they’re put in.

How much detail do I need to go into?

It’s up to you and what the image is. For a lot of them, a simple explanation will do it.

<img src="kitten.jpg" alt="A kitten sitting on a sofa">

If you’re running an e-commerce site, you might want to put in a bit more information, such as brand and product details.

<img src="123456.jpg" alt="150g pack of Kitten Treats cat treats in Tuna flavour">

What you don’t want to do, however, is keyword stuff your alt attributes.

<img src="kitten.jpg" alt="persian cat kitten ragdoll tabby main coon feline kitty" />

Remember – this isn’t just for search engines, this is for screen readers as well. How does the text flow when you read aloud the alt attribute? Does it make sense?

I hope this helps and I hope your alts are all perfect!

Written 22 January 2020 by Kate Bolin, our Marketing Director, originally on the Eco Web Hosting blog.
Cover image by 贝莉儿 DANIST on Unsplash.

Four challenges of working from home, and how to overcome them

Eco Web Hosting — Fri, 17 Jan 2020 14:53:24 +0000

So, you’re a home-worker

When I began working at Eco Web Hosting in February 2015, my now Udemy-famous boss Rob offered the job as a work-from-home position, (with the condition that I relocate). Five days later, I found myself sat on an East Coast Main Line train on a pile of my bags, with my bike propped against my thigh as I swapped Nottingham for Cambridge.

Working remotely has plenty of perks. A Stanford University 2003 study by Nicholas Bloom and others found homeworkers were more productive than office workers (good for business), and their job satisfaction higher (good for employees). For Rob, too, he could spend more time with his family. For me, I could go and visit family and friends during the week, so long as they had a quiet space and an internet connection.

Remote work, however, is not without its challenges. The long-term benefits of home-working have been supported by studies such as Nicholas Bloom’s, whereas the rest of my advice has no basis more reliable than my own meandering experience (and some online research, which doesn’t allow me to plagiarise Baz Luhrmann’s turn of Mary Schmich’s phrase so readily).

I will dispense this advice now.

Know yourself: Are you an integrator or a segmentor?

Home-workers add work into an environment that is otherwise reserved for relaxing, resting and socialising. When I first started home-working, I would wake up late, knowing that there was some flexibility for me to make the time up later, and then work doubly as late into the evening to compensate.

Suffice to say this was not healthy, and my working days ended up spanning from 10:00 am – 11:00 pm, and sometimes beyond. I was exhausted, depressed, and after some time, unproductive.

I had bought into an idea that work and leisure would mingle effortlessly with one another purely by virtue of working at home, only to discover that I had allowed work to completely take over. The idea I had bought into is one that works for many, the integrators. I however am a segmentor.

Integrators like to manage the demands of work and home life by blending them together. They may need to do the shopping first, then write a marketing e-mail. They’ll make dinner, then write a bug-fix and answer some e-mails.

Segmentors on the other hand would rather compartmentalise work and leisure into distinct parts of the day. For them, leisure or other responsibilities during work time is disruptive, and work during leisure time is stressful and draining.

As my first year at Eco Web Hosting went on (also helped by the addition of new staff to ease the workload), I was able to develop better self-discipline during the day, and be more frank with Rob and the team about expectations outside of working hours.

The result? I became less-stressed out, and more productive. It’s not necessarily a silver-bullet, but knowing what to expect from your day lets you concentrate on making the best of it.

Lesson #1: Understand your working preferences and talk with your team to agree on boundaries.

Accommodate yourself: Find flow

Flow is that illusive state where you lose focus on everything but what you’re doing. Whether it’s running a marathon, watching a film or writing a WordPress theme, you’re completely immersed in it. The psychologist Mihaly Csikszentmihalyi has a fantastic TED talk in which he claims it is the secret to happiness. If nothing else, it feels like the key to fulfilling work.

When I first moved to Cambridge, I lived in a house share where a slightly eccentric landlady would appear at random hours with old sofas, bike wheels, a man who lived in the shed for two weeks, and on one occasion, four chickens, to live in the back garden.

My workspace was at a desk in my room at the front of the house. One morning, I was sat at my laptop, engrossed in writing a CRM to help us offer support, when I saw one of the chickens, freely clucking around the driveway. An escapee!

I spent 20 minutes chasing it around the front of the house (I am from suburban Wolverhampton, and have never had to chase a chicken before), as the Benny Hill theme in my mind’s ear soundtracked events.

Though I lost 20 minutes chasing the chicken, it took me a further 40 before I was as engrossed in my work as I was before. It was on this day, I decided my house was not a good working environment.

There is a romanticised image of the home-worker perpetrated cruelly by stock photo vendors, which is that they get to spend the day working in hip coffee shops on their MacBooks. After the chicken incident, I tried this. It turns out though, that coffee shops (especially in Cambridge) are expensive, have rubbish Wi-Fi, and are filled with noisy people.

Interruptions are costly. The 40 minutes I lost after completing the poultry pursuit and the frequent Wi-Fi outages of Nero, Costa and company resulted in me losing flow.

I later moved into a house with the same housemates, now friends, and no chickens. I also found a co-working space with coffee and other home-workers, eager to be social, but also to pursue flow. The co-working space has sadly now closed, but I now work from a dedicated spot at home, my housemate’s office, or my girlfriend’s house, and I haven’t looked back.

Lesson #2: Work somewhere you can find flow.

Organise yourself: Give ideas form

Working from home requires self-organisation. No one wants to be harangued by a busybody supervisor peering over your shoulder to check up on you, and at home, no such busybody supervisor exists (hopefully).

This places you in a position of trust. Most people I know want to do their best work off their own back, but the best of intentions can be derailed by poor planning.

By 2017, after a few more hires, and having learnt PHP, my role had become a developer role. My own organisational challenges at Eco Web Hosting generally came in the form of interruptions to my intended focus.

I would talk about a project, not note it anywhere but a skeletal to-do list on my laptop, and set out in earnest to complete it. My relative inexperience at that time meant that I would run into unexpected obstacles, and those would lead me down proverbial rabbit holes of PHP quirks, plus of course, as a junior developer, there would always be bugs to squash.

By the time I had got past an obstacle, I would find I’d lost sight of the initial idea, and my skeletal plan had morphed into something same, same, but different.

Poor planning can result in two things:

Context switching (changing between different tasks)
Scope creep (your task mutating into more than originally planned)

Context switching is costly. It takes time to find the illusive state of flow. Context switching interrupts that, eating up the time it takes to regain that flow again from your day. It’s also really annoying, feeling something akin to someone knocking down a house of cards you’ve built as you proudly place the last Jack of Clubs at the top.

Scope creep can occur when a project’s details are not planned clearly from the start, or if it is, but that plan is ignored. This can be a little more insidious and difficult to detect if there is no clear plan to start with.

Both context switching and scope creep are nightmares of anyone tasked with managing their own time effectively. Here’s how to mitigate it.

On a basic level, it can be as simple as making sure you have a workspace that it clear and ready for you at the start of each day (as per finding flow).

When dealing with ideas, which don’t have intrinsic form, giving them a (virtual) physical form is a good place to begin.

The most effective way I’ve found to deal with my organisational challenges is to type out plans, what they involve, and set target dates for each step using Trello (project management software with a generous free tier).

Other project management software, such as Asana, is of course available, or if you’re old school, good old pen and paper. I opt for Trello because it’s less wasteful on paper, and keeps the team up-to-date with what I’m up to as I go.

The important thing is to make things you implicitly think about a project explicit, because the human mind tends to subtly change things if left to its own devices.

Lesson #3: Use tools like Trello to organise your ideas, plans and projects.

It doesn’t have to be just yourself: Make time to talk

It’s now 2019, and having acquired a Tak, a Mike, a Chris, a Leon and a Ben, there are seven of us at Eco Web Hosting.

With all of us working remotely, as we developed more distinct roles, we’ve needed to find ways to coordinate ourselves.

We began chatting on Google Hangouts every day, and would have periodic face-to-face meet-ups. We later moved to the soon-to-be-defunct HipChat, and more recently, to the surprisingly versatile Discord (great for video calls, though their 2,000 character message limit is a pain).

From a practical perspective, having a means of constant communication was particularly convenient, as quick questions could unobtrusively be answered.

Face-to-face meetups allowed us to better and more effectively able to communicate bigger ideas about our respective budding sections of the company, and where we wanted it to go. Also, happily, I rather like my workmates, so it was good to hang out.

From a morale perspective, though, it feels good to have contact with other people during the day. Working remotely can be a lonely experience. Feeling isolated is no way to live, or to work, but Buffer’s State of Remote Work 2018 report found that isolation was the joint-biggest struggle in working remotely.

With loneliness being a behind a myriad of health problems, from depression to an increased predisposition to heart disease, maintaining quality interactions should be high on the list of priorities of remote workers and companies alike.

We now touch base every morning with a standup call. The call is a 30-minute catch-up where each of us has a turn to talk about what we did the previous day, what we’re up to the day ahead, and share our wit and wisdom with one another.

No one enjoys sprawling meetings that lack focus, so our standup is brief. This alone isn’t the same as spending the day in company, so I try to make sure I work around my girlfriend, friends or family at least a few days a week.

Mediated chat still misses the nuances of in-person interaction, so of course, we at Eco Web Hosting do occasionally find time for to get together in person too.

Co-working spaces are on the rise and rise, so do some research into your area to see what’s available.

Lesson #4: Quality human interaction is absolutely essential to live and work well.

Take-home lessons

The freedom that comes with working from home removes some of the restrictions of office-based work, freeing you to structure your day in a way that works for you. For me, that meant some trial and error to figure out what exactly that required.

There is a balance to each aspect.

Being able to work any time shouldn’t mean working all the time. Being able to work anywhere, doesn’t necessarily mean you should work anywhere. Freedom from micromanagement comes with a need to self-manage effectively. Finally, working remotely can be a little… well… remote, unless you add meaningful interactions into your day.

These are just my experiences. Working from home is as popular as it’s ever been, and is ever-more possible thanks to faster, more widespread broadband and 4G coverage.

Are you a remote worker? What are your experiences?

Author's Note

Written 31st January 2019 by Andy Dunn, our Senior Technical Lead, originally on the Eco Web Hosting Blog

Creating Automatic Emails That Work

Eco Web Hosting — Thu, 09 Jan 2020 15:50:22 +0000

We see them every single day – emails that are sent automatically when something happens. Placing an order. Resetting your password. Updating an expired card. You do something on a website, you get an email in response.

Those emails are a vital part of every online business, and you need to make sure they're getting the right message across. A well-written and designed automatic email ensures customer trust, can produce repeat visits, calms customer frustration, and cuts down on the amount of time your support team is stuck answering questions that should've really been included in the email.

When I first joined up with Eco Web Hosting, one of my first tasks was to go through the existing automatic emails and completely rewrite them. And I have a few tips to help you make your emails work.

Make sure the right information is being passed through

When a customer sets up a hosting package, they get an email that gives them all the details – the login, the control panel link, what to do if they want to transfer a domain, etc. And most of that is passed straight from the database into the email. I don’t get to see what the customer sees, I just see something like {{domainname}} or {{controlpanel}}.

So when you're editing the email, run a few test versions so you can see exactly what's being passed through. See if there are other fields that should be passed through and work with your development team to get those in. Ensure that the information has the right text around it that explains what they're looking at.

You might not have control over the data, but you do have control over how the data's presented, so make sure it's as clear as possible.

Always include a way to contact you

I always think that a good automatic email should cut down on the number of support tickets that are raised. It should have all the details a customer needs so they don't need to ask any questions.

However, just because it should doesn't mean it will. And that's why you always have a link for customers to get in touch with you.

It just doesn't cut down on the frustration, it also means you can funnel them into the right place for what they need. You don't want your social media team answering technical questions, your technical support team answering billing questions, or your sales team fending off competition winners. Ensure in each email, there's a way for the reader to get in touch with the right person.

Give clear instructions

This can be tricky because clarity is a subjective term. What you think makes perfect sense for you might not work for another person. And even if it does make perfect sense, it might end up being a mountain of text that your customers refuse to read.

Start by writing down everything that the customer needs to do – no matter how small. Use bullet points or ordered lists. Then review what you've written.

Are there any side tasks that could be taken out? Maybe link to an article instead of including it in the email? Could it be broken up with screenshots if it's really long? Or, if it turns out the action is really short (like "Click on the link below and then click 'Purchase'"), could you cut it down even further (like "Purchase On Our Site")?

Don't be afraid to check with your support teams as well, especially after a few weeks of the emails going out. They'll be able to tell you what's working and what isn't, and you can revise as needed.

Upsell only when appropriate

It's really tempting to add in discounts, special offers, and product mentions into emails. It feels like you have the perfect captive audience, people who are already purchasing things, who are interested in your company, who will obviously buy more products if you just put it in front of them.

But it only takes one sales pitch to turn a customer off. And if it's in an email that's inappropriate for upselling, you're going to lose a lot of customers really quickly.

Before you add in that product, think about what the email is saying. Think about when the customer would receive it. If they're in the middle of an argument in a support ticket, are they really going to want to be told about other products they can buy?

Upselling works best in two types of customer journeys – when they're being brought in and when they might be leaving. You see this in physical stores as well, with the special offers right when you enter and the fancier treats right by the checkout. Just make sure you're offering the right kind of products in the right locations, such as related items and different tiers.

Add tracking

This is vital. How else are you going to know exactly how well your emails are working?

Google has a lot of information on how to best set up UTMs, including a generator that'll build the link for you. But before you go throwing UTMs around left, right, and centre, have a deep think about how you want them to look.

How will you identify marketing emails? Service messages? Automatic emails? Are you going to indicate exactly where in the email the link is (head, body, footer)? What type of link it is (image, button, text)? How much detail do you want in the campaign name?

Work out exactly how you want your UTMs to look and keep that key on hand before you start populating your emails. Not only will it help you remember exactly what and where the link is from, but it'll also make it easier to pull data from Analytics.

For example, with Eco Web Hosting's emails, I have automatically generated emails (named g-), service emails (named s-), and promotional emails (named p-). Since I put those prefixes into utm_source, I can then go into Analytics's Source/Medium tab, set it to only include sources from that name, and I instantly have a report telling me exactly how many customers come in from a set of emails.

And don't just abandon them!

Combining the five tips above will give you better emails, but don't think you can just create the emails once and then abandon them. Work closely with your support team, your customers, and your data, and make plans for revisions on a regular basis. I'm already planning out the next set of emails I want to add in, and you better believe there’ll be some changes to the existing ones.

Good luck!

Author's Note

Written 16 October 2019 by Kate Bolin, our Marketing Director, originally on the Eco Web Hosting Blog.
Cover image Gemma Evans on Unsplash

DEV Community: Eco Web Hosting

Seven Easy Ways to Protect Your WordPress Site

Update everything

Check your passwords and change them if necessary

Review who has administrative privileges

Make sure you’re using legitimate plugins and themes

Set up two-factor authentication for your site

Take regular backups

Keep aware of what’s happening

Update your site — no, really

Our Guide to Remote Working

Wake up at your normal time

Set aside your own place to work

Take breaks, and set alarms if you have to

Don’t worry about getting sidetracked

Wear what you like, but wear something different

Make sure you eat well

Don’t get distracted by housework

And don’t forget to have fun!

Five WordPress Tools for Developers

User Switching

WP Reset

Activity Log

Toolbelt

FakerPress

How We Built Our Own Prerenderer (And Why) - Part 2: How

How hard could it be?

Our implementation: A tale of three classes

What each class does

Once the prerenderer is constructed

Starting Puppeteer with startBrowser()

Getting the routes’ markup with getMarkup()

Saving the routes’ markup using saveFile()

But will it blend?

Open sourcing the results

Note:

How We Built Our Own Prerenderer (And Why) - Part 1: Why

Context: We built a Vue site

What is prerendering?

Vue.js apps are dynamically rendered

Most search engines don’t run JavaScript

Two ways of indexing dynamic pages

Prerendering one’s woes away

Curse of the mixed content warning

Alt, title, and your images

What’s the alt attribute?

What’s the title attribute?

Why does this matter?

What if the image is just decorative and doesn’t mean anything?

How can I make sure I have alt attributes?

How much detail do I need to go into?

Four challenges of working from home, and how to overcome them

So, you’re a home-worker

Know yourself: Are you an integrator or a segmentor?

Accommodate yourself: Find flow

Organise yourself: Give ideas form

It doesn’t have to be just yourself: Make time to talk

Take-home lessons

Further reading

Author's Note

Creating Automatic Emails That Work

Make sure the right information is being passed through

Always include a way to contact you

Give clear instructions

Upsell only when appropriate

Add tracking

And don't just abandon them!

Author's Note

Starting Puppeteer with `startBrowser()`

Getting the routes’ markup with `getMarkup()`

Saving the routes’ markup using `saveFile()`