Foundation v5 Unrecognized Expression Syntax Namespace Fix

Recently whilst trying to use the Zurb Foundation Abide validation component I ran into an issue where I was getting a bizarre error involving form validation.

The error message might vary, but it’ll look similar to this: Error: Syntax error, unrecognized expression: [data-'Times New Roman'-abide]

The issue stems from the fact Foundation utilises an internal namespace. All you have to do is set the namespace to be blank and everything appears to start working:

                Foundation.global.namespace = '';
            $(document).foundation();
    

That one line above the jQuery.foundation() call will force the namespace to be blank and Foundation won’t try setting it. Problem solved.

How To Stop PHP Composer Timing Out When Using "composer update" or "composer install"

At work our internet connection is painfully slow for the moment while we sort something better out and I ran into a rather interesting quirk whilst using Composer and timeouts.

I was trying to install Laravel and because of the sheer number of components it got part of the way through and then would display some error message about exceeding the timeout limit of 300 seconds (5 minutes).

The reason for this appears to be due to the fact my Internet connection is mega slow and some components being largish in size. When calling composer update or composer install you just need to specify a higher timeout value.

This worked for me:

COMPOSERPROCESSTIMEOUT=4000 composer update

Obviously 4000 seconds will be enough time even for the slowest of Internet connections.

The Next Big Front-end CSS Framework: Zurb Foundation

Currently Bootstrap is still the preferred choice for prototyping web applications and rapidly getting a MVP out the door. As great and undeniably helpful it is, Bootstrap is far too opinionated to be a viable front-end CSS solution for a lot of people. It throws the kitchen sink at you and its default style.

There are numerous themes for Bootstrap and means of creating your own styles, but as someone who’s now worked with Bootstrap quite extensively, it feels like you’re constantly overriding base styles (even using Bootstrap Sass won’t help you).

The way Bootstrap handles styling elements is also annoying, it isn’t uncommon to find long style declarations in Bootstrap like this: .navbar-default .navbar-nav > .active > a (that’s an actual line of code from Bootstrap) what if I want to style up that element, I don’t mean change its colour, I mean change its size, shape and add other things to it? While Bootstrap is pretty configurable, if you’re not using the LESS or Sass version of Bootstrap which allows SOME configuration, you’ll be overriding long computed lines like this.

Opinions.

When it comes to Zurb Foundation, it is completely unopinionated. It gives you just enough basic style to not make your site look like it’s from 1999, but it doesn’t add in anything like gradients or really any style at all which leaves it begging to be styled. If you work with real designers, chances are they won’t be content just styling Bootstrap elements, they’ll want to style and control everything. Bootstrap is of course the complete opposite assuming the role of a communist dictator in your web application opposed to a supporting team member.

Sometimes you will want to control every aspect and sometimes you won’t. As a developer who has had the privilege of working with actual designers who aren’t merely reskinning Bootstrap, most use-cases I encounter would never fit Bootstrap.

Grids.

The grid system in Bootstrap is often lauded as being the holy grail of grid systems, that is until you use Foundation’s grid system. Don’t get me wrong, the Bootstrap grid system works really well and is insanely clever in how it works, but Foundation takes it to a whole new level.

Both grids take the approach of being mobile first, but Foundation offers a considerably better grid system which allows you to either use classes or semantic elements and apply grids via your stylesheets using the in-built Sass grid helper functions.

You can center your grid items, push and pull, and specify how an element should react on different screen sizes. In regards to how Bootstrap and Foundation grids work, the non-semantic markup approach is basically the same. You use rows and column elements which allow for unlimited grid nesting.

Another point-of-difference is the fact Foundation uses relative em’s (REMS) and Bootstrap uses pixel values for gutter padding.

I encourage you to read the Foundation grid docs as they go into considerably more detail about what the grid system is capable of and how to use it.

Components

Out-of-the-box Foundation offers a nice selection of components to use within your page each abiding by the mantra of not being opinionated thus making them easier to style, which means less important declarations and lower stress levels.

Everything you will most likely ever need is included; accordions, tabbed dropdowns, offcanvas navigation, sticky navigation, form validation (Abide), modals, alerts, tooltips, guide tour plugin (Joyride), carousel slider (Orbit Slider) and my favourite component for responsive content: Interchange.

Interchange Component: A game-changer

The Interchange plugin alone in my opinion is a game-changer. It allows you to specify different sources for image elements and content partials for different screen sizes using an expressive form of media queries on the elements themselves.

My favourite aspect of this component is the ability to pull in HTML partials for displaying different pieces of content inside of a DIV. I’ve found this to be helpful when it comes to embedding HTML5 video elements into a page especially, I can specify a static image for mobile/handheld devices and a video for larger screens I know can play videos.

You can read more about the Interchange component here, it seriously is an invaluable tool to have at your disposal for mobile-first responsive web development.

Conclusion

I have barely scratched the surface of what Foundation can do. The grid system and nice array of components is only the beginning, with more planned improvements and a growing community, one thing is certain: Foundation is slowly but surely in it for the long-haul.

Try it out for yourself and see if it fits your needs. If you’re a developer being supplied colour schemes from your designers, choose Bootstrap or if you’re a developer being handed designs that aren’t mere reskins, consider using Foundation for your next project.

Keeping A Node.js Application Running After Console Is Closed With Forever & Upstart

Newcomers to Node.js will have run into this issue a couple of times. You get your setup working, you’ve built a little application and on your server you start your Node app, but then you close the terminal window and your application stops.

When I first started using Node.js, this is the first thing I Googled, “How do I keep a Node.js app running after I close the terminal console?”

The approach we are going to be detailing here uses the Node package Forever and the Linux upstart package. By default Upstart should be shipped with most distros of Linux, but if it is not, you can install it using your Linux package manager (yum, apt-get).

Forever is essentially a simplistic module that will spin up your Node.js app and restart it if needed. When it says forever, it literally means forever (until you say stop anyway).

Installing Forever

Assuming that you’ve got Node.js installed, open up your terminal window and connect to your server. We now want to install Forever globally so type: npm install -g forever – that’s it for this step.

Writing an Upstart script

This is the bread and butter. This will allow us to treat our Node application like a system service. I use Ubuntu, so some things might differ in my instructions.

Upstart scripts will be living in this directory: /etc/init and our script will have a .conf extension. So for this example we will create a file called nodeapp.conf in our /etc/init directory

See below for our Upstart script, change the appropriate paths for Node and other things. Save the below script as /etc/init/myapp.conf or whatever name you choose.

Please also don’t forget to change all instances of nodeapp to your application name and tell the script the proper path to your main Node app Javascript file.

            #!upstart
        
        description "My cool Node.js process that will run FOREVER, ahahahahaha"
         
        start on filesystem and started networking
        stop on shutdown
         
        # You need this so Upstart reports the proper process ID of Node and not Forever.
        expect fork

        # Monitor Forever
        respawn
        respawn limit 5 30
         
        # Node paths (change to suit your installation)
        # The full path to the directory containing the node and forever binaries.
        env NODE_BIN_DIR="/usr/local/bin"

        # Set the NODE_PATH to the Node.js main node_modules directory
        env NODE_PATH="/usr/local/lib/node_modules"

        # The main file that starts our app (usually called server.js or app.js)
        env APPLICATION_PATH="/var/www/nodeapp.com/public_html/server.js"

        # Process ID file path
        env PIDFILE="/var/run/nodeapp.pid"

        # Log file path
        env LOG="/var/log/nodeapp.log"

        # Forever settings to prevent the application spinning up constantly if it fails on launch.
        env MIN_UPTIME="5000"
        env SPIN_SLEEP_TIME="2000"

        # Node specific environment variables
        env NODE_ENV=production
        env PORT=3001
         
        script
            # Add our Node stuff to the main path
            PATH=$NODE_BIN_DIR:$PATH

            # Prevent Forever from bringing down our server by repeatedly attempting to spin
            * up our Node app if it fails
            exec forever \
              --pidFile $PIDFILE \
              -a \
              -l $LOG \
              --minUptime $MIN_UPTIME \
              --spinSleepTime $SPIN_SLEEP_TIME \
              start $APPLICATION_PATH
        end script
         
        pre-stop script
            PATH=$NODE_BIN_DIR:$PATH
            exec forever stop $APPLICATION_PATH
        end script
    

Using Your Upstart Script

There are only a few commands to remember and if you’re familiar with starting and stopping services already, this won’t be unusual to you. Remember to replace nodeapp with the name of your script. So if you created a file called /etc/init/multiplayer-chess.conf you would replace nodeapp with multiplayer-chess and so on.

start nodeapp
stop nodeapp
restart nodeapp
status nodeapp

The above commands are pretty self-explanatory; start will start your app as a service, stop will stop it running, restart will restart it and status will tell you whether or not it is currently running or not.

How To Correctly Use Semantic HTML5 <article>, <main> and <section> Tags

Chances are you are living in the past or working on a project that was built in the past that is still marking up content using DIV tags instead of semantic tags like article and section.

Don’t get me wrong, there is nothing wrong with using DIV tags and there will always be a use for them, some pieces of content should be marked up using tags with semantic meaning. They’re not only cleaner, but also help bolster your chances of ranking better on the likes of Google.

Confusion: When do I use article or section tags?

For some developers the distinction between the article and section tags is confusing. Do you use both? Do you use one over the other? And if you use both, what order do they go in and are there limits?

To understand the difference and clear up any confusion, lets go right to the source over at the W3.

Section

The section element represents a generic section of a document or application. A section, in this context, is a thematic grouping of content. Each section should be identified, typically by including a heading (h1-h6 element) as a child of the section element.

Examples of sections would be chapters, the various tabbed pages in a tabbed dialog box, or the numbered sections of a thesis. A Web site’s home page could be split into sections for an introduction, news items, and contact information.

Authors are encouraged to use the article element instead of the section element when it would make sense to syndicate the contents of the element.

Article

The article element represents a complete, or self-contained, composition in a document, page, application, or site and that is, in principle, independently distributable or reusable, e.g. in syndication. This could be a forum post, a magazine or newspaper article, a blog entry, a user-submitted comment, an interactive widget or gadget, or any other independent item of content. Each article should be identified, typically by including a heading (h1-h6 element) as a child of the article element.

A general rule is that the article element is appropriate only if the element’s contents would be listed explicitly in the document’s outline.

When article elements are nested, the inner article elements represent articles that are in principle related to the contents of the outer article. For instance, a blog entry on a site that accepts user-submitted comments could represent the comments as article elements nested within the article element for the blog entry.

Author information associated with an article element (q.v. the address element) does not apply to nested article elements.

Chances are you’ve visited this page before and it still doesn’t make sense to you. Heck reading that again, it is confusing to me as well. In examples for both elements, they show two different use-cases, one use has the section element inside of article and the other one doesn’t use article at all.

From this we conclude that both can be used within one another. It all depends on the context of your page content which determines how the tags are used. For a blog of content you would have a section tag wrapping one or more article tags.

A section tag groups similar content together. So a page comprised of one or more blog posts is worthy of fitting multiple article elements within a section tag. You can then use section tags within the article element itself to contain content that is relevant but different within the article element. The below example will show comments for a blog post using this sub-section method.

I’ll show you an example below to clear up any confusion you might still have.

What the heck is the <main> tag?

The <main> tag is actually a new addition to the HTML5 specification. It has been around for a year and a bit, it is pretty well supported and of course supported via html5shiv for older browsers.

This tag is essentially a wrapper tag that goes around your content. If you’ve ever used a <div id=”main”></div> or <div id=”wrapper”></div> around your content before, the <main> tag essentially replaces it.

The ideal structure

Now we’ve touched upon the tags, lets structure a fictional WordPress blog post. This would be the equivelent of viewing a single blog post (for this example). Parts of this example were taken from the above W3 link with a few additions like the tag added in.

			<main id="wrapper" role="main">

			<section id="content">

				<article id="post-123" itemscope itemtype="http://schema.org/BlogPosting">
					<header>
						<h1 itemprop="headline">Blog Post Title</h1>
						<p><time itemprop="datePublished" datetime="2009-10-09">3 days ago</time></p>
					</header>
					<p>This is some blog post content. Within an article element.</p>

					<footer role="contentinfo"><p>Post written by Dwayne and posted in category: Potatoes.</p></footer>

					<section id="comments">

						<article itemprop="comment" itemscope itemtype="http://schema.org/UserComments">
							<p>This is my all important comment, please don't delete it.</p>

							<footer>
								<p>Posted by: George Washington</p>
								<p><time itemprop="commentTime" datetime="2009-10-10">15 minutes ago</time></p>
							</footer>
						</article>

					</section>

				</article>

			</section>

			<aside id="sidebar" role="complementary">

				

			</aside>

		</main>
	

What Is The Opposite of event.preventDefault() In jQuery?

This is the one aspect of jQuery and well, Javascript in general I see newcomers to Javascript and jQuery get caught up on. Heck, I’ve seen veterans get caught up on how to properly cancel and allow events as well as event bubbling.

Nothing.

There is no opposite method of “event.preventDefault()” to understand why you first have to look into what event.preventDefault() does when you call it.

Underneath the hood the functionality for preventDefault is essentially calling a return false which halts any further execution. If you’re familiar with the old ways of Javascript, it was once in fashion to use return false for cancelling events on things like form submits and buttons using return true (before jQuery was even around).

So, what is the opposite of event.preventDefault()?

As you probably might have already worked out based on the simple explanation above: the opposite of event.preventDefault() is nothing. You just don’t prevent the event, by default the browser will allow the event if you are not preventing it.

See below for an explanation:

        ;(function($, window, document, undefined)) {

        $(function() {
            // By default deny the submit
            var allowSubmit = false;

            $("#someform").on("submit", function(event) {

                if (!allowSubmit) {
                    event.preventDefault();

                    // Your code logic in here (maybe form validation or something)
                    // Then you set allowSubmit to true so this code is bypassed

                    allowSubmit = true;
                }

            });
        });

    })(jQuery, window, document);
    

In the code above you will notice we are checking if allowSubmit is false. This means we will prevent our form from submitting using event.preventDefault and then we will do some validation logic and if we are happy, set allowSubmit to true.

This is really the only effective method of doing the opposite of event.preventDefault() – you can also try removing events as well which essentially would achieve the same thing.

Perspectives

Everyone wants to build the next Facebook, the next Google, the next Instagram and the next big thing. The harsh reality is that only a handful of people every so often actually make it. For every Mark Zuckerberg there are probably tens of thousands of entrepreneurs toiling away in cafes, the early hours of the morning and weekends who end up not “making it” presumably because only a very small percentage of entrepreneurs actually do.

Bubbles

Sometimes people get caught up in their own bubbles they often forget about the things that matter around them. I am pretty guilty of this, I have so many ideas bubbling away in my head, I’m never not working on something. It can be easy to forget when you’re “in the zone” that you have a girlfriend/boyfriend/husband/wife and perhaps even a child or two who might want your attention as well.

Entrepreneurs are a weird bunch of people. They work their nine to five jobs, come home and work on their side-projects hoping that one day all of this free time being consumed will have been worth it. It is good to have dreams, but you need to be mindful of those around you. What is the point of having a dream if you’ve got nobody to share it with?

This comic pretty much sums up everything I am trying to say:

Bq8H8oiCMAEXiY0

Understanding

Having side-projects is a healthy thing for any developer or would-be entrepreneur to have, but you have to prioritise your life a little better. As you get older and responsibilities like family, a mortgage and a partner inevitably for most come to fruition you need to shift your mindset.

You might understand why it is you are trying to build the next big thing, but your wife, your friends and your children might not understand. In your head you know you’re trying to break-through to make life better for your family, dreams of being acquired for a few million dollars, outside of the bubble all those looking in see is you spending too much time on the computer.

Reality

Your idea most likely won’t go anywhere. There are potentially hundreds, if not, thousands of other people just like you working on the exact same idea. Your idea is not unique, the amount of hours you put into your idea doesn’t necessarily equate to more success.

If you have ever watched Shark Tank or similar shows like Dragon’s Den, then you will have seen first-hand just how out-of-touch some entrepreneurs actually are with reality. Everyone thinks their idea is great partly because they’re blinded and partly because they’re inexperienced.

Time

We only have such a small amount of time in this life before we depart. You could die tomorrow. Do you want to die being remembered as someone who was always there for their family or do you want to be remembered as “always being on his computer” – when we’re gone, the only way we live on is through memories of those who were fortunate to be around us.

I came to the realisation a little while ago that entrepreneurism is an addiction in large doses. It can be easy to get addicted to wanting to build the next “big thing”, sometimes persistence does pay, but sometimes it can be damaging if you’re not aware of how much time you are spending on the computer and not with those who need your time more.

Spend time with your partner, take your children to the park, go out for a drink with some friends and use your time wisely.

Mastering Your Sass Like A Buddhist Monk

If you’re like a lot of developers out there, you start your projects off with the best of intentions. No developer ever says, “I am going to make this project a fucking mess, a cluster-fuck of spaghetti code that even I’ll struggle to read in 2 weeks, let alone any other developer

We’re living in the golden-age of front-end development. We have tools, we have awesome methodologies like BEM and CSS pre-processors like Sass. And for all that automation without a proper structure, our CSS always ends up being unorganised and messy.

I’ve done seen a lot of roaches and bitches, but the dog keep going the distance

— Snoop Dogg

Use The Structure, Luke

There are a lot of different ideas out there for structuring your Sass. Each has its own advantage and disadvantage, one thing is for certain though: folders are awesome and you should use them.

It can be hard breaking out of that old-css mindset when using Sass. You often see developers throwing a whole bunch of their Sass files into the one folder, maybe one sub-folder if you’re lucky.

My Structure

This is the money shot. This is the structure that I use on all projects I touch and it works well. It’s modular so it prevents conflicts, it means many developers can work on different aspects and not cause conflicts when committing your files (conflicts are annoying).

Stylesheets/
    homepage.scss # Imports the _homepage.scss file from pages/ (if you want separate stylesheets for different pages)

    style.scss # The primary global stylesheet you include everywhere on your site

    -- base/
        _functions.scss # Custom user mixins/functions

        _variables.scss # Variable values

        _base.scss # This includes the files above in one handy file, also could include Compass or Bourbon here. All standalone files should import this base file for access to variables/functions, etc.

    -- components/
        _buttons.scss # Button styles

        _classes.scss # Generic CSS classes

        _forms.scss # Form styles

        _grids.scss # Grid system

        _responsive.scss # Our media queries file

        _tables.scss # Table styles

        _typography.scss # Type styles

        _components.scss # This file includes all of the components via imports (except the _responsive file, this is included separately)

    -- pages/
        _global.scss # Global page styles

        _homepage.scss # Homepage styles

        _contact.scss # Contact page styles

    -- vendor/
        _bootstrap.scss

        _jquery.ui.scss

        _vendor.scss # This includes all previous vendor files, so we don't have to include one by one

Take me to your style.scss

Inside of your main stylesheet which we called style.scss, it will look something like below. The goal with the main style.scss stylesheet is that it will become a global styles file of sorts. You include this and it gets loaded on each page.

            // Import Compass
        @import "compass";

        // Base styles
        @import "base/base";

        // Import our components file minus the responsive include
        @import "components/components";

        // Vendor styles
        @import "vendor/vendor";

        // If you were to include page styling for all pages include it here in the middle
        // Keep in mind this is a global file and to prevent bloat, you should break CSS
        // files where possible into separate includes to prevent pages loading unneeded CSS

        // Include our media queries file at the bottom
        @import "components/responsive";
    

Huh?

What the above does is it generates a definitive global stylesheet called style.scss — it gets included on every page and features base styles. For specific pages like the homepage, we incur an additional request (if browser cache isn’t primed) but only include CSS on pages that need it.

I have a separate stylesheet for each page if there are going to be lots of changes and additions only relative to that page. If not, then you put your global page styles into the _global.scss file in the pages folder. Simple.

For each additional separate page stylesheet we need to make sure we include the base/_base.scss by adding: @import “base/base”; to the top of the file. This gives us all variables, functions and other nice Sassy stuff we might want to use.

Sass Pitfalls

Nesting

All CSS pre-processors allow their users to fall into this trap: nesting hell. This is where you nest styles inside one another, while it might look neat and manageable on your side, the generated CSS looks like this:

.selector > .someotherselector table > tr > td

Doesn’t that make you want to gouge your eyes out? As a general rule of thumb, limit any nesting to 3 levels. Try using BEM for your CSS to prevent nesting altogether.

Duplicating Compass or Bourbon Functionality

Heck, even I’ve done this before (too many times to count). Be mindful of whether or not that mixin you are writing already exists if you’re using Compass or Bourbon (chances are it does). You’d be surprised what they cover (all CSS3 properties/prefixes, colour manipulation and more).

Inline Media Queries

A cool feature in Sass is being able to nest media queries inside of a selector which will output a media query with the style change for the specified breakpoint.

In this post, arguments for inline media queries are pretty convincing. It’s not so much a pitfall, but rather something you need to be aware of. Inline media queries will mean duplicates (unless you use a Grunt or Gulp task to combine them).

That is pretty much it. The approach has flaws like being too modular and forgetting to include a file or getting caught in dependency hell where one file relies upon another file being include first before it will work properly, but managing things properly from the start avoids this.

In Defence of WordPress: The Anti-WordPress Movement

For some time now there has been a slowly growing movement amongst particular designers and developers against WordPress. We’ve seen light CMS’s, decoupled PHP frameworks, open source alternatives and the big one: static site generators, but no matter the alternative, it seems it’s for the wrong intentions.

What WordPress Is

Firstly, WordPress is a content management system that started out as a blogging platform. I’d actually argue WordPress is a framework of sorts in that it provides you with; user authentication, plugins sytem, themes system, helper classes and a loose structure which it expects you to follow (but isn’t overly strict on).

Over the years WordPress has grown in size and scope (like most projects of WordPress’ age do), but there have been more concentrated efforts for some time now to make it faster, lighter and eliminate legacy code (one release at a time). Having said that, WordPress is quite large and could be considered a heavy application.

What WordPress Isn’t

Wordpress is not some magic cure-all, bulletproof solution for every purpose.

You can build absolutely anything in WordPress, however that doesn’t mean you should. You can build portfolios, CRM’s, project management applications, video streaming sites, community based sites, blogs, online stores and even fully-blown web applications on-top of it (thanks to its generous selection of plugins and free/commercial themes).

Wordpress isn’t a magical bullet that is meant to replace existing PHP frameworks or other CMS’s like Drupal. It can be overkill for many purposes and sometimes it is better to use something built for the task at hand instead of WordPress (a large online store for example should not use WordPress).

Arguments

Argument #1 - Wordpress is too slow and doesn’t scale that well

Like any PHP application, performance isn’t limited to a code level. There are things like server resources, configuration and database query optimisation to consider. Under the hood the WordPress query system is actually quite good with support for caching and query optimisation out-of-the-box.

There are quite a lot of decent caching plugins for WordPress, my favourite is W3 Total Cache. Not only do they cache pages to static HTML files, they also cache DB queries, images and enforce good habits like setting expiry periods for your static resources (images, HTML, CSS).

Most instances I’ve encountered with slow performing WordPress installations were mostly due to horrible hosting environments (shared hosting like Hostgator, Dreamhost, Bluehost) and poorly written 3rd party plugins.

Wordpress is only as fast as you allow it to be. Install NGINX, PHP-FPM, Varnish and APC, then install a caching plugin and marvel at how fast your site runs. Tweaking your NGINX configuration file can squeeze out additional performance.

This article explains all you need to know to install the above aforementioned items on your server.

Look at sites like Techcrunch (running WordPress), they’re being hosted on properly configured servers running NGINX, using a combination of caching plugins and server-side caching solutions like Varnish and APC. Considering the traffic they get, I’d say they scaled WordPress quite fine.

Argument #2 - Wordpress is bloated

This is true, but a somewhat misguided argument. WordPress is quite a big web application, and there is a good chance a lot of the functionality bundled with WordPress out-of-the-box is not being used most of the time.

Given its age, there are pieces of legacy code and functionality which aren’t so easy to decouple and change. As anyone who has worked with a large-scale legacy code-base will tell you: it’s not that simple.

However, WordPress is getting less bloated with each and every release. The core team are aware of this and things like application size are not going unnoticed.

The size of WordPress itself is by no means a barrier to building something with it. It’s really a non-issue considering you’ll spend your time working in the “wp-content/themes” and “wp-content/plugins folders” and shouldn’t ever need to edit core files.

Argument 3 – Upgrades break 3rd party plugins

This is a very valid argument. With most things that rely upon 3rd party dependencies you take the risk with each and every upgrade that an existing dependency/plugin might stop working, which obviously on a client website is a bad thing.

It’s really a catch 22 here: upgrade and risk a breakage, or don’t upgrade and risk having your site hacked because of an exploit in an older version of WordPress.

For quite a while now, WordPress has been relatively stable. There have been minimal changes in the API and the core team are very careful to not deliberately remove something or risk changing things to the point existing plugins completely break.

If a plugin is built to proper coding standards, adheres to WordPress’ way of doing things as much as possible, the chances of a plugin breaking are quite low.

I can’t recall a situation in the last 3 or so years where a change to WordPress broke a plugin. Where possible and time permits, you should be trying to not use plugins (unless you have to).

Most instances of plugin breaks are due to reliance on API’s (social networking plugins especially) and bad practices (I’ve seen plugins with hard-coded table prefixes expecting your installation to use “wp_” before).

Argument #4 – WordPress is unsafe because it is a target of hackers

Before WordPress even existed hackers were attacking other popular applications, Windows used to be the frequent target of hackers in the 90′s, 00′s and still today. Why? Because it’s popular. The larger the user-base is of something, the higher chances of finding a victim to attack. WordPress is used by millions of people, if you were a hacker, you’d attack WordPress too, right?

Recent improvements to WordPress with minor version auto-updating are good steps in the right direction to secure your site. The WordPress team can only do so much, ensuring your server is secured is also another proactive step (proper file/folder permissions, user separation) to not being hacked.

There is no such thing as being 100% hacker-proof, an application of WordPress’ stature and size, as well as list of 3rd party dependencies and libraries means potentially many points of entry for an attacker. This is a problem many applications like WordPress face on a daily basis.

To the credit of the WordPress team, I can’t recall an incident with a client or personal site being hacked in at least a year, maybe longer. A couple of years ago my WordPress sites were being targeted a lot, but things have since changed.

The Wordfence Security plugin for WordPress is a must-have and if you’re not already using it, install it now.

Conclusion

Be informed when deciding to choose WordPress for your next project, but don’t write it off as a bloated insecure mess, because you might be pleasantly surprised of all the things WordPress offers you that you are taking for granted.

There are situations where it makes more sense to use a static site generator and there are situations where using Magento for that online store makes more sense. Use whatever works for you and not because it’s cool to hate on something else.

Has There Been Another Google Algorithm Update For July 2014?

For some weird reason, this very blog has started getting a lot of traffic the last few days, from Google. I wonder if Google have recently tweaked their search algorithm again?

I have been trying to update the blog on a more regular basis, I’ve been posting two, sometimes three posts a day and I have been focusing on making the quality of them as decent as I can.

Perhaps I am experiencing the effects of a previous search engine algorithm change, and my recent updates have put me into the upper-echelon of Google’s almighty preference circle.

Anyone else seeing similar changes in traffic for their sites/blogs from Google traffic?