Hello, friends and blog guests! Today I’ll tell you using PHP and MySQL. And we will also talk about commenting systems for the site and we will choose the best one for your site from the ones I offer.

Question one: by using PHP and MySQL?

To do this, you and I first need to create a table in the database of your site, which will be called - comments. This created table will store comments in fields with the following designations:

id is a unique identifier.
page_id— this field will store the identifier of the site page on which this comment is located.
name- this is the name of the commentator who left this comment.
text_comment— accordingly, this is the text of the current comment.

The next step, after creating a table for comments in the database, we need to implement special code for our future comments on the site. This code on the site will allow our commentators to add their comments to our articles. Here is the code:

Your name:

Your comment:

It's simple HTML form comments for the site. You place it on your website in a place where it is convenient for leaving a comment on a post - naturally, under the post itself.

query("INSERT INTO `comments` (`name`, `page_id`, `text_comment`) VALUES ("$name", "$page_id", "$text_comment")");// Add a comment to the table header(" Location: ".$_SERVER["HTTP_REFERER"]);// Do we redirect back?>

The last step in creating a comment form for a site in PHP and MySQL is to display our comments on the site page. Here's the code for this:

query("SELECT * FROM `comments` WHERE `page_id`="$page_id""); //Fetch all comments for this page while ($row = $result_set->fetch_assoc()) ( print_r($row); //Output comments echo "
"; } ?>

That's all! Our simple comment form for the site has been created and can work on the site.

But this is certainly not for a beginner who will not bother with all this HTML, PHP and MySQL code. Nor will he learn how to create a database. He needs everything at once, quickly and without headaches. I'm right? Of course you're right!

Then let's move on to the next section of my material and find out everything about ready-made comment systems for the site and choose the most convenient, functional and acceptable for your site...

Comment systems for the site. Which one to choose?

How to make comments on the site- this is an important question because comments on a site play an important role not only for communication between the site owner and the visitor, but comments are also important for SEO promotion and promotion.

With the help of comments on the site, the site’s position in search results increases, behavioral factors improve, traffic to the site increases, and, consequently, your earnings increase. You see how important comments are for the site!

So let's take a look how to make comments on the site and which one commenting system choose the most best option?

In general, comments on websites are displayed in many ways. These are special plugins for wordpress engines and comments from social networks all sorts of things, such as In contact with, Facebook, Disqus. There are also independent services that offer their own comment systems for the site, for example.

I’ll now give you one tablet that will immediately put everything in its place and no questions will arise about choosing a comment system for the site:

Here you can clearly and clearly see which comment system is the best and several presented ones, which are most often used by webmasters on their resources. I think that explanations are unnecessary here and the choice is yours!

Reading time: 55 min

Good day to all.

Now the time has come for the long-awaited material about micro markup.

I’ll say right away that this article will be quite difficult to understand at first, especially for beginners, since there are many options for micro markup and it’s difficult to get it all in your head at once. But I will try to describe the overall picture and at the same time focus on the most important and common things.

The material is quite voluminous, but I hope that it will help you create micro-markup on the site.

Lately I've noticed that a lot of people are obsessed with microdata. This happened after various SEO bloggers began to vigorously discuss it. But let's figure out why it is used at all and whether it is necessary to pay so much attention to it. Is the game worth the candle?

What is micro markup and why is it needed?

If you hear micro-markup or semantic markup of a page (site), then know that this means marking up a page using additional attributes (tags), which give search engines an idea about individual elements of the page, indicating their content.

You must understand that a regular page is already marked up, but the usual generally accepted tags and attributes are used. This is quite enough for search engines and many sites still exist this way and are thriving quite successfully.

But, if we want to help search engines understand our site, point them to important areas of the page, understand its structure, pointing out the content of those areas that first need to be paid attention to, then it is necessary to implement micro-markup, that is, add certain tags and attributes that will indicate everything.

By doing this, we will not only help search engines, but also our site, since micro markup is used not only to understand the site structure and content, but also to build search results, forming functional and attractive snippets, which affects the click-through rate (CTR) of the site in issuance. And this is an increase in overall site traffic.

You can see a striking example of such snippets below.

On this image you can see, which complements and makes it more noticeable among the gray masses of other sites in the search results. I also used arrows to highlight the breadcrumb trail, which shows a clear structured path to the material on the site, rather than a simple unclear URL.

This navigation chain is quite simple. All you have to do is install them on the site.

Here is another option for rich snippets.

The same option allows the visitor to immediately understand what the site is about and what it can give him. If the snippet is constructed correctly in this case, then the user can immediately take the action you need, and as we know, each site must perform its own tasks (subscription, purchase, etc.).

Agree that such a snippet will be more noticeable in the search results than a regular page description, since it has much more larger size. Yes, and it looks more solid.

Let's now answer a question that may concern those who think that micro markup helps in increasing positions and is one of the ranking factors.

Does micro markup affect rankings? Should we expect an increase in positions after its implementation?

In order not to write our reasoning, let's turn to the help of the Yandex search engine. So, what does Yandex itself tell us about this? I quote:

Will my site rank better if I use markup?

Answer: Markup can make your site more visible in Yandex Search and thus attract more visitors belonging to target audience. Yandex is interested in users solving their problems using Search. One of the Search quality metrics is called “user happiness.” Websites that increase “happiness” rank higher.

We can conclude that markup does not directly affect positions, but only indirectly, since we can make a more attractive snippet, which in itself will bring more visitors to the resource. Then it's a matter of technique. More visitors means more accumulated good indicators about the pages (if the content is high-quality) and the positions will gradually increase.

It is also worth noting that by helping search engines understand the nature of the content, its type (information, meeting, product, etc.), we make the content more relevant search query and he should occupy higher positions. Maybe not directly, but indirectly - that’s for sure. Yandex confirmed this to us (see above).

So, let's make a short checklist of the benefits of having micro markup on the site. These are those points that indirectly or directly indicate the quality of the site, increase its position and help search engines.

1. Firstly, we can conclude that the trust in the site from search engines increases, since we point the search robot to the main elements of the site, without being afraid that something is wrong with us and without trying to hide something from the search robot . As a result, it is logical for search engines to think that we are helping them and revealing to them the “soul of the site,” which will certainly affect the quality of the site’s indexing, and ultimately its positions;
2. Secondly, with the proper settings, we can highlight our snippet in the search results, which will lead to an instant increase in traffic to the resource pages without changing positions. Ultimately, increased traffic will lead to increased individual pages in the search results and the site as a whole;
3. Thirdly, we increase the behavioral factor - CTR in search results (click-through rate). This point is very closely related to the previous one. Since more people click on our website, it means we have more accurately helped the visitor understand that our page is of higher quality than on other sites. This means that the site needs to be slightly raised in search results.

So, I think the answer to the question has been given.

Is markup necessary at all? - Yes, I need it.

Of course, if there is a choice between the painful implementation of markup on the site and working on other aspects, then, of course, you should not focus only on semantic markup. It’s better to work on content, which is much more important than some technical detail among hundreds or thousands of other things. Moreover, now you can highlight your snippet in the search results without introducing markup into the template, but only by installing , which already provides rating markup.

Once we know the main benefits, we can move on to consider the main types of semantic markup.

Main types of micro markup

Everything is quite complicated here. First, you need to understand that there are micro markup dictionaries and their syntaxes.

A dictionary can be understood as a micro-markup language that includes a set of classes and properties that indicate the essence of the page content. In each dictionary, each element on the site is identified using different tags. For example, in the Schema.org dictionary, the name of the document is indicated using the "name" tag, but microformats use a CSS class inside the block of the element that is worth marking up ( Chamomile, where fn org is the title tag in this case).

Each dictionary and syntax has its own tags and attributes, which makes micro markup formats a so-called vinaigrette. It's really hard to figure everything out.

Syntax is understood as the way of using a particular language (dictionary) of semantic markup. The syntax determines which tags will be used to indicate the essence of objects and their properties on the page.

From the previous definition about syntax, the concept of essence was introduced. What does this mean applicable to the issue at hand?

Essence - simply put, this is the type of information (unit of content, information) that we point to search engines. For example, we need to point to announcements on the main page of the blog, that is, highlight the essence of this area with some tag, defining it as an announcement area. The same needs to be done with the post page, where you need to indicate the essence of the area where the content (article) is located, that is, highlight the text as a content area.

For almost every element of the page, you can define the essence, that is, indicate what it is: content or rating, or comments in general. Thus, entities can be specified on such pages (I’ll take a simple blog template like mine as an example):

• Home - list of announcements;
• Posts page - comments, content, rating (if available), breadcrumbs;
• A regular static page - content, comments (if any).

In addition, on each type of page you can designate the same element - site header, footer (footer), sidebar (side column), main menu.

Each entity has its own properties, for example:

• Content area on the posts page - article title, article text, description, article author name, publication date, category, images, videos and others;
• The area for the list of announcements on the main page, sections and archives is the same;
• Comment area - commentator name, date, comment text;
• The content area on a regular static page is basically the same as in posts;
• Site header area - title, description;
• Rating area on pages - maximum rating, current rating, number of ratings.
• Footer area (site footer) - year of copyright;
• Sidebar area (side column) - name of widgets;
• Main menu area - links.

There are other areas with properties, but I will not consider them, since in each markup dictionary there are several dozen of them, and in the markup from schema.org their number is generally in the hundreds.

We will look at what tags and attributes to use to indicate the entities and properties of each of them in the practical part of this article.

Now let's move on to the main idea of ​​the paragraph and consider the main formats of semantic markup. A short list of basic vocabularies and syntaxes can be seen in the mind map below.

We will not consider all dictionaries and syntaxes, as this is pointless. You won't need them. Let's discuss only briefly the main markup formats:

• Schema.org;
• Open Graph;
• Microformats.

We will touch on some of the rest quite a bit.

The last step is worth noting another dictionary, namely Data Vocabulary, which was developed by Google and now its development has been suspended. All attention shifted to Schema.org. We can say that all the properties and entities that were in this markup language became prototypes for markup from schema.org.

As far as I understand, the Data Vocabulary dictionary can work with syntaxes: microdata and the RDF language, which can be very clearly seen in the Google help on breadcrumb micro-markup material. There are 2 markup options:

1. Data Vocabulary tagging with microdata;
2. Data Vocabulary Markup with RDFa.

I'll get ahead of myself a little. In the first image you can see that microdata from Schema.org is used along with the Data Vocabulary. The fact is that breadcrumbs with schema are not supported yet. Therefore, a combined option is used.

Which markup format is best to use?

I think you already know the answer to this question, since in the description of each type of markup I gave an undeniable argument that search engines They themselves recommend the Schema.org markup dictionary. This is exactly what you need to use. But there can be a lot of options for implementing this micro markup, both from plugins and the introduction of entities and properties into design templates.

The last option is the most optimal, since this is a one-time job and micro markup will be on absolutely every page. All search engines will see it, since it will be built into the template. But beginners may have problems implementing it, since they need to understand the code of their template at least at a minimum basic level and see what tag displays the title of the article, where the code is for displaying the text, and so on. All these moments will need to be wrapped with micro markup tags.

This point also raises the issue of combining different dictionaries on one site. This is acceptable and in some cases it cannot be avoided. This is clearly seen in the example of breadcrumb markup, when a variant of the Data Vocabulary markup and microdata markup from Schema.org are combined. There's nothing wrong with that. Yandex itself speaks about this.

It's up to your discretion. If you find it easier to use microformats, then go for it. I personally will show the whole process on Schema.org micro markup, since I myself have implemented it and everything works with a bang without a single error.

How to check the presence of markup on a website

Our task at this stage is to find out whether our template has some kind of markup format. This is quite possible, because most of the templates used are translated English-language themes that already contain some kind of semantic markup format. As a rule, this is markup in microformats, which is of no use to us at all. It is better if it is not there initially, as this will save us from the headache when it is removed.

To check the presence of markup, you can use both the micro markup validator from Yandex and the Google structured data verification tool. I prefer and strongly recommend that you use the Yandex validator, as it is much simpler.

After going to the Yandex validator, we enter the page address and click “Check”.

If it says “Micro markup not detected,” it means there is no third-party markup in the template. This is very good, since you don’t need to waste effort on removing it. But be careful, because on one type of page there may be no markup, but on another it will be present (for example, on an article page).

So, I’m analyzing the post page and it turns out that the template comments are marked with microformats (vcard is present). This is evidenced by different codes in the scan results.

We don't need microformats, so we should remove them. It may happen that your template is marked up in other markup formats. Then they should also be removed. And it is possible that markup from Schema.org will be immediately implemented. This also happens, but very rarely, since there are practically no worthwhile templates available for free. But bad ones are a dime a dozen.

Now let's look at the process of removing third-party markup.

Removing third-party markup

Since in my case it turned out to be third-party markup using microformats, I will use its example to show this process. If you have some other markup, then the principle of deleting it will be similar.

It all comes down to removing the tags and their attributes from the markup that you have. The only difference between microformats and other types of micro markup will be that all types except microformats add new tags and attributes. Microformats do not add anything but are written inside a specific class attribute html element template (for example, the title of an article), as I wrote in the paragraph about the main types.

By the way, in point No. 6 of this article I give the comment markup code that needs to be inserted into the template function file functions.php. This code should cure these errors from third-party microformat markup. Therefore, if you have this problem, I first recommend checking that code on your template. He should help. This will save you the unnecessary work of manual disposal. If nothing works out, then we do everything by hand, as I describe below.

Now let's move on to the process itself. So, earlier it became clear that I had extra markup from microformats. When checking in the validator, we were given the vcard tag, which creates errors.

Now we need to open the folder with the template to see all its files and then we turn to those files that are responsible for displaying those elements where the microformats are located. How to do this, see the list below:

I hope I explained it quite simply. Although, a beginner may have more confusion in his head.

This is how this piece of code with vcard originally looked in my template file.

After the change it became like this.

I also made changes to the styles.

Now there are no microformats and the design has been preserved in its original state.

So, when we have removed the standard markup (if it was present), we can embed new one from Schema.org. TO this process we get started.

Implementing micro markup Schema.org

Let's start with a little explanation and theory, since you always need to prepare before practice.

First, it’s worth figuring out what files we need to point to the necessary entities and their properties. Now I’m talking about files for the WordPress engine. I won’t say anything about other engines, since I don’t work with them. The marking principle remains the same. You just need to determine the files where the required areas for marking are located.

• Single.php file (record file): entity - content area (article), properties - publication date, author, category, article title, images;
• Functions.php file (in my case - comment code markup): entity - comment, properties - comment text, date and name of the commentator;
• Files with a list of announcements index.php, category.php, archive.php (main, categories and archives, respectively): entity - list of announcements, properties - publication date, author, category, article title;
• File page.php (regular static page - optional): entity - content area, properties - text title and, if available, date, author and others;
• In the header.php file, also mark the header - the entity will be the header, and the properties will be the site title + description;
• File sidebar.php (side column): entity - the entire sidebar, property - the title of each widget;
• File footer.php (site footer): entity - the entire footer, property - copyright date + site name (I did not mark up the name);
• File header.php ( top part resource): entity - main navigation menu, property - links + their anchors.

Now about the tags and attributes that correspond to each type of entity and their corresponding properties. First about the entities.

/***List of announcements***/ itemscope itemtype="http://schema.org/BlogPosting" /***Post page content***/ itemscope itemtype="http://schema.org/Article" / ***Comments***/ itemprop="comment" itemscope itemtype="http://schema.org/Comment" /***Regular static page***/ itemscope itemtype="http://schema.org/ Article" /***Sidebar (sidebar)***/ itemscope itemtype="http://schema.org/WPSideBar"> /***Footer (site footer)***/ itemscope itemtype="http:/ /schema.org/WPFooter"> /***Site Navigation (main menu)***/ itemscope itemtype="http://schema.org/SiteNavigationElement"> /***Images***/ itemscope="" itemtype="https://schema.org/ImageObject" /***Permanent link to the page***/ itemscope itemprop="mainEntityOfPage" itemType="https://schema.org/WebPage" /***Organization* **/ itemscope itemtype="https://schema.org/Organization" /***Address***/ itemscope itemtype="http://schema.org/PostalAddress"

Now the property tags.

• Page (text) title - itemprop="headline"
• Entry text - itemprop="articleBody" (can also be used for description if it is formed as part of the full text)
• Date of publication - itemprop="datePublished"
• Author - itemprop="author"
• Article category - itemprop="articleSection"
• Image - itemprop="image"
• Comment text - itemprop="text"
• Commentator name - itemprop="creator"
• Comment date - itemprop="datePublished"
• Link (applies to main menu and image) - itemprop="url"
• Copyright year in the footer - itemprop="copyrightYear"
• Date the page was last modified - itemprop="dateModified"
• Address - itemprop="address"
• Street - itemprop="streetAddress"
• Index - itemprop="postalCode"
• Address location - itemprop="addressLocality"
• Telephone - itemprop="telephone"
• Image length - itemprop="width"
• Image width - itemprop="height"
• Logo - itemprop="logo"

These are the main properties that we will now use.

Further steps to markup the template are quite simple.

Each area that needs to define an entity and property using the tags provided above is wrapped in some kind of common tag. This could be a div block tag, an article tag, a span tag, an H1 header, and others. To make it easier to understand, the title is almost always wrapped in an H1 tag, which is how it should be. There will be 2 tags: opening and closing. And so with every element of the site, and not just with the headers.

The idea is that each required element will need to be given an entity tag (specify the content type: article or comment, or list of announcements, etc.) and properties inside its opening tag.

Now practice. For example, there is a single post (article) file single.php. Let's start with its marking.

Micro markup of a post (article)

Let's start by defining the entity. The template has a common tag that wraps the entire content area of ​​the post (both the text of the article and the title and comments) and it is different for everyone. Some people might have it div block. I have this article. Naturally, this tag opens at the very beginning, where all the content begins, and ends somewhere when the content ends.

And it is at the very beginning, inside the opening article tag, that I need to insert the entity tag of the content area on the post page (I gave the codes a little higher). I’ll give you an image (clickable) of the final markup of the single.php recording file, and then I’ll explain what happened and what happened in the end, if it’s not clear to anyone. The image is large, but clickable, so you can click on it and view it in a larger size, or open it in a new tab and view it in full size.

Initially, the entire content area of ​​the post is opened using the article tag. It was like this:

And it became like this:

As you can see, the post entity tag is included inside the opening article tag. Now the search robot will understand that this is an area that contains content. Will perceive this area as an object. It is very important.

By the way. Many people set article ratings without a plugin, and after checking the page in a Yandex or Google validator, they are told that the object of the review is not specified. This is due to the fact that the rating is posted on its own. You need to place it inside this area, which in turn must be defined by a markup tag as the content area (or review object). Then the rating will belong to the object, that is, the article. After this there will be no errors.

Let's get back to the process. First, we placed the essence of the object (we wrapped the entire main area with a common tag), and then we marked its properties, that is, secondary data: date of publication, author, body of the article (the text itself), information about the publisher (address, organization, logo), date last page change, home page address, and so on. Everything is exactly the same - inside each opening tag of the required element we indicate the corresponding parameters. Below I provide an explanation of what happened before the changes were made and what happened after.

Initially, we copy 2 lines of code immediately after the opening tag that wraps the entire content area. For me this is an article tag with an entity inside it that was placed earlier in the text.

"/>

• The 1st line is responsible for outputting a line that points to the page address and says that this particular page is the main one.
• 2nd line - date of last modification of the page.

Then, in the next line, we give information about the publisher, i.e. about who publishes the materials. This includes several entities at once (Organization - the address inside it, the image - the logo). I give you the code, you just replace the hints in it with your data. Whether you put real ones or not is up to you, but if Google still does this in order to improve the results and show your data so that your credibility increases, then I would indicate the real ones. In general, this is everyone's business. Here's the code.

Street name index country, region, city telephone

If you notice, in the above codes there is a display:none style tag, which says that this data does not need to be displayed on the page, but only in the source code, so that the search engine can see it. Actually this is what I need. This tag is located on lines 2 and 9 and hides the display of the logo and address. If you want to display, then remove these styles. In the future, I will do this, when I radically redesign the blog, I will design it into a compact, beautiful blog that will fit well into the design and provide information about me.

Regarding the logo, many simply do not have one. I suggest doing the following - either create a small image and write on it the name of the site with the address (the simplest logo option) or upload your photo (the laziest option). I have a logo, so I registered it.

So now we mark up the following information. It will be easier here. You just need to find all the other necessary codes that display this or that information (title, category, publication date, author), and insert the necessary schema.org markup property tags inside their opening tags in which they are enclosed.

Post title. Was:

Publication date. Was:

Konstantin Khmelev

Konstantin Khmelev

".$current_category_name."

".$current_category_name."

Article text. Was:

here is third party code

here is third party code

You should do almost the same thing yourself. The only differences will be in the tags, inside which you need to place the entity and property tags. Their order may also be different. Or it may be that something will not be there at all, for example, there will be no publication date or link to the category. Then you will have to add this data to the template.

In the penultimate paragraph of the article, I will give you codes that you can use if you are suddenly missing something.

So, now we must check our page in Yandex and Google validators.

In Google's validator it will be almost the same. There should be no errors in this data. The only nuance concerns the micro-tagging of images, which is what we are moving on to.

You can mark up each image manually, wrapping it in the essence of the images and specifying the necessary properties, but this is quite inconvenient when there are several dozen images in each post. Let's use the following code.

Function micro_images_captions ($a , $attr, $content = null)( extract(shortcode_atts(array("id" => "", "align" => "alignnone", "width" => "", "caption" = > ""), $attr)); if (1 > (int) $width || empty($caption)) return $content; $caption = html_entity_decode($caption); if ($id) $id = "id ="" . esc_attr($id) . "" "; return "

" . do_shortcode($content) . "

" . $caption . "

";) function micro_image($content) ( $ar_mk = "! !si"; $br_mk = " "; $content = preg_replace($ar_mk, $br_mk, $content); return $content; ) add_filter("the_content", "micro_image"); add_filter("img_caption_shortcode", "micro_images_captions", 10, 3);

Now you don't need to add an image markup tag to every article. We go to the validator, check the page with at least one picture, and see the next picture.

There shouldn't be any errors. Everything is clear. Each image should be wrapped with markup, just like in the screenshot above.

Micro markup of the main page

Here you need to wrap the code that displays the list of announcements with the announcement list entity tag. This is done exactly the same way. Inside the general tag that wraps all the code in the template, we place the desired tag (the essence of the list of blog posts is blogposting, or you can do it similarly to the post page -article). See the image (clickable).

As you can see, my list of announcements is displayed using the li list tag, that is, each announcement is enclosed in it. Inside the list is almost the same as inside the entry itself - there are dates, the name of the author, the name of the sections, the address, the logo, the publisher, and so on. You can clearly see this on the blog pages. The structure is similar, only the text of the article is not complete. In general, the markup is exactly the same as for the post page, with the exception of the blogposting announcement entity tag.

It is also necessary to use a slightly different image markup code for the announcements page, since it displays not just pictures, but thumbnails. Micro-marking of thumbnails will be carried out using almost similar code. If previously they had to be marked by hand, now there is no point in doing so. Here is the code (we also place it in the functions.php file).

Function micro_thumbnail($content) ( $ar = "!!si"; $br = ""; $content = preg_replace($ar, $br, $content); return $content; ) add_filter("post_thumbnail_html", "micro_thumbnail ");

We contact the validator and check home page. I showed you only 2 announcements, because... the full screen will be very large.

There will be as many such blogposting entries as there are announcements on this page. If you used article instead of blogposting, then you will have several articles depending on the number of announcements.

Since the main page is similar in structure to the pages of sections and archives, their micro markup is identical. Lists of announcements are displayed on all types of pages.

So, all that remains is to parse the comment markup, which is a rather complicated process for a beginner. There are also regular static pages left. The principle of their markup is similar to records, so I won’t show it.

So, comments. Let's simplify the task to inserting one code into the functions.php file and modifying the function that displays comments on the site pages. First, take the following code and place it inside the functions.php file at the very beginning, right before the opening tag< ?php. Если будет выдавать ошибку, можно попробовать его разместить после закрывающего тега?>at the very end of the file.

There is also a placement option when you need to remove the opening of the php code in this code at the very beginning (remove< ?php) и в самом конце его закрытие (удалить?>). Then you need to place the code not before or after the opening (closing) php tag, but inside these tags next to all other functions. Sometimes I encountered a problem when this particular placement option works.

The code does not work on all templates!

< id="comment-">

%s:

"), get_comment_author_link()); ?>comment_approved) : ?>

$add_below, "depth" => $depth, "max_depth" => $args["max_depth"]))); ?>

$add_below, "depth" => $depth, "max_depth" => $args["max_depth"]))); ?>