Wordpress Web Design Galway

Depreciation of your Server’s PHP version

If your site still runs on PHP 5, we have some bad news: your code is out-of-date and unsupported. If you don’t upgrade, you could get hacked, and believe us when we say that’s pretty hard to beat on the “sucks-ometer”. PHP 5 reached its End Of Life — that’s EOL if you’re an irredeemable nerd like us — on January 1st, 2019.

This means no more support and no more updates. You might wonder why that matters; if everything you have works, why upgrade to PHP 7? Because no more updates mean no more security updates. Any vulnerabilities discovered after a product’s EOL leave you wide open to all manner of bad actors. You’re an albino bunny in a dark wood during a rabbit season that never ends.

You might be okay. Probably not, though.

And of course, there’s another layer of complexity. Problems can arise when updating your version of PHP, as PHP 7 isn’t backwards compatible. If your theme and/or plugins have also not been updated recently, they can “break” or cause some weird errors on your website, if they use a PHP version 5 function that doesn’t exist in PHP version 7. This is what we call depreciation.

Why thigs changed if everything was fine?

This is a normal part of web development. This is a normal part of software development. This is a normal part of every aspect of information technology. I’ve discussed before how security is basically an arms race and that same principle applies here.

PHP supports their releases for 2 years starting at release plus 1 more to address these sorts of security issues as they arise. 3 years after its release, that version of PHP reaches its EOL.

Some people who don’t have perspective on the information technology world may be put off by the fact that PHP doesn’t support their own legacy products, but most tech companies stop security updates on heavily dated software at some point. Microsoft recently announced that Windows 7 will no longer receive security updates after January 14, 2020.
Coming from the other side of it, the uninitiated may also wonder why their developer didn’t put PHP 7 on their site when they first built it. The answer is that it might not have been out yet at the time of your site’s development. So basically if you are not yet updated to latest version 7 you are in risk of losing your website or compromising its database beyond recovery.

PHP 7 is also very fast, which can greatly reduce the loading time of your website. It will help you with your website speed optimisation processes.

If you have not done so already, it is time to do so now.  If you cannot, call us on 091 450 817 and we will do that free of charge for you if you move hosting to our high-tech provider.
Media PRO Web Design Galway – Make us your upgrading partner for the future.

WordPress Speed Optimisation

The Ultimate Guide to Boost WordPress Speed & Performance – WordPress Speed Optimisation

Do you want to speed up your WordPress site? Fast loading pages improve user experience, increase your page views, and help with your WordPress SEO. In this article, we will share the most useful WordPress speed optimization tips to boost WordPress performance and speed up your website.

Unlike other “X best WordPress caching plugin” lists or generic “X tips to speeding up WordPress” tutorials, this article is a comprehensive guide to WordPress performance optimization.

We tried to cover everything from why speed is important, what slows down your WordPress site, and actionable steps that you can take to improve your WordPress speed immediately.

To make it easy, we have created a table of contents to help you navigate through our ultimate guide to speeding up your WordPress site.

  1. Why Speed is Important for your WordPress Site?
  2. How to Check Your WordPress Website Speed?
  3. What Slows Down Your WordPress Website?
  4. Importance of Good WordPress Hosting


  • Why Speed is Important for Your WordPress Site?

Studies show that from 2000 to 2016, the average human attention span has dropped from 12 seconds to 7 seconds.

What does this mean for you as a website owner?

You have very little time to show users your content and convince them to stay on your website.

A slow website means users will potentially leave your website before it even loads.

According to a Strange – Loop case study that involved Amazon, Google, and other larger sites, a 1 second delay in page load time can lead to 7% loss in conversions, 11% fewer page views, and 16% decrease in customer satisfaction.

On top of that, Google and other search engines have already started penalizing slower websites by pushing them down in the search results which means lower traffic for slow websites.

To sum it all up, if you want more traffic, subscribers, and revenue from your website, then you must make your WordPress website FAST!

How to Check Your WordPress Website Speed?

Often beginners think that their website is OK just because it doesn’t feel slow on their computer. That’s a HUGE mistake.

Since you frequently visit your own website, modern browsers like Chrome store your website in the cache and automatically prefetch it as soon as you start typing an address. This makes your website load almost instantly.

However, a normal user who is visiting your website for the first time may not have the same experience.

In fact, users in different geographical locations will have a completely different experience.

This is why we recommend that you test your website speed using a tool like Is – It – WP’s WordPress Speed Test.

It is a free online tool that allows you to test your website’s speed.


After you run your website speed test, you might be wondering what’s a good website speed that I should aim for?

A good page load time is under 2 seconds. However, the faster you can make it, the better it is. A few milliseconds of improvements here and there can add up to shaving off half or even a full second from your load time.

What Slows Down Your WordPress Website?

Your speed test report will likely have multiple recommendations for improvement. However, most of that is technical jargon which is hard for beginners to understand.

Learning what slows down your website is the key to improving performance and making smarter long-term decisions.

The primary causes for a slow WordPress website are:

  • Web Hosting – When your web hosting server is not properly configured it can hurt your website speed.
  • WordPress Configuration – If your WordPress site is not serving cached pages, then it will overload your server thus causing your website to be slow or crash entirely.
  • Page Size – Mainly images that aren’t optimized for web.
  • Bad Plugins – If you’re using a poorly coded plugin, then it can significantly slow down your website.
  • External scripts – External scripts such as ads, font loaders, etc can also have a huge impact on your website performance.

Now that you know what slows down your WordPress website, let’s take a look at how to speed up your WordPress website.

Importance of Good WordPress Hosting

Your WordPress hosting service plays an important role in website performance. A good shared hosting provider like Irish – Hosting or our own Hosting Service take the extra measures to optimize your website for performance.

However, on shared hosting you share the server resources with many other customers. This means that if your neighboring site gets a lot of traffic, then it can impact the entire server performance which in turn will slow down your website.

On the other hand, using a managed WordPress hosting service give you the most optimised server configurations to run WordPress. Managed WordPress hosting companies also offer automatic backups, automatic WordPress updates, and more advanced security configurations to protect your website.


Speeding Up WordPress in Easy Steps (No Coding)

We know that making changes to your website configuration can be a terrifying thought for beginners, especially if you’re not a tech-geek.

But don’t worry, you’re not alone. We have helped thousands of WordPress users improve their WordPress performance.

We will show you how you can speed up your WordPress site with just a few clicks (no coding required).

If you can point-and-click, then you can do this!

Install a WordPress Caching Plugin


WordPress pages are “dynamic.” This means they’re built on the fly every time someone visits a post or page on your website.

To build your pages, WordPress has to run a process to find the required information, put it all together, and then display it to your user.

This process involves a lot of steps, and it can really slow down your website when you have multiple people visiting it at once.

That’s why we recommend every WordPress site use a caching plugin. Caching can make your WordPress site anywhere from 2x to 5x faster.

Here’s how it works.

Instead of going through the whole page generation process every time, your caching plugin makes a copy of the page after the first load, and then serves that cached version to every subsequent user.

page caching




web design galway

Digital Marketing Trends 2019

Digital marketing keeps growing. The way you did something last year is probably done differently this year. The latest technology, such as artificial intelligence is being used to personalize campaigns and automate marketing tasks. With technology and its role in digital marketing accelerating faster than ever, it is a no brainer to stay on top of the latest trends.

Influencer Marketing

Influencer marketing is the use of influencers to grow your brand’s awareness, primarily through social media channels. For years, influencer marketing was all about big followings and big names, but that’s changing. As consumers grow smarter on how influencers are used to promote products and services, companies are becoming more selective.

Companies are opting for influencers that are experts within their niche and their audience can trust and relate. These influencers have smaller followings, but audiences with higher engagement rates and are more affordable. It makes growing your online presence, strengthening your brand image and earning your audience’s trust simpler and more effective than ever before.

Social Media Stories

Social media channels such as Facebook, Snapchat and Instagram have a stories option where you can post images, videos and graphics that only last 24 hours. Although putting up posts that only last 24 hours doesn’t sound effective, it is important to do so as it is content that is considered more authentic and genuine. This makes it the perfect content to implement to your content strategy to boost visibility, engage audiences and build trust and authenticity.

Conversational Marketing

Have you conversed with chatbots powered by AI and machine learning yet? Conversational marketing is the practice of fostering one-on-one conversations with leads and customers. This is becoming a key trend in the digital marketing industry, as companies are focusing on providing personalized customer journeys. It also keeps consumers always connected to marketing, sales and customer service efforts.

Voice Search

There has been a significant increase in voice search queries. If you ask Google something via voice or search it usually retrieves a small snippet with a very accurate answer. So it shouldn’t be a surprise that companies are polishing up their content to be more conversational and focused on voice search optimization.

Video Marketing

Video is all over the place and if you haven’t hopped on this trend, it is better late than never. Platforms like Instagram have now made it super easy to create and share video, so there is no excuse to not leverage this channel.

web design galway

Enabling HTTPS on Your Servers


  • Create a 2048-bit RSA public/private key pair.
  • Generate a certificate signing request (CSR) that embeds your public key.
  • Share your CSR with your Certificate Authority (CA) to receive a final certificate or a certificate chain.
  • Install your final certificate in a non-web-accessible place such as /etc/ssl (Linux and Unix) or wherever IIS requires it (Windows).

Generating keys and certificate signing requests

This section uses the OpenSSL command-line program, which comes with most Linux, BSD, and Mac OS X systems, to generate private/public keys and a CSR.

Generate a public/private key pair

Let’s start by generating a 2,048-bit RSA key pair. A smaller key, such as 1,024 bits, is insufficiently resistant to brute-force guessing attacks. A larger key, such as 4,096 bits, is overkill. Over time, key sizes increase as computer processing gets cheaper. 2,048 is currently the sweet spot.

The command to generate the RSA key pair is:

openssl genrsa -out www.example.com.key 2048

This gives the following output:

Generating RSA private key, 2048 bit long modulus
e is 65537 (0x10001)

Generate a certificate signing request

In this step, you embed your public key and information about your organization and your website into a certificate signing request or CSR. The openssl command interactively asks you for the required metadata.

Running the following command:

openssl req -new -sha256 -key www.example.com.key -out www.example.com.csr

Outputs the following:

You are about to be asked to enter information that will be incorporated
into your certificate request

What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
Country Name (2 letter code) [AU]:CA
State or Province Name (full name) [Some-State]:California
Locality Name (for example, city) []:Mountain View
Organization Name (for example, company) [Internet Widgits Pty Ltd]:Example, Inc.
Organizational Unit Name (for example, section) []:Webmaster Help Center Example
Common Name (e.g. server FQDN or YOUR name) []:www.example.com
Email Address []:[email protected].com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

To ensure the validity of the CSR, run this command:

openssl req -text -in www.example.com.csr -noout

And the response should look like this:

Certificate Request:
        Version: 0 (0x0)
        Subject: C=CA, ST=California, L=Mountain View, O=Google, Inc.,
OU=Webmaster Help Center Example Team,
CN=www.example.com/emailAddress=[email protected].com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Exponent: 65537 (0x10001)
    Signature Algorithm: sha256WithRSAEncryption

Submit your CSR to a certificate authority

Different certificate authorities (CAs) require different methods for sending them your CSRs. Methods may include using a form on their website, sending the CSR by email, or something else. Some CAs (or their resellers) may even automate some or all of the process (including, in some cases, key pair and CSR generation).

Send the CA to your CSR, and follow their instructions to receive your final certificate or certificate chain.

Different CAs charge different amounts of money for the service of vouching for your public key.

There are also options for mapping your key to more than one DNS name, including several distinct names (e.g. all of example.com, www.example.com, example.net, and www.example.net) or “wildcard” names such as *.example.com.

For example, one CA currently offers these prices:

  • Standard: $16/year, valid for example.com and www.example.com.
  • Wildcard: $150/year, valid for example.com and *.example.com.

At these prices, wildcard certificates are economical when you have more than 9 subdomains; otherwise, you can just buy one or more single-name certificates. (If you have more than, say, five subdomains, you might find a wildcard certificate more convenient when you come to enable HTTPS on your servers.)

Copy the certificates to all your front-end servers in a non-web-accessible place such as /etc/ssl (Linux and Unix) or wherever IIS (Windows) requires them.

Enable HTTPS on your servers

Enabling HTTPS on your servers is a critical step in providing security for your web pages.

  • Use Mozilla’s Server Configuration tool to set up your server for HTTPS support.
  • Regularly test your site with the Qualys’ handy SSL Server Test and ensure you get at least an A or A+.

At this point, you must make a crucial operations decision. Choose one of the following:

  • Dedicate a distinct IP address to each hostname your web server serves content from.
  • Use name-based virtual hosting.

If you have been using distinct IP addresses for each hostname, you can easily support both HTTP and HTTPS for all clients.

However, most site operators use name-based virtual hosting to conserve IP addresses and because it’s more convenient in general. The problem with IE on Windows XP and Android earlier than 2.3 is that they do not understand Server Name Indication (SNI), which is crucial for HTTPS name-based virtual hosting.

Someday—hopefully soon—clients that don’t support SNI will be replaced with modern software. Monitor the user agent string in your request logs to know when enough of your user population has migrated to modern software. (You can decide what your threshold is; perhaps < 5%, or < 1%.)

If you don’t already have HTTPS service available on your servers, enable it now (without redirecting HTTP to HTTPS; see below). Configure your webserver to use the certificates you bought and installed. You might find Mozilla’s handy configuration generator useful.

If you have many hostnames/subdomains, they each need to use the right certificate.

Now, and throughout your site’s lifetime, check your HTTPS configuration with Qualys’ handy SSL Server Test. Your site should score an A or A+; treat anything that causes a lower grade as a bug. (Today’s A is tomorrow’s B, because attacks against algorithms and protocols are always improving!)

Make intrasite URLs relative

Now that you are serving your site on both HTTP and HTTPS, things need to work as smoothly as possible, regardless of protocol. An important factor is using relative URLs for intrasite links.

Make sure intrasite URLs and external URLs are agnostic to protocol; that is, make sure you use relative paths or leave out the protocol like //example.com/something.js.

A problem arises when you serve a page via HTTPS that includes HTTP resources, known as mixed content. Browsers warn users that the full strength of HTTPS has been lost. In fact, in the case of active mixed content (script, plug-ins, CSS, iframes), browsers often simply won’t load or execute the content at all, resulting in a broken page. And remember, it’s perfectly OK to include HTTPS resources in an HTTP page.

Additionally, when you link to other pages in your site, users could get downgraded from HTTPS to HTTP.

These problems happen when your pages include fully-qualified, intrasite URLs that use the http:// scheme.

Not recommended — We recommend you avoid using fully qualified intrasite URLs.

<h1>Welcome To Example.com</h1>
<script src="http://example.com/jquery.js"></script>
<link rel="stylesheet" href="http://assets.example.com/style.css"/>
<img src="http://img.example.com/logo.png"/>;
<p>A <a href="http://example.com/2014/12/24/">new post on cats!</a></p>

In other words, make intrasite URLs as relative as possible: either protocol-relative (lacking a protocol, starting with //example.com) or host-relative (starting with just the path, like /jquery.js).

Recommended — We recommend that you use relative intrasite URLs.

<h1>Welcome To Example.com</h1>
<script src="/jquery.js"></script>
<link href="/styles/style.css" rel="stylesheet"/>
<img src="/images/logo.png"/>;
<p>A <a href="/2014/12/24/">new post on cats!</a></p>

Recommended — Or, you can use protocol-relative intrasite URLs.

<h1>Welcome To Example.com</h1>
<script src="//example.com/jquery.js"></script>
<link href="//assets.example.com/style.css" rel="stylesheet"/>
<img src="//img.example.com/logo.png"/>;
<p>A <a href="//example.com/2014/12/24/">new post on cats!</a></p>

Recommended — We recommend that you use HTTPS URLs for intersite URLs (where possible).

<h1>Welcome To Example.com</h1>
<script src="/jquery.js"></script>
<link href="/styles/style.css" rel="stylesheet"/>
<img src="/images/logo.png"/>;
<p>A <a href="/2014/12/24/">new post on cats!</a></p>
<p>Check out this <a href="https://foo.com/">other cool site.</a></p>

Do this with a script, not by hand. If your site’s content is in a database, test your script on a development copy of your database. If your site’s content consists of simple files, test your script on a development copy of the files. Push the changes to production only after the changes pass QA, as normal. You can use Bram van Damme’s script or something similar to detect mixed content in your site.

When linking to other sites (as opposed to including resources from them), don’t change the protocol since you don’t have control over how those sites operate.

If your site depends on scripts, images, or other resources served from a third party, such as a CDN or jquery.com, you have two options:

  • Use protocol-relative URLs for these resources. If the third party does not serve HTTPS, ask them to. Most already do, including jquery.com.
  • Serve the resources from a server that you control, and which offers both HTTP and HTTPS. This is often a good idea anyway because then you have better control over your site’s appearance, performance, and security. In addition, you don’t have to trust a third party, which is always nice.

Redirect HTTP to HTTPS

You need to put a canonical link at the head of your page to tell search engines that HTTPS is the best way to get to your site.

Set <link rel="canonical" href="https://…"/> tags in your pages. This helps search engines determine the best way to get to your site.

Turn on Strict Transport Security and secure cookies

At this point, you are ready to “lock in” the use of HTTPS.

  • Use HTTP Strict Transport Security (HSTS) to avoid the cost of the 301 redirect.
  • Always set the Secure flag on cookies.

First, use Strict Transport Security to tell clients that they should always connect to your server via HTTPS, even when following an http:// reference. This defeats attacks such as SSL Stripping, and also avoids the round-trip cost of the 301 redirect that we enabled in Redirect HTTP to HTTPS.

Turn on HTTP Strict Transport Security (HSTS) by setting the Strict-Transport-Security header. OWASP’s HSTS page has links to instructions for various server software.

Most web servers offer a similar ability to add custom headers.

It is also important to make sure that clients never send cookies (such as for authentication or site preferences) over HTTP. For example, if a user’s authentication cookie were to be exposed in plain text, the security guarantee of their entire session would be destroyed—even if you have done everything else right!

Therefore, change your web application to always set the Secure flag on cookies that it sets. This OWASP page explains how to set the Secure flag in several application frameworks. Every application framework has a way to set the flag.

Most web servers offer a simple redirect feature. Use 301 (Moved Permanently) to indicate to search engines and browsers that the HTTPS version is canonical, and redirect your users to the HTTPS version of your site from HTTP.

Migration concerns

Many developers have legitimate concerns about migrating from HTTP to HTTPS. The Google Webmasters Team has some excellent guidance available.

Search ranking

Google uses HTTPS as a positive search quality indicator. Google also publishes a guide for how to transfer, move, or migrate your site while maintaining its search rank. Bing also publishes guidelines for webmasters.


When the content and application layers are well-tuned, the remaining TLS performance concerns are generally small, relative to the overall cost of the application. Additionally, you can reduce and amortize those costs. (For great advice on TLS optimization and generally, see High Performance Browser Networking by Ilya Grigorik.) See also Ivan Ristic’s OpenSSL Cookbook and Bulletproof SSL And TLS.

In some cases, TLS can improve performance, mostly as a result of making HTTP/2 possible. Chris Palmer gave a talk on HTTPS and HTTP/2 performance at Chrome Dev Summit 2014.

Referer headers

When users follow links from your HTTPS site to other HTTP sites, user agents don’t send the Referer header. If this is a problem, there are several ways to solve it:

  • The other sites should migrate to HTTPS. If referee sites can complete the Enable HTTPS on your servers section of this guide, you can change links in your site to theirs from http:// to https://, or you can use protocol-relative links.
  • To work around a variety of problems with Referer headers, use the new Referrer Policy standard.

Because search engines are migrating to HTTPS, in the future you are likely see more Referer headers when you migrate to HTTPS.

Ad revenue

Site operators that monetize their site by showing ads want to make sure that migrating to HTTPS does not reduce ad impressions. But due to mixed content security concerns, an HTTP <iframe> doesn’t work in an HTTPS page. There is a tricky collective action problem here: until advertisers publish over HTTPS, site operators cannot migrate to HTTPS without losing ad revenue; but until site operators migrate to HTTPS, advertisers have little motivation to publish HTTPS.

Advertisers should at least offer ad service via HTTPS (such as by completing the “Enable HTTPS on your servers” section on this page. Many already do. You should ask advertisers that do not serve HTTPS at all to at least start. You may wish to defer completing Make IntraSite URLs relative until enough advertisers interoperate properly.

web design galway

Why HTTPS Matters

You should always protect all of your websites with HTTPS, even if they don’t handle sensitive communications. Aside from providing critical security and data integrity for both your websites and your users’ personal information, HTTPS is a requirement for many new browser features, particularly those required for progressive web apps.


  • Intruders both malignant and benign exploit every unprotected resource between your websites and users.
  • Many intruders look at aggregate behaviours to identify your users.
  • HTTPS doesn’t just block misuse of your website. It’s also a requirement for many cutting-edge features and an enabling technology for app-like capabilities such as service workers.

HTTPS protects the integrity of your website

HTTPS helps prevent intruders from tampering with the communications between your websites and your users’ browsers. Intruders include intentionally malicious attackers, and legitimate but intrusive companies, such as ISPs or hotels that inject ads into pages.

Intruders exploit unprotected communications to trick your users into giving up sensitive information or installing malware, or to insert their own advertisements into your resources. For example, some third parties inject advertisements into websites that potentially break user experiences and create security vulnerabilities.

Intruders exploit every unprotected resource that travels between your websites and your users. Images, cookies, scripts, HTML … they’re all exploitable. Intrusions can occur at any point in the network, including a user’s machine, a Wi-Fi hotspot, or a compromised ISP, just to name a few.

HTTPS protects the privacy and security of your users

HTTPS prevents intruders from being able to passively listen to communications between your websites and your users.

One common misconception about HTTPS is that the only websites that need HTTPS are those that handle sensitive communications. Every unprotected HTTP request can potentially reveal information about the behaviours and identities of your users. Although a single visit to one of your unprotected websites may seem benign, some intruders look at the aggregate browsing activities of your users to make inferences about their behaviours and intentions and to de-anonymize their identities. For example, employees might inadvertently disclose sensitive health conditions to their employers just by reading unprotected medical articles.

HTTPS is the future of the web

Powerful, new web platform features, such as taking pictures or recording audio with getUserMedia(), enabling offline app experiences with service workers, or building progressive web apps, require explicit permission from the user before executing. Many older APIs are also being updated to require permission to execute, such as the geolocation

API. HTTPS is a key component to the permission workflows for both these new features and updated APIs.