10 Useful WordPress Security Tweaks – Smashing Magazine

 

Security has always been a hot topic. Offline, people buy wired homes, car alarms and gadgets to bring their security to the max. Online, security is important, too, especially for people who make a living from websites and blogs. In this article, we’ll show you some useful tweaks to protect your WordPress-powered blog.

[Offtopic: by the way, did you know that there is a Smashing eBook Series? Book #1 is Professional Web Design, 242 pages for just $9,90.]

1. Prevent Unnecessary Info From Being Displayed

The problem
When you fail to log into a WordPress blog, the CMS displays some info telling you what went wrong. This is good if you’ve forgotten your password, but it might also be good for people who want to hack your blog. So, why not prevent WordPress from displaying error messages on failed log-ins?

The solution
To remove log-in error messages, simply open your theme’s functions.php file, and paste the following code:

view source

print?

1
add_filter('login_errors',create_function('$a', "return null;"));

Save the file, and see for yourself: no more messages are displayed if you fail to log in.

Please note that there are several functions.php files. Be sure to change the one in your wp-content directory.

Code explanation
With this code, we’ve added a simple hook to overwrite the login_errors() function. Because the custom function that we created returns only null, the message displayed will be a blank string.

Source

2. Force SSL Usage

The problem
If you worry about your data being intercepted, then you could definitely use SSL. In case you don’t know what it is, SSL is a cryptographic protocol that secures communications over networks such as the Internet.

Did you know that forcing WordPress to use SSL is possible? Not all hosting services allow you to use SSL, but if you’re hosted on Wp WebHost or HostGator, then SSL is enabled.

The solution
Once you’ve checked that your Web server can handle SSL, simply open your wp-config.php file (located at the root of your WordPress installation), and paste the following:

view source

print?

1
define('FORCE_SSL_ADMIN', true);

Save the file, and you’re done!

Code explanation
Nothing hard here. WordPress uses a lot of constants to configure the software. In this case, we have simply defined the FORCE_SSL_ADMIN constant and set its value to true. This results in WordPress using SSL.

Source

3. Use .htaccess To Protect The wp-config File

The problem
As a WordPress user, you probably know how important the wp-config.php file is. This file contains all of the information required to access your precious database: username, password, server name and so on. Protecting the wp-config.php file is critical, so how about exploiting the power of Apache to this end?

The solution
The .htaccess file is located at the root your WordPress installation. After creating a back-up of it (it’s such a critical file that we should always have a safe copy), open it up, and paste the following code:

view source

print?

1
<files wp-config.php>

2
order allow,deny

3
deny from all

4
</files>

Code explanation
.htaccess files are powerful and one of the best tools to prevent unwanted access to your files. In this code, we have simply created a rule that prevents any access to the wp-admin.php file, thus ensuring that no evil bots can access it.

Source

4. Blacklist Undesired Users And Bots

Sm4 in 10 Useful WordPress Security Tweaks

The problem
This is as true online as it is in real life: someone who pesters you today will probably pester you again tomorrow. Have you noticed how many spam bots return to your blog 10 times a day to post their annoying comments? The solution to this problem is quite simple: forbid them access to your blog.

The solution
Paste the following code in your .htaccess file, located at the root of your WordPress installation. As I said, always back up the .htaccess file before editing it. Also, don’t forget to change 123.456.789 to the IP address you want to ban.

view source

print?

1
<Limit GET POST PUT>

2
order allow,deny

3
allow from all

4
deny from 123.456.789

5
</LIMIT>

Code explanation
Apache is powerful and can easily be used to ban undesirable people and bots from your website. With this code, we’re telling Apache that everyone is allowed to visit our blog except the person with the IP address 123.456.789.

To ban more people, simply repeat line 4 of this code on a new line, using another IP address, as shown below:

view source

print?

1
<Limit GET POST PUT>

2
order allow,deny

3
allow from all

4
deny from 123.456.789

5
deny from 93.121.788

6
deny from 223.956.789

7
deny from 128.456.780

8
</LIMIT>

Source

5. Protect Your WordPress Blog From Script Injections

The problem
Protecting dynamic websites is especially important. Most developers always protect their GET and POST requests, but sometimes this is not enough. We should also protect our blog against script injections and any attempt to modify the PHP GLOBALS and _REQUEST variables.

The solution
The following code blocks script injections and any attempts to modify the PHP GLOBALS and _REQUEST variables. Paste it in your .htaccess file (located in the root of your WordPress installation). Make sure to always back up the .htaccess file before modifying it.

view source

print?

1
Options +FollowSymLinks

2
RewriteEngine On

3
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]

4
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]

5
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})

6
RewriteRule ^(.*)$ index.php [F,L]

Code explanation
Using the power of the .htaccess file, we can check requests. What we’ve done here is check whether the request contains a <script> and whether it has tried to modify the value of the PHP GLOBALS or _REQUEST variables. If any of these conditions are met, the request is blocked and a 403 error is returned to the client’s browser.

Sources

6. Fight Back Against Content Scrapers

The problem
If your blog is the least bit known, people will no doubt try to use your content on their own websites without your consent. One of the biggest problems is hot-linking to your images, which saps your server’s bandwidth.

The solution
To protect your website against hot-linking and content scrapers, simply paste the following code in your .htaccess file. As always, don’t forget to back up when modifying the .htaccess file.

view source

print?

1
RewriteEngine On

2
#Replace ?mysite\.com/ with your blog url

3
RewriteCond %{HTTP_REFERER} !^http://(.+\.)?mysite\.com/ [NC]

4
RewriteCond %{HTTP_REFERER} !^$

5
#Replace /images/nohotlink.jpg with your "don't hotlink" image url

6
RewriteRule .*\.(jpe?g|gif|bmp|png)$ /images/nohotlink.jpg [L]

Once you’ve saved the file, only your website will be able to link to your images, or, to be more correct, no one would link to your images, because it would be way too complicated and time-consuming. Other websites will automatically display the nohotlink.jpg image. Note that you can also specify a non-existent image, so websites that try to hot-link to you would display a blank space.

Code explanation
With this code, the first thing we’ve done is check the referrer to see that it matches our blog’s URL and it is not empty. If it doesn’t, and the file has a JPG, GIF, BMP or PNG extension, then the nohotlink image is displayed instead.

Source

7. Create A Plug-In To Protect Your Blog From Malicious URL Requests

Sm7 in 10 Useful WordPress Security Tweaks

The problem
Hackers and evil-doers often use malicious queries to find and attack a blog’s weak spots. WordPress has good default protection, but enhancing it is possible.

The solution
Paste the following code in a text file, and save it as blockbadqueries.php. Once you’ve done that, upload it to your wp-content/plugins directory and activate it as you would any other plug-in. Now your blog is protected against malicious queries.

view source

print?

01
<?php

02
/*

03
Plugin Name: Block Bad Queries

04
Plugin URI: http://perishablepress.com/press/2009/12/22/protect-wordpress-against-malicious-url-requests/

05
Description: Protect WordPress Against Malicious URL Requests

06
Author URI: http://perishablepress.com/

07
Author: Perishable Press

08
Version: 1.0

09
*/

10

11
global $user_ID

12

13
if($user_ID) {

14
if(!current_user_can('level_10')) {

15
if (strlen($_SERVER['REQUEST_URI']) > 255 ||

16
strpos($_SERVER['REQUEST_URI'], "eval(") ||

17
strpos($_SERVER['REQUEST_URI'], "CONCAT") ||

18
strpos($_SERVER['REQUEST_URI'], "UNION+SELECT") ||

19
strpos($_SERVER['REQUEST_URI'], "base64")) {

20
@header("HTTP/1.1 414 Request-URI Too Long");

21
@header("Status: 414 Request-URI Too Long");

22
@header("Connection: Close");

23
@exit;

24
}

25
}

26
}

27
?>

Code explanation
What this code does is pretty simple. It checks for excessively long request strings (more than 255 characters) and for the presence of either the eval or base64 PHP functions in the URI. If one of these conditions is met, then the plug-in sends a 414 error to the client’s browser.

Source

8. Remove Your WordPress Version Number… Seriously!

The problem
As you may know, WordPress automatically displays the version you are using in the head of your blog files. This is pretty harmless if your blog is always up to date with the latest version (which is certainly what you should be doing anyway). But if for some reason your blog isn’t up to date, WordPress still displays it, and hackers will learn this vital piece of information.

The solution
Paste the following line of code in the functions.php file of your theme. Save it, refresh your blog, and voila: no more WordPress version number in the header.

view source

print?

1
remove_action('wp_head', 'wp_generator');

Code explanation
To execute certain actions, WordPress uses a mechanism called “hooks,” which allow you to hook one function to another. The wp_generator function, which displays the WordPress version, is hooked. We can remove this hook and prevent it from executing by using the remove_action() function.

Source

9. Change The Default “Admin” Username

Sm9 in 10 Useful WordPress Security Tweaks

The problem
Brute force is one of the easiest ways to break a password. The method is simple: try as many different passwords as possible until the right one is found. Users of the brute force method use dictionaries, which give them a lot of password combinations.

But knowing your username certainly makes it easier for them to guess the right combination. This is why you should always change the default “admin” username to something harder to guess.

Note that WordPress 3.0 let you choose your desired username by default. Therefore, this tip is still usefull if you still use the old “admin” account from older WordPress versions.

The solution
If you haven’t changed the “admin” username yet, simply run the following SQL query to your database to change it for good. Don’t forget to specify your desired username.

view source

print?

1
UPDATE wp_users SET user_login = 'Your New Username' WHERE user_login = 'Admin';

Code explanation
Usernames are stored in the database. To change one, a simple UPDATE query is enough. Note that this query will not transfer posts written by “admin” to your new username; the source post below shows you how to easily do that.

Source

10. Prevent Directory Browsing

The problem
By default, most hosts allow directory listing. So, if you type http://www.yourblog.com/wp-includes in the browser’s address bar, you’ll see all of the files in that directory. This is definitely a security risk, because a hacker could see the last time that files were modified and access them.

The solution (Updated)
Just add the following to the Apache configuration or your .htaccess file:

view source

print?

1
Options -Indexes

Code explanation
Please note that it’s not enough to update the blog’s robots.txt file with Disallow: /wp*. This would prevent the wp-directory from being indexed, but will not prevent users from seeing it.

Source

Smarter Grids With Sass And Susy

Michelle Barker shows how to create fast, responsive, fully customizable grids in CSS without touching your markup with Susy, a Sass-based grid framework.

If you’re a designer, you’ll know that grids are your friends. More often than not, they’re the vital architecture that holds a beautiful design together; they create rhythm, structure your page, lead the eye, and prevent the whole thing collapsing in a sloppy mess.

I’m a firm advocate for designing with the browser: prototyping with HTML and CSS has many clear advantages over static Photoshop comps, which have less value for the responsive web. Unfortunately, HTML, CSS and grids aren’t natural bedfellows: the progression of web standards over the years has been lacking in this area, meaning we have to grapple with floats (which were never designed to be used this way) and clearfixes — not ideal when you want to spend less time debugging layout and more time crafting experiences.

The relatively new implementation of the flexbox and CSS grid layout modules are on course to free us from the constraints of floats and allow us to create some pretty interesting layouts — which I’m excited about — but they’re not a magic bullet. Even with those, coding up a layout can still be a lengthy process for a designer, and require you to remember a bunch of not very intuitive properties.

Happily, lots of tools currently exist to enable you to quickly design grids for the web, from CSS frameworks like Bootstrap and Foundation, to sites like Responsive Grid System. However, frameworks have their drawbacks, such as requiring you to add a large number of classes to your markup, and delivering a bloated codebase that can be bad for performance.

Luckily for us, solutions exist to the problem of creating fast, responsive, fully customizable grids: Susy is a Sass-based grid framework. It’s very lightweight and enables you to create entirely custom grids in CSS without touching your markup.

Susy was developed by Eric M. Suzanne, with support from Chris Eppstein — creator of Compass and co-creator of Sass — so it’s very well supported in the Sass community and it’s rapidly gaining in popularity.

Framework Or Not? Link

I tend to refer to Susy as a framework, but it may be more accurate to call it a grid system. Unlike more traditional frameworks, Susy doesn’t require you to add classes to your HTML elements. Susy is written entirely in your SCSS file by adding mixins and functions, using media queries to customize your layout at your own specified breakpoints. It enables you to keep content and style entirely separate — not essential all the time, but widely viewed as best practice.

Before we continue, I should point out that Susy isn’t the only solution: Zen Grids by John Albin and Jeet by Cory Simmons are two others. Singularity is also a pretty interesting framework, which works in a similar way to Susy, using Sass mixins rather than adding classes to your HTML. However, Susy has a growing community and helpful documentation, making it a good choice to get started with.

Advantages Link

Why might you want to use Susy in your next project? There are several advantages:

  1. (Relatively) Easy to Learn
    If you’ve used other frameworks (like Bootstrap or Foundation), and if you’re familiar with Sass at all, Susy shouldn’t be too difficult for you to pick up. Even if you’re fairly new to Sass, Susy doesn’t require in-depth knowledge and is a great way to start! The examples in this article assume a working knowledge of Sass, so it’s worth reading up a little if you’re not familiar.
  2. Speed Up Your Workflow
    Unlike many other frameworks, Susy doesn’t come with a bunch of default styling that you need to overwrite. In fact, Susy has no styling: it’s purely a grid layout system. Its purpose is to do the maths for you — anything else is for you to add. Once you’re familiar with a few of Susy’s mixins, you’ll find it’ll save you time and free you up to concentrate on design.
  3. Use as Much or as Little as You Like
    As with Sass, you can pick and choose what works for you. We’ll focus on a few fairly simple examples here, but you can use Susy to do some pretty complex things if you’re so inclined!

I should also point out that while Susy currently relies on traditional floats to position your grid, the documentation indicates that flexbox and CSS grid layout could well be forthcoming, which will make it even more powerful!

Getting Started Link

Susy was designed to work with Compass, so if you already have Compass installed then setting up Susy is straightforward. You don’t actually need to use Compass in order to use Susy — Susy is compatible with just about any Sass workflow — but for the purpose of getting started I’ll be using Compass as a primary example.

To install Susy, simply run the following in the command line:

$ gem install susy

(If you get an error, you may need to prefix this command with sudo.)

Then set up your new project. If you’re using Compass, in your config.rb you need to add require 'susy'. Then, in your main SCSS file (in this case screen.scss) add @import "susy"; to import Susy into your project.

Alternatively, CodeKit is an excellent app for getting up and running with everything you need and allows you to add Susy to your project quickly and easily.

Finally, we need to create an index.html file in our project folder to house our markup, and link it to our style sheet.

Building Our First Susy Grid Link

Assuming you’ve gone through the necessary steps to run Susy in your project, we’re ready to create our first layout. First of all, we need to define some parameters for our grid in a map at the beginning of our main SCSS file. If you’ve come across Sass maps, you’ll be familiar with the syntax:

$susy: (
  columns: 12,
  container: 1200px,
  gutters: 1/4,
  global-box-sizing: border-box,
  debug: (image: show)
);

In this map you can define pretty much any of the global settings for your grid, from the number of columns to gutter width, all of which are listed in the Susy documentation. If you don’t enter a setting in your map, Susy will simply use its default settings. There are a few things we’ll need to define to create our grid:

  • The number of columns we’ll use.
  • The maximum width of the container. If you don’t specify a width, your container will be 100% of the width of the viewport, like any block element. You might want this in some cases but, especially while we’re learning, setting a maximum width allows us to see more clearly what’s going on.
  • Gutters. By default Susy includes gutters as right-hand margins on your columns and at one quarter (1/4) of the column width. You can change the gutter ratio here, or use gutter-position to decide how you want gutters to behave.
  • Box-sizing. I always prefer to set this to border-box. (Susy’s default is content-box.)
  • The debug image. Setting this to show displays a background image showing your column grids, useful for making sure everything is aligned correctly and your elements behave as they should.

Creating A Basic Layout Link

We’re going to start by creating this simple layout using Susy:

We’ll start with some markup containing a header, a main content area with article and sidebar, and a footer.

<main class="wrapper">
  <header></header>
  <article></article>
  <aside></aside>
  <footer></footer>
</main>

As I previously mentioned, Susy depends entirely on CSS and Sass to customize your grid, so you don’t need to add anything else to your HTML. The most important feature for creating grids in Susy is the span mixin. Use @include to include the mixin in your Sass. As you can see from the image, we want our header and footer to take up 100% of the container width, so we don’t need to do anything here. But we need our<article> and <aside> elements to take up eight columns and four columns respectively in our twelve-column grid. In order to achieve this we need to use thespan mixin:

/* SCSS */

article {
  @include span(8 of 12);
  /* More styles here */
}

aside {
  @include span(4 of 12 last);
  /* More styles here */
}

There are a couple of things to note here:

  1. Susy depends on context: we could easily write @include span(8) for the<article> element, which would produce the same result because we already defined our layout as four columns in the map. However, if we wanted to override the map for this particular element (say, subdivide this area of our layout into a greater number of columns), we need to specify the context — in this case, twelve columns.
  2. We want the <aside> to be the last item in the row, so we’ve added the wordlast to the mixin. This tells Susy to remove the right-hand margin on that element so that it fits on the row.

If we take a look at our CSS file, we’ll see the above Sass compiles to:

article {
  width: 66.10169%;
  float: left;
  margin-right: 1.69492%;
}

aside {
  width: 32.20339%;
  float: right;
  margin-right: 0;
}

You can see that Susy has calculated our column widths and gutters based on the settings we specified in our map.

In the Codepen example I’ve included some dummy content, as well as a little padding and a background color on our elements. Without these our grid would simply be invisible, as Susy has no default styling.

As we’re floating elements, we also need to remember to clear our footer:

    
header {
  padding: 2em;
  background-color: #FF4CA5; /* Of course, you can define your colours as variables if you prefer! */
}

article {
  @include span(8);
  padding: 2em;
  background-color: #ff007f;
}

aside {
  @include span(4 last);
  padding: 2em;
  background-color: #CC0066;
}

footer {
  clear: both;
  padding: 2em;
  background-color: #7F2653;
}

Finally, we’ll include the container mixin in our main element to give our content a maximum width and position it in the center of the page by setting the left and right margins to auto:

main.wrapper {
  @include container;
}

With these additions, we get this result:

Refining Our Grid Link

We could do with separating the elements to make our layout more pleasing. Let’s add a bottom margin to our <header>, <article> and <aside> elements. What would make an even more appealing layout would be to make our bottom margins the same width as our column gutters. With Susy, we can do this using the gutter function (as opposed to the mixin):

header, article, aside {
  margin-bottom: gutter();
}

As we haven’t specified a value in the gutter function, Susy will use our map settings; that is, 1/4 column-width in a twelve-column layout. But if, for instance, the section we were working on was only eight columns wide, we may want to specify gutter(8) to create the same effect.

Our SCSS file now looks like this:

main {
  @include container;
}

header, article, aside {
  margin-bottom: gutter();
}

header {
  padding: 2em;
  background-color: #FF4CA5;
}

article {
  @include span(8);
  padding: 2em;
  background-color: #ff007f;
}

aside {
  @include span(4 last);
  padding: 2em;
  background-color: #CC0066;
}

footer {
  clear: both;
  padding: 2em;
  background-color: #7F2653;
}

Now our layout looks like this:

Mixins Vs. Functions Link

We just used gutter as a function, as opposed to including it in a mixin. It’s worth noting that span, gutter and container can all be used as both mixins and functions. The Susy documentation outlines use cases for each, but our next example should help give you an understanding of the circumstances in which a function might be useful.

There’s one more thing that will no doubt be extremely handy to you as a designer: thegallery mixin. As the Susy documentation succinctly puts it, “Gallery is a shortcut for creating gallery-style layouts, where a large number of elements are layed [sic] out on a consistent grid.” It’s great for unordered lists, for example, if you want to create a portfolio page.

We’ll use the following markup for a gallery of twelve items — again, I’ve added some placeholder content in the Codepen example:

<main>
  <header></header>
  <article>
    <ul class="gallery">
      <li></li>
      <li></li>
      <li></li>
      <li></li>
      <li></li>
      <li></li>
      <li></li>
      <li></li>
      <li></li>
      <li></li>
      <li></li>
      <li></li>
    </ul>
  </article>
  <aside></aside>
  <footer></footer>
<main>

We’ll keep the same SCSS from the previous example, with the addition of the following:

ul.gallery {
  padding: span(1 of 8);
  list-style: none;
}
    
.gallery li {
  @include gallery(2 of 6);
  margin-bottom: gutter(6);
  
  &:nth-last-child(-n + 3) {
    margin-bottom: 0;
  }
}

There are a few things going on here:

  1. First, we’re using span as a function to add one column-width of padding all the way around our gallery. As the element is eight columns wide, taking up one column-width on either side leaves us with the remaining six columns for our gallery items.
  2. Using the gallery mixin on our <li> element (@include gallery(2 of 6)), we’re telling Susy that each item should take up two columns in our six-column width. That means that each row will hold three gallery items.
  3. Using the gutter function (margin-bottom: gutter(6)) we’re adding a bottom margin the equivalent of one gutter-width in our six-column context to each item in our gallery. I’m using the :nth-child pseudo-class to remove the bottom margin from our last row, giving us a perfectly even amount of spacing around our gallery.
  4. As we’re floating elements, we’ll also need a clearfix on the parent element (in this case the ul element). In the example, I’m using Compass’s clearfix, but you could create your own mixin, or write it longhand.
    ul.gallery {
      @include clearfix;
    }

Result:

Susy For Responsive Web Design Link

Although the examples we’ve walked through so far are based on fluid grids (Susy’s default), they aren’t responsive — yet. At the beginning of this article I mentioned that Susy is a great tool for designing responsively. Let’s look at one more example to see how we can use Susy to create a layout that adapts to different viewport sizes.

In this demo we’ll use use media queries in our Sass, along with Susy’s layout mixin to customize our grid for different breakpoints.

You’ll recall that at the beginning of our SCSS file we created a map with our global settings. In fact, we can create any number of maps and summon them at will into our layout with this mixin. This is useful if at a certain breakpoint you want to switch from, for instance, a twelve-column to a 16-column layout with no gutters. Our second map may look something like this:

$map-large: (
  columns: 16,
  container: auto,
  gutters: 0,
  global-box-sizing: border-box
);

For this example I’ve created a simple gallery webpage displaying a collection of photos of found typography. Taking a mobile-first approach, our first step is to create a single-column view, where our main elements take up the full width of the page. However, in our gallery section, we want our images to display in rows of two once our viewport gets wider than, say, 400px and in rows of three after 700px. We’re using atwelve-column grid in our global settings, so all we need to do is instruct Susy to set our gallery items at six columns out of twelve, and four columns out of twelve respectively, in min-width media queries:

li {
  @media (min-width: 480px) {
    @include gallery(6);
    margin-bottom: gutter();
  }
  @media (min-width: 700px) {
    @include gallery(4);
    margin-bottom: gutter();
  }
}

At widths above 700px, this is what our webpage looks like:

At desktop sizes we’re going to make our layout a little more complex. Here we want our header to display as a bar on the left-hand side and our gallery items to display in rows of four on the right of the screen, with no gutters. To achieve this we’re going to switch to a 16-column layout, as defined in the new map we created a moment ago.

We’re going to use the layout mixin as follows:

@media (min-width: 1100px) {
  @include layout($map-large);
  
  header {
    @include span(4);
  }
  
  main {
    @include span(12 last);
  }
  
  li {
    @include gallery(3 of 12);
    margin-bottom: 0;
  }
}

The layout mixin sets a new layout for our grid. Any code following this mixin will be affected by the 16-column layout we specified. (Note: if you want to revert back to a different layout, you’ll need to use this mixin again to call a different map, as your code will be affected by this mixin until you specify otherwise!)

In this instance, the <header> element will span 4 colomns out of 16 and the main content area will span the remaining 12 out of 16 columns. Because our gallery items are nested within this 12-column section, we should specify that they take up 3 columns out of 12 (rather than 16).

The above code gives us this layout at desktop sizes:

Dealing With Sub-Pixel Rounding Link

If you’re working with percentage-based grids you’re going to come up against sub-pixel rounding issues. These occur when percentages result in column widths that subdivide a pixel, so the browser rounds your column width up or down by a pixel to compensate. This may mean your layouts don’t always behave as you might expect. For a full explanation of sub-pixel rounding, read “Responsive Design’s Dirty Little Secret” by John Albin Wilkins.

Susy provides a workaround for dealing with sub-pixel rounding via its isolatetechnique, and it’s a handy port of call when your layouts aren’t playing nice.

Conclusion Link

I hope this article has helped you get started with Susy and provided a small taste of what is possible. Once you spend a little time getting the hang of it, you’ll see how easy and fast it is to create simple or complex layouts without a huge amount of code; and it really will save you time in the long run.

Here are some useful links and resources to help you get started with Susy:

(ds, ml, og)

Fonte: Smarter Grids With Sass And Susy

SXO a evolução do SEO ou um complemento?

O SXO (Search eXperience Optimization) tem sido cada vez mais utilizado no universo Web. Há quem afirme até que o SEO está a caminhar para a extinção. E porquê? Porque o SEO (na grande maioria das vezes) apenas se baseia em melhorar os resultados nas pesquisas pelos motores de pesquisa, deixando por vezes outros pormenores muito importantes “esquecidos”.

Na minha opinião o SXO é um “complemento”.

O SXO baseia-se (tal como o próprio nome indica) na otimização da experiência do utilizador quando navega num website.

Um exemplo simples é a página com o erro “404 – Not Found”.

O SEO pode ser fantástico, mas se depois a experiência do utilizador no website não for a mais positiva, todo o trabalho desenvolvido em SEO não servirá para nada.

Imagine que clica numa página nos resultados de um motor de pesquisa e é redirecionado para uma página “inexistente”. Esta situação é má para SEO, mas é ainda pior para o utilizador. O que acontece? O utilizador provavelmente volta aos resultados de pesquisa e escolhe outro website!

Outro exemplo, que infelizmente é bastante recorrente, é a utilização de produtos sem descrição, imagem e informações adicionais numa loja online (por exemplo). Logo, por muito bom que seja o trabalho SEO, se o utilizador não reconhece qualquer valor acrescentado no website que acaba de visitar certamente não voltará, escusado será dizer que neste caso nem com o “melhor” SEO haveria bons resultados.

Search eXperience Optimization

Embora apenas tenha mudado uma palavra – ‘engine’ para ‘experience’ o SXO fornece uma visão muito diferente. Aqui estão quatro maneiras de focar/melhorar a experiência que dá aos seus visitantes/compradores, e, finalmente, o valor que ele dá ao seu negócio:

1. O utilizador como “centro” do seu negócio online

Não se esqueça que será uma pessoa e não uma máquina a comprar seja o que for no seu website/loja. Com isto queremos dizer que deve verificar se o tipo de linguagem que utiliza no website/loja está efetivamente enquadrada com o utilizador final.

Se fizer esse pequeno procedimento, irá certamente associar melhor as palavras chave que identificam o que pretende vender. Se o conteúdo é verdadeiramente valioso, terá cada vez mais visitas e com isso mais relevância para classificação nos motores de pesquisa.

Lembre-se, quem pesquisa são pessoas, não os motores de pesquisa.

2. Alinhar com os objetivos dos administradores

Muito provavelmente, o termo SEO não é associado com tanta importância como um objetivo estratégico por parte dos administradores das empresas.
Contudo, a “experiência do cliente” já o será. Cada vez mais os administradores pretendem não só angariar novos clientes, como também fidelizar os existentes. Para que isso seja possível ter uma experiência de qualidade em todas as fases de um relacionamento comercial é fundamental.

Ter um website/loja que cative os clientes poderá ser um excelente início para uma relação comercial.

3. Alinhar com a equipa de desenvolvimento WEB

No desenvolvimento de soluções web, sobretudo aquelas que terão uma forte interação com o utilizador final, o SXO deve estar o mais presente possível. É fundamental que todos os envolvidos no processo de desenvolvimento estejam focados na experiência do utilizador (UX – User eXperience). O importante é que os utilizadores encontrem a informação correta e de fácil acesso. Ninguém gosta de procurar “eternamente” informação num website!

4. Alinhamento estratégico da pesquisa orgânica ou paga

SEO, SEA, PPC, SEM. Quem se importa? O mais importante é “dar” ao utilizador aquilo que ele realmente procura. Claro que é importante ter excelentes resultados nos resultados das pesquisas, mas deve, como é óbvio, integrar tudo numa só estratégia.

Por vezes existem equipas diferentes e autónomas nas estratégias WEB, uma equipa para SEO, outra para desenvolvimento, outra para anúncios, etc. Apesar de não ser “errado”, certifique-se que essas equipas comunicam entre si e que elevem ao máximo a otimização da experiência do utilizador, seja em valência for.

Quanto mais os utilizadores valorizarem o seu website/loja, mais facilmente o mesmo terá uma melhor classificação nos motores de pesquisa. Todo o trabalho envolvente será mais potencializado (Vendas, novos clientes, etc).

Foque-se na experiência do utilizador!

Fonte: SXO a evolução do SEO ou um complemento?

Controle o Android pelo seu computador com o Vysor

A chegada do Vysor vem abrir novas portas e novas possibilidades. Com o Chrome e o Vysor podem agora controlar directamente o Android em qualquer computador.

Vysor

Download: Vysor

Preço: Gratuito

chrome_store

 

Fonte: Controle o Android pelo seu computador com o Vysor