Loading...

Follow WPShout — WordPress Development Tutorials and.. on Feedspot

Continue with Google
Continue with Facebook
or

Valid

Is Email Making Professors Stupid? →

Focus for longer, and understand the cost of admin work.

Long-time readers will know Cal Newport’s books and ideas are a favourite of mine – especially his “Deep Work” philosophy. This post combines Deep Work with some of the themes from Cal’s new book on Digital Minimalism, and he argues that admin work, and email in particular, is stopping leading academics from doing the work they’re best at, and having the creative breakthroughs that their predecessors have enjoyed.

This post specifically is applied to Cal’s “home” field of academia, but there are plenty of ideas which can apply to the WordPress world. The primary item is understanding the impact of any work which isn’t whatever you’re the very best at, how this interrupts your ability to focus for sustained periods, and what the opportunity cost of this is.

Slack comes to mind immediately; it’s an integral part of making WordPress, but it also demands our attention, all the time. Perhaps we need to create boundaries, and urgently get much better at doing so.

This post first appeared in MasterWP, a weekly newsletter for WordPress professionals.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

A GitHub Action to Deploy to the Plugin Repo →

Deploying a WordPress plugin to the WordPress.org repository has been challenging for most developers for at least a few years. Why? Mostly because almost no one learns Subversion (the version control system that WordPress.org uses) anymore. So we’ve all cobbled together different versions of things that kind of work. And at least for me, I often forget what mine is, and how to use it. (For those real nerdy folks, what I have used a variation of Scribu’s scripts: http://scribu.net/blog/deploying-from-git-to-svn.html. It works for me, but I wouldn’t really recommend it as the perfect system. It’s just good enough that I’ve not sought an alternative.)

For that reason, many people including me were quite excited to see this post on the 10up blog from Helen Hou-Sandi. What she announces is that using the new GitHub Actions (still in beta) feature, they’ve developed a way to fairly seamlessly deploy a GitHub repository as a plugin on WordPress.org. To get it working you’ll need to be approved for the GitHub Actions beta, or wait for its wide release. (I’m still waiting for approval.)

But anything that makes deploying plugins easier for most developers is very welcomed, so I’m excited for this. Yay Helen and 10up!

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

This article introduces an important concept in WordPress themes: the WordPress get_template_part function. It’s one of the many important concepts of WordPress theme development. Mastering WordPress theme development is an important milestone in understanding WordPress development more generally. (We have a full free course on the topic, check it out.)

This content is not just one of our normal articles: it’s a sample chapter from our “learn WordPress development” guide Up and Running, our comprehensive summary of all the information a person needs to be rolling as a WordPress developer.

If you like this chapter, check out Up and Running. There’s about 40 more chapters where this one came from. It’s the best guide to WordPress development out there.

The Ultimate Way to Learn WordPress Development ConceptsGet Up and Running Today! Up and Running is our complete “learn WordPress development” course. Now in its updated and expanded 3rd Edition, it’s helped hundreds of happy buyers learn WordPress development the fast, smart, and thorough way.

Key Takeaways about template parts in WordPress:
  • “Template parts” are incomplete pieces of WordPress PHP templates, pulled out into their own PHP files. Template files access them with a function called get_template_part().
  • The primary reason to create a template part in WordPress is to avoid repeating code: if multiple files use several identical lines of code, this code can be pulled into a template part, allowing it to be stored (and modified) in a single place.
  • get_template_part() can accept two arguments which, together, specify both a target template part file and a fallback file—much as the WordPress template hierarchy falls back to index.php. get_template_part() will also search the child theme (if one exists) for the targeted template part.

In WordPress, get_template_part() is a helpful way to avoid duplication and repetition within a WordPress theme. Use get_template_part() for any template code that you would otherwise end up copying-and-pasting. This chapter covers how WordPress’s get_template_part() function works, why get_template_part matters for WordPress themes, and how to use it in your own theme development.

What get_template_part() Is in WordPress

get_template_part() is a WordPress function that includes template “partials” wherever you need them. This allows you to centralize any block of code that is likely to be repeated into these “partials,” cutting down on duplication and making your template files more readable. Effective, it tells WordPress to load template parts, like the body of a post in different theme files (which are usually part of the template hierarchy).

Let’s take an example Loop in an index.php file, using get_template_part():

/* Environment: We're in index.php */

if ( have_posts() ) :
    while ( have_posts() ) : the_post();
        get_template_part( 'content' );
    endwhile;
endif;

And here’s our example content.php:

/* Environment: We're in content.php */

<article id="post-<?php the_ID(); ?>" <?php post_class(); ?>>
    <h2 >
	    <a href="<?php the_permalink(); ?>">
	    	<?php the_title(); ?>
	    </a>
	</h2>

    <?php the_excerpt(); ?>
</article>

In this example, WordPress will load up index.php, and it will run as if the contents of content.php were inside it. You can think of it as being WordPress loading in the “sub-template” completely in the line where get_template_part() was called. This lets us avoid rewriting (or maintaining) all the same code around the various files of our WordPress theme.

Breaking this one file into two has a number of advantages:

  1. Both index.php and content.php are now compact and readable.
  2. The two files now have distinct responsibilities: index.php contains mostly logic, and content.php contains mostly presentational HTML/PHP templating code.
  3. The major advantage: the code in content.php can be reused by other template files, like home.php, simply by having those files also call get_template_part( 'content' ). This cuts down on the overall bulkiness of the theme, and it prevents repetition: if you want to change something about content.php, you only change it once, and the changes propagate everywhere.
WordPress Get Template Part Filenames are Arbitrary, Can Be Variables

One thing to note from this example: content.php is an arbitrary name—you can name your template parts anything you want. get_template_part( 'anything' ); would work perfectly fine, as long as the theme (or its child or parent theme) contains a file called anything.php. That name, specifically, we don’t recommend. But it’s important to know as different themes you’ll

Using get_template_part() with a Second Parameter

You can use a second parameter on get_template_part(), which makes it even more powerful.

This second parameter is probably easiest to explain by example. We’ll assume that we’re using a child theme. The code, with a second parameter, is as follows:

<?php get_template_part( 'first', 'second' ); ?>

Based on this code, WordPress will look for the following files, in order:

  1. In the child theme: first-second.php
  2. In the parent theme: first-second.php
  3. In the child theme: first.php
  4. In the parent theme: first.php
Filenames and get_template_part() with Two Arguments

To make the pattern above explicit:

<?php get_template_part( 'firstargument', 'secondargument' ); ?>

Will look for a file named firstargument-secondargument.php—both arguments, combined and separated by a hyphen. If this file isn’t found, WordPress will fall back to simply firstargument.php. In both cases, it will look for these files first in the child theme (if one exists), then in the parent theme.

The Usefulness of get_template_part() with Two Arguments

As a real-world example: you may want to specify a content-page.php template part that works specifically for Pages; if this file is missing, WordPress simply falls back to content.php. This is very similar to how all templates fall back to index.php in the template hierarchy, eliminating the risk that WordPress will be unable to process a certain kind of content.

This method also tends to lead to helpful, descriptive template part names, as in Twenty Fifteen:

With get_template_part, passing variables to the second argument is also rather common. Passing variables to get_template_part is useful because it allow us to have things (like the WordPress post format) stored as a variable and then passed in to the function. Or we can simply have what could have been a variable declarion stand as a function-call inline, like this line from the Twenty Nineteen theme:

get_template_part( 'template-parts/post/content', get_post_format() );
WordPress Child Themes: Why get_template_part() is Better than PHP’s include() or require()

If you know PHP well, you might wonder: “Why not just use PHP’s include() or require() functions to pull in the template part files?” These functions will indeed work as designed; however, they’re not the “WordPress way” of doing it, and that has specific downsides.

First, the default PHP functions do not have the “two arguments with fallbacks” structure of get_template_part(), as covered above. This means that a file moving, or not having an expect fall back will just break. That’s bad.

The second, and more important reason is child themes. For a child theme to modify a template part file—for example, a child theme that creates its own version of content.php—require simply won’t work. It’s not “child theme aware” which is a really important thing for WordPress themes.

With get_template_part(), the child’s content.php can simply replace the parent’s—but since include() and require() pull in files in a “non-WordPress” way, the child theme must instead replace every theme file that uses these template parts, creating huge unnecessary bulk in the child theme.

So when your “parent theme” has used get_template_part take advantage. Just write the template part you need to override, and nothing more. The feature of get_template_part will help you. And, if you write your own theme, you should always use get_template_part() where possible. It’ll make everyone happier.

That’s All About WordPress Template Parts!

WordPress’s get_template_part() is a powerful and valuable part of WordPress theming. You’ll see it in most good themes you try to edit, so we hope you now know what it’s doing and why it’s valuable.

Summary Limerick

A template is whole when it starts,
But it’s often best broken in parts.
This cuts repetition
And helps with concision,
And shows off your WordPressing smarts.

Quiz Time! Do You Understand get_template_part?
  1. A template part is:
    1. A complete, but succinct, page template
    2. The section of a WordPress template that’s inside The Loop
    3. A section of a template file—generally likely to be repeated across multiple template files—broken out into its own PHP file
  2. Template parts are a good idea for all of these reasons except:
    1. They reduce repetition and code bulk inside a theme
    2. They make it easier to track down and debug PHP errors
    3. They allow a “search-and-fallback” template system, much like the WordPress template hierarchy
  3. get_template_part( 'content', 'page' ); will search for:
    1. content-page.php, falling back to page.php
    2. content-page.php, falling back to content.php
    3. content.php, falling back to page.php
Answers and Explanations
  1. C. A defeats the purpose of template parts. B could be true, but a template part can be made from any amount of code, either inside or outside of The Loop.
  2. B. A is the primary argument in favor of template parts, and C is a secondary benefit.
  3. B. WordPress will search for content-page.php, first in the child theme (if one exists) and then the parent theme, and then fall back to content.php, first in the child theme and then the parent theme. Remember that the two function arguments are combined, and separated by a hyphen, to make the template part’s filename.
Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

The pocket notebook, and capturing creative ideas →

Alex on his little notebook.

I carry around a little notebook for recording ideas, and – this sounds a bit odd but go with it – it’s totally changed the way I approach ideas, and being creative. Like most readers, I’m sure, I have lots of ideas! They come and go, and using the little notebook is a way of making sure they stay and then get put into practice. For my work this has led to moving forwards on a bunch of ideas which would have otherwise been forgotten. This is a fun post, and worth a read.

This post first appeared in MasterWP, a weekly newsletter for WordPress professionals.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

So, you want to remove the date from your WordPress post URLs? I get it. Those /2016/07/09/post-slug URLs that seemed pretty cool when you (or someone else) set it up get old. The primary reason: when you update that post, what should you do? Leave it’s URL looking old? Move it to the new one and worry it’ll break. These concerns are why we use the “Post name” option for WordPress permalinks here at WPShout and encourage most of our clients to do the same.

In this Quick Guide about WordPress, changing permalink structure will be our goal. The problem: while toggling the setting itself can work, will cause your WordPress site to present 404 errors at your old URLs. The trick we’ll cover in this video (and written tutorial about WordPress): URL rewrites with .htaccess files.

As always, we’ll start with this video. In this one I explain how I change permalink structure for WordPress posts, and make sure that I forward all the traffic to the old URLs to the new ones:

Changing WordPress Permalinks: Remove Date from Post URLs - YouTube

WordPress URL rewrite with htaccess, the Code

When I simply remove post dates from URLs, WordPress is confused. It knows my “new” permalink settings, but it immediately forgets the old one. So we have to help it, that’s where this URL rewrite in .htaccess rule comes in: it’ll make sure that WordPress never sees our old permalink structure. Here’s the code, which you’ll typically put in a file called .htaccess which will be at the root of your WordPress site’s file system:

## To change example.com/2019/01/01/post-slug to example.com/post-slug
<IfModule mod_rewrite.c>
RewriteRule ^([0-9]+)/([0-9]+)/([0-9]+)/(.*)$ /$4 [R=301,NC,L]
</IfModule>

The really important thing about this code: it requires that your WordPress server be running “Apache” not “Nginx,” and that your Apache configuration support .htaccess files for URL rewrites. I mention this because this is the only way to remove date from WordPress post URLs we’ll cover in this Quick Guide. But if you’re struggling, hopefully that gives you some helpful pointers on where to look next.

Step-by-Step Guide to Remove Date from WordPress Post URLs

So if you want to change your permalinks to remove post date in WordPress, here’re the steps we recommend you take:

  1. First, you’ll want to change the permalink settings. To do that, navigate to “Settings > Permalinks” in the left bar of the WordPress admin area.
  2. The rest of this tutorial assumes that you’ve chosen URLs like mysite.com/post-slug. If you do want that URL structure for WordPress, select “Post name” (the fifth option as I write this) on the Permalink Settings page. Press “Save Changes.”
  3. Now, to supper WordPress, we’ll do a URL rewrite with htaccess. As mentioned above (don’t worry if you didn’t use it) to change the change permalink structure for WordPress posts, we’ll need to find the .htaccess file. This is most easily done by first connecting to your web host via SFTP. If you’re new to that, here’s a guide.
  4. Once connected, find the .htaccess file at the root of your WordPress installation. Here’s where we’ll put the code to change our permalink structure for WordPress to remove the date.
  5. URL rewriting is doing by .htaccess for *most* WordPress sites. So we’ll open up that file, and paste in these lines:
    ## To change example.com/2019/01/01/post-slug to example.com/post-slug
    <IfModule mod_rewrite.c>
    RewriteRule ^([0-9]+)/([0-9]+)/([0-9]+)/(.*)$ /$4 [R=301,NC,L]
    </IfModule>
  6. Save and upload that file back to the server. With that, you should have successfully removed the date from your WordPress post URLs, without triggering a bunch of 404 errors.

Changing permalink structures in WordPress can be daunting, but hopefully we’ve guided you through

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Welcome to this rundown on return in PHP! This article continues our series explaining the basics of PHP for WordPress development.

Our discussion of PHP’s return builds on two topics we’ve covered in earlier articles:

  1. PHP functions. Functions are where return is useful, so you’ll want to understand the basics of what PHP functions are and what they do.
  2. PHP’s echo. echo is how PHP outputs things to the page, and it and return are flip sides of a coin—so, again, you should understand the basics of how it operates moving into our exploration of return.

Now: Here’s how return works in PHP, and why it’s super-powerful.

In PHP, return is How a Function “Gives Back” its Results

Let’s start by understanding why we need return in the first place.

PHP Usually echos to the Page Eventually, But It Does Lots More Too

PHP certainly isn’t echoing out to the page the whole time.

As we covered with echo, the final purpose of most PHP is to output markup into the HTML document that the user sees in her browser. For very simple uses of PHP, it really can be just an “HTML convenience tool,” to do things like give HTML elements sequential IDs.

However, looking at PHP that way risks making it sound way simpler than it is. In WordPress and most other PHP systems, a single line of outputted markup—“You are now logged in! Your last login was three weeks and two days ago.”—might reflect literally thousands of calculations across dozens of PHP files totaling megabytes of code.

In other words, PHP certainly isn’t echoing out to the page the whole time. In most PHP applications, data is being passed around and worked on extensively before it ever “exits through the front door” in the form of an echo statement.

Functions Need to Talk to Each Other

In our article introducing PHP functions, we made a few key points, which we’ll summarize here:

  1. PHP functions are defined, repeatable “bits of work.” Having these clear, separate “bits of work” is what keeps PHP code from mushing together into a repetitive, unworkable glue.
  2. It’s possible to give a PHP function data to work with, by passing that data into the function. For the technical details refer to the article, but the main point is that a function can be “given” data to work with, and that it will do so in whatever way the function itself is written to work.

This brings us to our next question: What should a PHP function do with the data it’s given, once it’s done working on it? To echo it directly to the page is one possibility—but definitely not the most common one.

return is how a function passes back its results—to whatever piece of code called it—for further use.

Far more often, you want to “hand back” the result. That is, you want to pass the worked-on data back to the rest of your PHP application, to be worked on further.

This is what return does. In PHP and many other programming languages, return is how a function passes back its results to whatever piece of code “called” (invoked) it, where it can further worked with and used.

Code Demo: How PHP Uses return to Pass Back a Function’s Results

Okay, enough fancy paragraphs. Let’s understand return by diving in and looking at a code example, which revolves around two functions:

  1. echo_text(), which echos (prints) text directly.
  2. return_text(), which doesn’t print anything, but returns its results for further use.

Here’s the demo:

<?php

function echo_text() {
	echo 'Kittens.';
}

echo_text(); // Will print "Kittens."

$var1 = echo_text(); // Bad code. Will print "Kittens." and won't set a value for $var1.

echo $var1; // Problem. $var1 was never set, because echo_text() echos instead of returning.

function return_text() {
	return 'Puppies.';
}

$var2 = return_text(); // $var2 now has value "Puppies."

echo $var2; // Will print "Puppies." since that's the value of $var2.

echo return_text(); // Will print "Puppies." Works by getting the returned value, and immediately echoing it.

return_text(); // Bad code, does nothing. return_text() runs and returns "Puppies." but the returned value isn't used for anything.

?>

Hopefully that example starts to illustrate how return works, and what makes it a complement to echo: rather than printing a function’s results out onto the page, return takes those results and gives them back to whatever operation it was that called the function—whether that operation was defining a variable, an echo statement, or anything else.

Code Demo: Using return to Pass Back Different Kinds of Data

Our return_text() function, above, is pretty silly: it always returns the same thing, the string “Puppies.” In reality, for it to be useful, return will almost always be returning dynamically calculated values, and these values can be of any PHP data type: string, ineger, array, object, and more. Let’s see a few examples in action:

<?php

function return_the_number_five() {
	return 5;
}

$var1 = 3 * return_the_number_five(); // $var1 now has value 15.

function multiply( $num1, $num2 ) {
	return $num1 * $num2;
}

$var2 = multiply( 3, 10 ); // $var2 now has value 30.

$var3 = multiply( 8, return_the_number_five() ); // $var3 now has value 40.
// This example demonstrates calling one function to get its return value, and passing that value in as an argument of another function: return_the_number_five() "becomes" its return value, 5, which is then passed into multiply().

function get_my_shopping_list() {
	return array( 'plums', 'toothpaste' );
}

$my_list = get_my_shopping_list(); // $my_list is now an array with values [ 'plums', 'toothpaste' ]
echo $list[0]; // Will print "plums"

function add_to_shopping_list( $list, $item ) {
	$list[] = $item; // This means "add $item to the end of array $list"
	return $list;
}

$my_bigger_list = add_to_shopping_list( get_my_shopping_list(), 'ice cream' );
// $my_bigger_list is now an array with values [ 'plums', 'toothpaste', 'ice cream' ]

$my_bigger_list = add_to_shopping_list( $my_bigger_list, 'shampoo' );
// $my_bigger_list is now an array with values [ 'plums', 'toothpaste', 'ice cream', 'shampoo' ]
// You can pass a variable into a function and have that function's return value change the variable
?>

If you’ve understand the examples above, you’ve got a good handle on return. The pattern is the same: you call a function, get its return value, and do something with it.

The way I think about return is that the function “becomes” its return value everywhere it’s called.

Thinking with my fuzzy human brain, the way I think about return is that the function “becomes” its return value everywhere it’s called. For example,return_the_number_five() above becomes 5 anytime it’s called—whether it’s called in the process of echoing something, defining a variable, or even as an argument for another function.

return and WordPress: Template Tag Naming

As in any PHP application, WordPress uses return absolutely all the time. So return is “relevant” to WordPress in the same way that breathing is “relevant” to baseball: it’s impossible to imagine the second without the first.

However, there is a particular part of WordPress’s codebase where, once you understand echo, return, and their “two sides of a coin”-type relationship, the whole thing lights up all at once. The topic is WordPress’s post template tags, and specifically their the_() and get_the_() function naming convention, and it’s one of the super-satisfying areas in which WordPress’s function library mirrors the structure of PHP itself.

Have you ever wondered the difference between the_ID() and get_the_ID()? It’s as simple as this:

<?php

// WordPress's get_the_ID() function
function get_the_ID() {
	$post = get_post(); // Get the current post
	return ! empty( $post ) ? $post->ID : false; // Return the current post's ID, or false if none
}

// WordPress's the_ID() function
function the_ID() {
	echo get_the_ID(); // Call get_the_ID() and echo the returned result - simple as that
}

?>

So the difference between the_() and get_the_() is simply the difference between echo and return. This holds true for functions like the_content()/get_the_content(), the_title()/get_the_title(), and so on—and it simply boils down to echoing results or returning them for further use.

For more on these template tag functions, have a look at our full article on the topic:

WordPress Template Tags: How They Show Post Content & More

return to Learning PHP

The echo and return dichotomy, and the ways those two language constructs work together, form a bedrock piece of understanding that PHP knowledge is built on. This dichotomy also ties nicely into a helpful naming convention within WordPress’s template tags, which is one of the cleanest and easiest-to-use pieces of the WordPress codebase.

More broadly, “return values”—the way that functions give stuff back—are a concept that virtually no modern programming language would make any sense without. They’re very much at the heart of programming itself.

In other words, the time you’ve spent learning this should earn you a hefty—well, return.

Thanks for reading! We’d love to hear any questions or thoughts, either in the comments below or in our Facebook group.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Sarah Drasner on Learning to Learn →

This is one of those articles that I’m linking 50% for its substance (which I regard as good but too brief) and 50% for covering and important topic. Specifically, how to manage and think about self-education. A lot, probably most, web developers I know and readers of WPShout I’ve talked to are self-educated in the web development field. Maybe you got college degrees, but few of those were “computer science.” Even if you did, Computer Science Degree often covers very little about web development. So most of us are just learning as we go.

What I really valued in the piece was Sarah’s transparency about the fact that she’s still learning (even while writing in a vaunted space like CSS-Tricks), and that she lays out specifically how she thinks about doing it:

If there’s an API I’m trying to learn, I’ll go to the main documentation page (if there is one), and list each of the things I’m trying to learn. Then I’ll divide the sections into what I think are manageable chunks, and spread the sections over my schedule, usually shooting for about a half hour a day. I do this with the understanding that some days I won’t find the time, and others, I’ll dig in for longer. Typically I aim for at least 2.5 hours of learning a week, because that pace seems reasonable to me.

This is so concrete, and quite different from the way I’ve ever thought about learning. (I’m much more “learn as needing by doing projects.”) But her success speaks for itself. It’s not easy to manage the continuous learning that computer-professionals require. But even you dismiss the specific schedule, Sarah covers also some great things about how to think about learning–how to practice, cognitive load theory–that’ll entertain and inform you as well.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Identifying the Stakeholders of WordPress →

The WordPress Governance Project working out who we are.

The WordPress Governance Project is trying to explore and influence the governance of WordPress and the open web, and it’s issued some new research. This identifies the stakeholders involved in the WordPress project, and does so with the aim of better understanding the needs and desires of those stakeholders.

The hope is that: “Understanding the nuances of each stakeholder and their preferences, actions or relationships can better articulate the needs for governance in the WordPress project.”

Some of what the research uncovers will be familiar, but it’s worth a read as it’s a great example of exploring “common knowledge” and working out what’s actually driving it. It’s also a great example of really nicely done project management: “Deep understanding of a target audience is fundamental to creating exceptional products”.

This post first appeared in MasterWP, a weekly newsletter for WordPress professionals.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

How to Build a Google Data Studio Dashboard →

From an internet marketing firm called Data Driven Labs comes this outstanding introduction to Google Data Studio, a Google product I’d like to know a lot more about.

I’ve just started trying to use Google Data Studio to pull together information on WPShout that I’m currently accessing through Analytics and Search Console separately. Like seemingly all Google interfaces designed for technical people, Google Data Studio is super confusing, and without the Data Driven Labs tutorial—which at least gives you sequential steps to start to follow to see stuff on the screen—I’d be staring at empty grid lines right now. Much appreciated!

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Sucuri’s 2018 Hacked Website Report →

When putting together WordPress Security with Confidence, one of the best sources about actual WordPress site comprises was the Sucuri hacked website report. While a lot of WordPress security content (including my own) is informed by a small number of real and important first-hand exposures to WordPress security issues, in a given year Sucuri has literally thousands.

And while there are great reasons that they may choose not to share any data (competitive advantage, the real human time such a report takes to release for public analysis), I’m grateful to see that they’re keeping up the trend of sharing some of their data with the rest of us.

I also love that they start with the executive summary. I’ll encourage you to click through, but here are a few as teasers:

  • There was a notable decrease in the number of updated Joomla! installations at the point of infection.
  • The blacklist telemetry showed a 6% reduction in sites being blacklisted. Blacklist authorities only detected 11% of the sites we cleaned as malicious in 2018, which speaks to the importance of proper scanning and detection controls.
  • Our malware families analysis showed that SEO spam increased to 51.3% (up from 44% in 2017).
Read Full Article

Read for later

Articles marked as Favorite are saved for later viewing.
close
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Separate tags by commas
To access this feature, please upgrade your account.
Start your free month
Free Preview