1. Home
  2. Blog
  3. Free stock images for your web design projects

Blog

WordPress 4.9 is out! And it’s awesome!

by

WordPress 4.9 is out and features some seriously awesome new features.

Improved theme customiser

Draft and schedule design customisations

The theme customiser now allows you to create draft customisations and schedule their publish date.

This can be done using by clicking on the ‘cog’ icon in the theme customiser.

After creating a draft customisation you can share it with others using a special preview link.

This allows you to collect feedback and collaborate without having to publish to manage a staging site for theme customisations.

This can be found by clicking on the ‘cog’ icon in the theme customiser.

Design locks

The customizer now places locks to ensure two administrators don’t edit a theme at the same time.

WordPress 4.9’s design lock feature works similar to post locking secures your draft design so that no one can make changes to it or erase all your hard work.

Save changes prompt

WordPress will now protect you from loosing unsaved changes. It does this by prompting when you navigate away from the customiser and allowing you to continue unsaved changes.

Better safer code editing

Syntax highlighting

WordPress now provides syntax highlighting when editing CSS, HTML and PHP files.

This will help you visually scan your code and spot errors.

The HTML widget is also supported, but the post editor ‘text’ mode isn’t yet.

Error checking

A massive amount of work has gone into protecting you from bad code editing in theme and plugin files. Whilst it’s never recommended to edit code from the wp-admin – this should protect you from creating the white screen of death.

There are four layers to this protections:

  1. syntax highlighting – allowing you to visually identify errors
  2. inline error highlighting – prompting you of errors before they’re committed
  3. on screen prompts before committing changes with errors
  4. improved handling of white screen of death events – the previous method was unreliable and has been massively reworked to reliably disable the theme or plugin if it an edit creates a white screen of death.

Code edit warning

The first time you go to edit code you’ll get a warning letting you know the risks.

New and improved widgets

The new gallery widget lets you easily display images with a few clicks of the mouse – no code required.

Add media

The text widget now allows you to add media.

Shortcode support

The text widget now supports shortcodes – a very longstanding request that we finally have.

You no longer need to manually add shortcode support to your plugins and themes.

Better theme installation

Reliable theme switching

Often when you change themes widgets and menus can go haywire – moving position or disabling.

WordPress 4.9 includes improvements which will make this more reliable – allowing you to switch between themes without having to reconfigure your widgets and menus each time.

Theme browser improvements

The customiser now allows you to browse, filter and preview themes from the WordPress theme directory.

Improved menu creation

Making menus has never been that straight forward – with many people muddling their way through their first menu using lots of trial and error.

The process now includes tips to help guide you through create a menu.

 

Security

Last but not least there were improvements to notify and protect administrators of changes to account email addresses.

There were also a handful of security enhancements.

Are WordPress developers “real” developers?

by

When it comes to software development, WordPress developers get a bad rap.

Many won’t consider WordPress developers “real” developers – and there’s no wonder with “developer” being so overused in the WordPress ecosystem – resulting in no separation between those that can install plugins and themes and those that produce them.

But what does it mean to be a “real” developer and when does it apply to WordPress developers?

What is a developer?

In the software world, a developer is someone that can design, write, test and debug software.

A real developer will add value to a solution beyond installing and configuring – they can design and create solutions using code.

For websites, this can be in two parts –

  1. front-end developer – using code such as CSS, JavaScript, HTML that is ran on the client (browser) side
  2. back-end developer – using code such as PHP and MySQL that is ran on the server side

Some developers may focus on one part or both – but ultimately they use code.

A developer will understand (and hopefully use) coding standards, best practice and secure code.

What about those that don’t use code?

The WordPress ecosystem is broad – and just because someone doesn’t use code to work with WordPress doesn’t mean their work has any less value, but someone that does not code is not a “developer”.

Instead there are other terms that can more accurately describe their role such as:

Web designer

A web designer focuses on the look and feel of a website.

They will use their expertise in design principles, colour theory, usability to create the design of the website.

They may provide a PSD and/or specification of a design – and may work with a developer who will use code to create an installable WordPress theme.

WordPress implementer

A WordPress implementer will take the requirements for a website and use existing “off the shelf” software to create a website.

They assemble the website like pieces of a puzzle, may use some basic coding but ultimately rely on software created by developers.

Why does this matter?

When everyone calls themselves a developer it leaves a confusing sea of people with vastly different skills and little hope for clients to find the right person for the job.

It agitates the ecosystem – if clients end up with someone that isn’t capable of doing the work it makes the WordPress community and product look bad.

So how do you identify an actual WordPress developer?

Without any official  WordPress certification you need to rely on a portfolio of past and present work – for example websites, themes and plugins.

If they have work in the WordPress plugin and theme directories? Check the review and support threads – how do they respond?

If you can, make contact with previous clients and ask them about their experience with the developer – both in the implementation and ongoing support.

Do not delete Active Directory user accounts !

by

I’m always surprised to hear of Active Directory user accounts being deleted as part of normal account management.

I was taught to never delete user accounts and every Active Directory environment I’ve managed has been the same. Instead an account is set to “disabled”, removed from any email distribution lists and moved to a “graveyard” container.

I can understand the intent – when you’re done with it, delete it. But there’s a lot more going on than just a users ability to log on. 

Accounts are SIDs

When you think of a user account you most likely think of the account name – but the truth is an account is actually a SID (Security IDentifier) – this unique ID is what is used when referencing the user account.

This allows a user account name to change through its use, for example if the users legal name was changed without affecting effecting any existing permissions.

What happens when you delete an account?

By deleting the user account you’re removing the ability for Active Directory to display the account name – instead it will show the SID – which will look something like

{S-1-5-21-1004336348-1177238915-682003330-512}

Why Active Directory would need to display the account name?

Because Active Directory is an integrated environment – the account may have security permissions on a folder, a mailbox, scheduled tasks that run a program as well as audit logs for everything they did with the account.

What if you need to use the account again?

Just because the user has left doesn’t mean the account no long has a use.

I’m not suggesting that you recycle the account by giving it to another user, or allow their manager to use it – I’m talking about all the times you’re asked to create a new account based on a previous employees access, to check a mailbox, to set an out of office message. Or perhaps the user returns.

If the account wasn’t there to re-enable, those tasks become harder.

What about restoring the account?

Server 2012 introduced a “recycle bin” for deleted Active Directory objects. However it’s not enabled by default.

Even if you are lucky enough to be using Server 2012 AND have this enabled – the fact is it is MUCH easier to re-enable an account than restore from the recycling bin.

So what should I do?

There’s no official “best practice” advice from Microsoft for managing user accounts – but my advice is to never delete a user account.

When a user leaves and no longer needs an account your responsibility is to ensure the account cannot be used by the user whilst also being able to respond to any potential future requests like setting an out of office.

The most effective way to do this is to set the account to “disabled”.

WordPress Gutenberg – what happens when developers go wild

by

Since early 2017 WordPress developers have been working on a new content editor for WordPress – code name  “Gutenberg”.

The intent is to replace the current content editor, TinyMCE, but for the meanwhile Gutenberg is a plugin in it’s beta development phase.

Gutenberg is attempting to completely reinvent how editors interact with content – most significantly:

  1. separating the parts of content into “blocks” – for example, paragraphs, lists and images will all be separate blocks. A concept that has remained in desktop word processors, such as Microsoft Word, since their invention
  2. providing a minimalist interface which only provides buttons contextually when they can be used.

The good

I  can understand the desire to be innovative and provide improvements – in fact, I  applaud it.

The current editor, TinyMCE, was introduced to WordPress in version 2.0 in 26 December 2005.

Since then it’s seen several updates but has remained a traditional WYSIWYG content editor – one large block for all content, buttons at the top, ‘visual’ and ‘code’ mode etc.

During the same time other areas of WordPress have changed significantly – leaving the perception that the content editing experience also needs a revamp.

I’m not convinced that a revamp of this scale is necessary – specifically separating content into to blocks. 

But to be fair I do see one benefit – it will pave the way for developers to provide “block plugins”, much like WordPress widgets but for content. For example, you could create a button or an AdSense unit exactly where you want in the content with a few clicks of the mouse.

The bad

Change can be good – but it needs to be tested and refined based on feedback.

I’m concerned that Gutenberg went too far before user testing and now even after user testing is revealing its faults the ship has already sail.

Developers tend to have a “build to improve” mindset – an unwillingness, or inability to accept some features are not good and will focus on building on the feature when sometimes you just need to accept that some faults are not fixable, or at least not with code.

Just take a look at the Gutenberg reviews – at the time of writing there are 38 1 star reviews, compared to 15 5 star reviews.

Will the developers listen to this feedback?  Will they refocus on the usability and functionality shortfalls?  Or will they just focus on the technical implementation?

The ugly

The truth is – the Gutenberg plugin leaves a lot of room for improvement.

By removing all the traditional editor buttons and trying to make a minimalist design the usefulness and ease of use has been drastically reduced.

Extra clicks

Using Gutenberg I found myself to click, hover and look for the buttons – instead of them being visible and available immediately.

I accept that once you learn a new user interface you things get quicker – but even after learning how to change a heading to a list it still took 8 seconds in Gutenberg, compared to 2 seconds in TinyMCE.

 

Failing to recognise vastly different WordPress uses

I feel like it fails to recognise the vastly different ways WordPress is being used to manage the different types and formatting of content.

For example, I manage a how-to blog. Listed items (UL or UL) and pictures are fundamental to providing how-to-instructions. But with Gutenberg even this very basic requirement is not possible – to add an image you need to end the list, insert the image then start a new list – returning the list back to 1.

Clunky reformatting

In content creation I often reformat text, for example changing listed items to headings or switching an H2 to an H3 to create a better structure. Gutenberg did not handle this well at all. Turning a list to headings created some hideous heading block with <br>’s (not that I can check due to the lack of a “Source” option).

Learning curve

The platform may be web/browser – but the end users are used to desktop word processors and will be expecting a similar user experience when trying to use HTML WYSIWYG editors.

If the usability testing has said anything – it’s that there will be a lot of end user support and hand holding to train non-technical users in how to steer it. Not something I’m particularly keen to spend time on.

For example, select-all – this should select EVERYTHING in the document — not just the current content block.

No source view

For the more HTML literate users – the lack of a “Source” option to view and manually change the HTML will be significant. If you’ve ever needed to paste content in HTML format into a post, add custom formatting, edit/clean HTML – you’ll be at a complete loss with Gutenberg.

Third-party TinyMCE

Some people have argued that there will always be third-party plugins to re-introduce TinyMCE.

But I don’t think this is enough – the content editor needs to be a consistent user experience for ALL WordPress users and MUST have core support.

Conclusion

I acknowledge that Gutenberg is still in beta, and that the developers have put a lot of work into getting it to where it is now.

But I find it hard to see the Gutenberg editor providing an easier experience for any content management scenario I’ve dealt with.

I feel like they’re trying to solve a problem that just doesn’t exist, not at least for the majority of users. To me it seems like there are enough solutions like TinyMCE and CKEditor to not justify recreating an entirely new editor and new editor experience.

How to write a changelog and why it matters

by

If you thought changelogs were to document what has changed – you’re wrong.

That may be what you do in a changelog, but what’s often not seen is how they act as bridge between the software developer and users. 

It’s a shame because this is incredibly powerful – with this you can:

  • demonstrate good communication, attention to detail and professionalism to the users
  • show a continued development cycle – which builds confidence
  • refer users to related documentation

Instead they’re often underrated – and hence poorly done. I’ve seen some shocking examples – ranging from vague, over-detailed or even worse – just a link to a “diff” that shows what code has changed.

Here I’m going to share some tips on how to write a change log that matters to the user. More information on what makes a good change log can be found at Keep a Changelog.

Know your audience

As with any writing – the first step is to know your audience.

Are your users all technically minded, for example if you had a developer tool, or are they the type of user that is only capable of installing a WordPress plugin?

I usually consider my audience as:

  • my mother
  • a developer
  • myself

The key here is you need to write to the lowest level – so I always think “does this pass the mother test” — “will she understand what this means”.

Keep It Simple Stupid

Avoid using technical terms in the changelog and only talking in general terms.

For example

BAD: added async processing of ZIP file 
BETTER: improve time taken to create ZIP file

The level of detail to include will likely be contextual, for example – do you need to refer to where ZIP files are created? If so,

BETTER: improve time to send notification email with ZIP file

Write in terms of features

Most users are interested in the what – not the how. It can be hard to remember this when you spend so long thinking about how things work and making it happen.

For example

BAD: minify JS and CSS
BETTER: make page load quicker by reducing size of JavaSript and CSS

Avoid technical documentation

Don’t fall into the trap of including technical documentation in a changelog – for example providing examples on how actions or filters can be used.

Unlike a changelog, technical documentation is not set in stone – it’s a living breathing beast. What happens when that filter gets a new parameter – will you be retrospectively changing the past changelog entries? (I hope not!)

Instead simply provide a high level reference to the technical element, for example the name of a new or updated filter – and provide a link to the official documentation.

If this isn’t an option at least provide inline documentation in the code.

Break it down

If your changelog is for a complicated multi-part project, for example software that has a front-end and an API – use headings to break updates into their relevant part.

For example

Front-end

+ make page load quicker by reducing size of JavaSript and CSS

API

+ improve time to send notification email with ZIP file

Categorise

Before each item in the changelog, prefix with a category that describes the type of change in a single word.

For example

  • Feature – for new features
  • Improved – for general improvements
  • Maintenance – for tidying code
  • Changed – for changes in existing functionality
  • Deprecated – for soon-to-be removed features
  • Removed – for removed features
  • Fixed – for any bug fixes
  • Security – in case of vulnerabilities

Decide on how you want to do this early on and continue to use it as a “controlled vocabulary” – your users will rely on this being consistently used so they can scan through the list.

Don’t forget WHEN

For each update, include at the top the version number and the date the update was released.

This can help when jumping multiple versions or if a bug is discovered several months after the update is installed.

Include the full history

Don’t assume that the changelog is only being used for the latest updates.

By including the full history you allow the changelog to be used as a historical reference – for your users and the developer.

Anything else?

What else do you think makes a changelog matter for the user – comment below.

How I run a 10k hits a day WordPress website for $5 a month

by

For years I ran itsupportguides.com on a “business plan” cPanel host – it cost $25 dollars a month and while it ran OK most the the time, it was a shared service – which suffered performance issues or even outages when someone else on the server did something out of the ordinary.

That was before I found DigitalOcean – a cheap Virtual Private Server (VPS) host with prices from $5 a month – backed by solid infrastructure, awesome documentation and various one-click installs to get your website going as quick as possible.

At the time itsupportguides.com received around 10k visits a day – which left me thinking – could I run this one the cheapest $5 a month VPS?

The answer – YES! And even better – with DigitalOcean I can easily upgrade the plan if I ever need more, even temporarily – giving a quick easy scalability.

The VPS

At the moment the $5 a month plan gets you a VPS with:

  • 512 MB RAM
  • 1  core processor
  • 20 GB  SDD  HDD
  • 1  TB  of traffic

At first glance this is actually a significant step down from my cPanel hosting – but the key is your website is the only thing using these resources AND you can optimise the server for YOUR website.

Software and configuration

The biggest concern that stopped me from moving to a VPS was security and maintenance – I didn’t want to get bogged down by worrying about the server software or configuration and I definitely didn’t want to introduce any security issues.

Fortunately there was an answer for this as well – ServerPilot – who take away all the hard work of configuring the server and installing WordPress – leaving you with a highly optimised web host. If you don’t believe me, check out the amazing features they install.

The best part – once setup it’s completely hands off – they deal with the servers security updates.

The stack

  • A choice of PHP versions – 5.4, 5.5, 5.6, 7.0 or 7.1
  • Nginx in front of Apache
  • PHP-FPM – PHP’s official FastCGI process manager
  • MySQL
  • HTTP/2
  • Google PageSpeed Module

Server performance

itsupportguides.com gets about 10k visits a day with a peek of 800 visits an hour. 

Using the performance tools provided by DigitalOcean I can see the server is sitting quite comfortably handing the traffic – with only once in a month that memory usage was above my 70% alert threshold.

Page speed

My cPanel hosting would give somewhere between a 3 – 5 second page speed. Which isn’t bad, but I knew I could do better.

On the DigitalOcean $5 a month plan I a much better page speed – normally below 1.5 seconds.

A massive improvement at a fraction of the cost.

How do I do this?

I’ve written a detail set of instructions at The idiots guide to installing WordPress on DigitalOceans $5 a month plan.

10 things everyone must know about email

by

1. Email is insecure.

email-iconEven secure email programs only encrypt messages as they travel between the sender’s computer and the sender’s email server. Email transmitted from the sender’s email server to the recipient over the Internet passes unencrypted through any number of server, this happens regardless of any security configured by your or your email host – such as SSL or https.

The easiest way to understand this is by thinking of the email being transmitted through its various steps. At very best the sender and the recipient will be using SSL or https, leaving the following:

You (using SSL) -> SECURE -> Your Server -> UNSECURE -> Internet -> UNSECURE -> Recipient’s Server -> SECURE -> Recipient (using SSL)

Unless you are encrypting the actual message or attachments your email can be intercepted and read in transit.

2. You have no control over the email after you send it.

The people you send email to can forward it, post it online, or even post it on a billboard. As a rule, you should only put in writing what would pass the scrutiny of your peers or even a court of law.

3. The ‘From’ field is easily forged.

Both the ‘From’ name and email address are very easily forged.

Attackers can attempt to gain your trust by forging the ‘from’ field – misleading the recipient of the validity of the message.

4. Sending personal information over email puts you at risk for identity theft and other crimes.

NEVER send private information through email, whether you know the recipient or not. The private information could be intercepted by a third party, mishandled by the recipient or even be delivered straight into the hands of an identity thief.

If asked to send private information through email, even as an attachment politely decline and offer an alternative such as phone or fax.

Legitimate organizations are aware of email related risks and should not ask you to jeopardise the security of private information.

5. Identity thieves and other criminals use email, websites, and the names and logos of legitimate businesses to get you to give them sensitive information.

It’s easy to copy and paste logos into email, so don’t believe an email is legitimate just because they include logos of well known companies. Often, the link you see in the message does not take you where it appears to. For example, link text that says http://paypal.com may really lead to something like http://paypal.fakesite.zz/login.php and have a realistic imitation of the real site.

Emails that appears to be from a familiar and/or reputable businesses can be used to:

  1. Direct you to a website that is used to collect your account numbers and passwords
  2. Get you to reply to or attempt to unsubscribe from a service or newsletter so that they can send you more fraudulent email – replying or attempting to unsubscribe confirms for the sender that your email address is legitimate.
  3. Direct you to a website which infects your computer with malicious programs as the page is loaded. These programs can allow someone to use your computer to send spam, track key strokes to collect sensitive information, or set up repositories of inappropriate content.

7. Legitimate businesses have professional writers and editors that review emails for errors.

Typos are fairly common in email, but messages with several misspelled words, poor grammar or an unprofessional appearance are most likely not from an legitimate business and should be viewed with skepticism or simply deleted.

8. Email attachments can contain viruses and worms.

Avoid opening attachments that contain viruses by:

  1. Deleting messages and attachments from people you do not know.
  2. If you do know the sender but are concerned about the validity of the email and attachment, contact them and ask if they sent the attachment and where they got it.

For comprehensive advice on handling links and attachments see The jargon-free guide to computer and internet security.

9. Real millionaires will never offer you money via email.

If you receive an email offering to pay you to help them move millions of dollars out of a distant country, DELETE IT.

They want your bank account number and intend to use it to take your money.

10. Trust your instincts.

Most malicious emails just don’t “feel right” in some way.

If you find yourself wondering why you received a particular message, you should treat it with caution or simply delete it.