Как правилно да внедрите CRM система: алгоритъм на действия и често срещани грешки. Проста система за коментиране, използваща AJAX Лошо обучение на персонала

В този урок ще говоря за това как се правят коментари в HTML, CSS, PHP. Коментарите са текст, който не се вижда на уеб страницата. Те се използват за различни видове обяснения, напомняния и описания за уеб администратори, което ви позволява да структурирате документа. Коментарите са незаменими при отстраняване на грешки в код; те ви позволяват бързо да навигирате в маркировката на уеб страница и да намерите желания блок. Коментарите често се използват за отстраняване на грешки в HTML кода. Например, можете временно да коментирате конкретен блоккод, така че да не се изпълнява и ако е необходимо, лесно се възстановява.

В HTML коментарите се формират с помощта на знаците: . Следователно всеки текст между тези знаци е коментар. Да разгледаме един пример:

Пример за коментари в HTML

Коментарите в CSS се създават с помощта на знаците: /* и */. За да създадете коментар, просто трябва да поставите кода на уеб страницата между тези знаци:

Коментарите в PHP могат да бъдат едноредови или многоредови:

1) Едноредовите коментари в PHP се създават с помощта на знаците: //. Просто поставете този знак пред реда и той ще бъде коментиран.Тази опция се използва в случай, че коментарът се състои само от един ред.

2) За реализиране на многоредови коментари се използват следните символи: /* и */. Тази опция е полезна, ако коментарът обхваща няколко реда.

Така се научихме да правим

Днес много популярни сайтове са не само източник на информация, но и място, където тази информация може да се обсъжда с други потребители; сайтовете често се превръщат в центрове, около които се формира общност.

Сега потребителите идват при вас не само за да прочетат някаква новина или статия, но и за да я обсъдят.

Характерното е, че читателят можеше да научи самата новина на друго място, но общността от интересни хора, възможността да се изкажат и да чуят мнението им - това ще доведе до факта, че той ще посети вашия сайт и отидете на страницата с новината, която той вече знае.

Само преди десет години центровете, около които кипеше животът, бяха форумите. В днешно време обаче това вече не е толкова удобно и популярно; сега повечето популярни сайтове работят във формат на блог, а потребителската комуникация се осъществява в коментари.

Така коментарите са факторът, който отличава обикновените сайтове от сайтовете, които са наистина успешни в своята област. Това се отнася за новинарски сайтове, блогове, общности по интереси, понякога дори онлайн магазини и различни специализирани сайтове.

Също така е важно да запомните, че коментарите са източник на обратна връзка от читателите, което ви позволява да разберете какво точно им харесва и на какво реагират читателите. И колкото по-добър и интересен е вашият сайт за посетителите, толкова по-често те се връщат при вас и го препоръчват.

Освен това обратната връзка винаги е добра мотивация за самите автори и администратори, което почти мигновено ви позволява да почувствате, че хората се интересуват от това, което правите и вашия сайт. Обикновен броячНяма да получите такъв тип посетители.

И така, какви трябва да бъдат „правилните“ коментари на един модерен уебсайт?

• Просто и разбираемо за читателите.
• Удобен и функционален за администратори.

Какви опции има уеб администраторът в момента?

Има само един плюс - има доста голяма вероятност потребителят вече да е влязъл в социалната мрежа и следователно няма да се налага да се регистрира.

Рускоезичните аналози често са напълно платени и не могат да се похвалят с атрактивен дизайн.

Единственото изключение тук е системата SV Kament (svkament.ru), която е напълно безплатна и обединява функционалността на различни западни системи за коментиране, но в същото време е фокусирана върху рускоезичния сегмент.

Нека да разгледаме набързо какво бихме искали да видим в нашата система за коментиране.

Дървовидни коментари с възможност за свиване на отделни дискусионни нишки. Те са много полезни при навигирането в дискусията, когато има много коментари.

Социалното влизане значително опростява регистрацията и в резултат на това увеличава броя на коментарите. Западни проучвания показват, че използването на социално влизане понякога увеличава конверсията с повече от 60%.

Оценка на коментарите - първо, помага да се откроят най-интересните и заслужаващи внимание коментари, което е изключително удобно за читателите, и второ, насърчава потребителите да пишат интересни съобщения.

Работа в реално време - колкото по-удобно и по-бързо работи системата, толкова повече хора я използват и толкова по-често пишат коментари.

Известия по имейл – колко често губим потенциални коментари само защото потребителят не знае, че някой е отговорил на предишното му съобщение.

• Управление директно на сайта.

• Информация за потребителя.

• Един контролен панел за коментари за целия сайт.
• Възможност за назначаване на модератори.
• Лесен за монтаж.

Системата SV Kament има и редица интересни функции.

• Социални излъчвания - позволяват ви да „върнете“ комуникацията към вашия уебсайт от социалните мрежи. Ако имате група VKontakte, в която публикувате съобщения за нови статии на сайта, тогава често част от обсъждането на статиите остава в коментарите към самата публикация и би било чудесно да излъчите тези коментари обратно на вашия сайт.

• Потребителски рейтинг и статус - позволява ви да подчертаете най-активните и популярни посетители, като по този начин стимулирате вашите потребители да посещават по-често, да общуват повече и да пишат интересни съобщения на други хора.

Има доста често срещана практика да се поставят няколко системи за коментиране наведнъж, например отделна джаджа VKontakte, отделна Facebook и отделна за всички останали.

Според мен това е един от най-лошите решения, обаче е важно да се разбере какви точно цели се преследват.

Ако просто трябва да съберете потребителски отзиви, тогава този метод има право на живот, въпреки че обикновена книга за гости или дори имейл адрес може да са достатъчни за това.

Ако целта ни е да създадем общност и да стимулираме комуникацията между потребителите, то този подход е изключително вреден, защото разделяйки коментарите, ние разделяме самата комуникация, така че вместо един диалог, получаваме куп несвързани съобщения.

Какъв вид коментари използвате? Смятате ли коментарите за важни за вашия сайт и колко удобни и ефективни намирате коментарите на вашия сайт?

Честно казано, когато видях, че пишат за това и съветват новодошлите в други сайтове, бях малко ужасен и реших да напиша бележката си по тази тема без фатален недостатък. Най-често виждах дълги листове код, които прилагат добавяне на коментари към сайта. Обикновено за целта те създават форма, извършват нейната обработка, запис, както и селекции за показване. Но предимствата на този подход стават все по-малко с течение на времето.

В тази публикация ще научите един от най-простите (но субективно един от най-предпочитаните) начини за добавяне на коментари към сайт - прост пример за начинаещи + опции за по-напреднали уебмастъри.

Наистина, защо да изобретяваме колелото и да пишем куп код, който все още ще трябва да бъде поддържан, коригиран и т.н. в бъдеще, ако има куп готови решенияот услуги на трети страни (говорим за в социалните мрежи+disqus)?

Но преди да преминем към самото внедряване, нека разгледаме предимствата/недостатъците на използването на готови решения. (Ако сте забравили нещо, пишете в коментарите и ще разширим списъка)

Предимства на решенията на трети страни:

• Лесен за изпълнение.
• Защита срещу спам „извън кутията“ (в моето решение ще трябва да внедря това допълнително, така че теоретично е свързано с предишната точка).
• По-малко склонни към грешки, бъгове и т.н., тъй като решенията на трети страни са тествани от милиони потребители (отново свързано с първото: можете също да пишете всичко без бъгове, но ще отнеме допълнително време за отстраняване на грешки).
• По правило услугите предоставят готов административен панел, статистика, известия за администратори, понякога модериране, няколко администратори, предварително модериране и т.н., което може да отнеме месеци, ако не и години, за уеб администратор, особено начинаещ изпълнявам.
• Не е необходимо потребителят да се регистрира, да въвежда името си и т.н. - предполага се, че вече има акаунт в популярна социална мрежа.
• Най-вероятно ще издържи голямо натоварване поради факта, че социалните. платформите първоначално са предназначени за тежки товари.

недостатъци:

• Лоша или пълна липса на възможност за промяна външен видблокирайте с коментари.
• Индексиране в търсачките.

Както можете да видите, има много повече предимства. Невъзможността за промяна на външния вид най-вероятно се прави с цел разпознаване на стила на услугата за коментари, като по този начин се създава ненатрапчива реклама. (Като една от опциите). Колкото до индексирането, наистина ли е толкова важно, защото не всички коментари носят смисъл.

Но достатъчно теория, нека да преминем към практиката.

1. Най-лесният вариант е да добавите коментари с помощта на избрана социална мрежа.

Например vk. Нека да разгледаме документацията. Копираме предоставения код и го добавяме към страницата (части от кода са взети от документите на връзката, те може да се променят в бъдеще, така че винаги копирайте от сайта с документация. Ето само възможен пример):

1) Добавяне към:

VK.init((apiId: 2951023, onlyWidgets: true));

2) Добавете на мястото, където искаме да видим уиджета за коментари (например след бележка, ако говорим за блог):

VK.Widgets.Comments("vk_comments", (редизайн: 1, ограничение: 10, ширина: "665", прикачване: "*"));

2. Добавете джаджи от няколко услуги. Например, като на този ресурс. Превключване на раздели:

Добавете към маркирането (twitter bootstrap трябва да бъде свързан за правилна работа!) на мястото, където искате да се показва джаджата за коментари:

• Обсъдете
• Вконтакте

Но този вариант не е най-добрият, въпреки че е най-простият. Проблемът е, че при този подход всички уиджети ще бъдат инициализирани, когато страницата се зареди, независимо дали потребителят има нужда от тях или не.

Това може да се избегне чрез внедряване на мързелива инициализация на джаджи за коментари. Първо целия код, след това обяснение:

(function(global, $) ( "use strict"; $(function() ( var $tabToggler, initComments, initialized; initialized = ( "#vk-comments": false, "#disqus_thread": false); initComments = функция (тип) ( var discussUserName, disqus_config, pageUrl; if (initialized) ( return; ) pageUrl = "page_url"; switch (type) ( case "#disqus_thread": // имате нуждаза да зададете тези параметри, като използвате подходящия начин на вашата платформа, обсъждайте UserName = "discussUserName"; disqus_config = function() ( this.page.url = pageUrl; return this.page.identifier = "page_identifier"; ); (function() ( var d, s; ​​​​d = документ; s = d.createElement("script"); s.src = "//" + discussUserName + ".disqus.com/embed.js"; s.setAttribute("data- timestamp" , +нова дата()); return (d.head || d.body).appendChild(s); ))(); break; case "#vk-comments": VK.Widgets.Comments("vk -коментари ", ( ограничение: 5, прикачване: "*", pageUrl: pageUrl )); break; default: return; ) initialized = true; ); $tabToggler = $(".comments-wrapper a"); $tabToggler .on ("shown.bs.tab", function(e) ( initComments($(e.target).attr("href")); )); initComments($tabToggler.closest(".active").find (" a").attr("href")); )); ))(прозорец, jQuery);

Обърнете внимание на променливите, чиято стойност трябва да подготвите, като използвате методите, предоставени от вашата платформа.

Първо, нека създадем картографиране на типове уиджети за коментари, променлива инициализирано. След това функция initComments(тип)ви позволява да инициализирате джаджа за коментари и не прави нищо, ако вече е инициализирана.

И последното докосване е да инициализирате приспособлението за коментари по подразбиране, така че да се показва веднага след зареждането на страницата.

Готов скрипт за и кафескрипт за същината. Пример за работа - по-долу (примери на кодове, взети от този сайт)

Време за четене: 55 мин

Добър ден на всички.

Сега дойде времето за дългоочаквания материал за микромаркирането.

Веднага ще кажа, че тази статия ще бъде доста трудна за разбиране в началото, особено за начинаещи, тъй като има много опции за микромаркиране и е трудно да получите всичко в главата си наведнъж. Но ще се опитам да опиша цялостната картина и в същото време да се съсредоточа върху най-важните и общи неща.

Материалът е доста обемен, но се надявам, че ще ви помогне да създадете микромаркиране на сайта.

IN напоследъкЗабелязах, че много хора са фиксирани върху микроданните. Това се случи, след като различни SEO блогъри започнаха бурно да го обсъждат. Но нека да разберем защо изобщо се използва и дали е необходимо да му се обръща толкова много внимание. Играта струва ли си свещта?

Ако чуете микромаркиране или семантично маркиране на страница (сайт), тогава знайте, че това означава маркиране на страница с помощта на допълнителни атрибути (тагове), които дават на търсачките идеята за отделни елементистраници, посочвайки тяхното съдържание.

Трябва да разбереш това обикновена страницаи така се маркира, но се използват обичайните общоприети тагове и атрибути. Това е напълно достатъчно за търсачките и много сайтове все още съществуват по този начин и процъфтяват доста успешно.

Но ако искаме да помогнем на търсачките да разберат нашия сайт, да ги насочим към важни области на страницата, да разберем нейната структура, като посочим съдържанието на тези области, на които първо трябва да се обърне внимание, тогава е необходимо да внедрим микро- маркиране, тоест добавяне на определени тагове и атрибути, които ще показват всичко.

Правейки това, ние не само ще помогнем на търсачките, но и на нашия сайт, тъй като микро маркирането се използва не само за разбиране на структурата и съдържанието на сайта, но и за изграждане на резултати от търсенето, формиране на функционални и атрактивни фрагменти, което влияе на кликванията сквозна скорост (CTR) на сайта в издаване. И това е увеличение на общия трафик на сайта.

Можете да видите ярък пример за такива фрагменти по-долу.

На това изображениеможете да видите, което допълва и го прави по-забележим сред сивата маса на други сайтове в резултатите от търсенето. Използвах също стрелки, за да подчертая пътеката за навигация, която показва ясен структуриран път до материала на сайта, а не обикновен неясен URL адрес.

Тази верига за навигация е доста проста. Всичко, което трябва да направите, е да ги инсталирате на сайта.

Ето още една опция за богати фрагменти.

Същата опция позволява на посетителя веднага да разбере за какво става въпрос в сайта и какво може да му даде. Ако в този случай фрагментът е конструиран правилно, тогава потребителят може незабавно да предприеме действието, от което се нуждаете, и както знаем, всеки сайт трябва да изпълнява свои собствени задачи (абонамент, покупка и т.н.).

Съгласете се, че такъв фрагмент ще бъде по-забележим в резултатите от търсенето, отколкото обикновено описание на страница, тъй като е много по-голям по размер. Да, и изглежда по-солидно.

Нека сега отговорим на въпрос, който може да загрижи онези, които смятат, че микромаркирането помага за увеличаване на позициите и е един от факторите за класиране.

Микро маркирането влияе ли върху класирането? Да очакваме ли увеличение на позициите след прилагането му?

За да не пишем нашите разсъждения, нека се обърнем към помощта на търсачката Yandex. И така, какво ни казва самият Yandex за това? цитирам:

Моят сайт ще се класира ли по-добре, ако използвам маркиране?

Отговор: Маркирането може да направи вашия сайт по-видим в Yandex Search и по този начин да привлече повече посетители, принадлежащи към целева аудитория. Yandex се интересува от потребителите да решават проблемите си с помощта на Търсене. Един от показателите за качество на търсенето се нарича „щастието на потребителя“. Уебсайтовете, които увеличават „щастието“, се класират по-високо.

Можем да заключим, че маркирането не влияе пряко на позициите, а само косвено, тъй като можем да направим по-атрактивен фрагмент, който сам по себе си ще доведе повече посетители на ресурса. След това е въпрос на техника. Повече посетители означава повече натрупани добри показатели за страниците (ако съдържанието е качествено) и постепенно позициите ще се покачват.

Също така си струва да се отбележи, че като помагаме на търсачките да разберат естеството на съдържанието, неговия тип (информация, среща, продукт и т.н.), ние правим съдържанието по-подходящо заявка за търсенеи трябва да заеме по-високи позиции. Може би не пряко, но косвено - това е сигурно. Yandex ни потвърди това (вижте по-горе).

Така че, нека направим кратък контролен списък на предимствата от наличието на микро маркиране на сайта. Това са тези точки, които косвено или пряко показват качеството на сайта, повишават позицията му и помагат на търсачките.

И така, мисля, че отговорът на въпроса е даден.

Изобщо необходимо ли е маркиране? - Да, трябва ми.

Разбира се, ако има избор между болезненото внедряване на маркиране на сайта и работа върху други аспекти, тогава, разбира се, не трябва да се фокусирате само върху семантичното маркиране. По-добре е да работите върху съдържанието, което е много по-важно от някои технически детайли сред стотици или хиляди други неща. Освен това сега можете да маркирате своя фрагмент в резултатите от търсенето, без да въвеждате маркиране в шаблона, а само като инсталирате , който вече предоставя маркиране за оценка.

След като знаем основните предимства, можем да преминем към разглеждане на основните типове семантично маркиране.

Тук всичко е доста сложно. Първо, трябва да разберете, че има микроречници за маркиране и техния синтаксис.

Речникът може да се разбира като език за микромаркиране, който включва набор от класове и свойства, които показват същността на съдържанието на страницата. Във всеки речник всеки елемент на сайта се идентифицира с помощта на различни тагове. Например в речника на Schema.org името на документа е посочено с помощта на маркера „name“, но микроформатите използват CSS клас вътре в блока на елемента, който си струва да се маркира (Chamomile, където fn org е заглавието етикет в този случай).

Всеки речник и синтаксис има свои собствени тагове и атрибути, което прави форматите за микро маркиране така наречения винегрет. Наистина е трудно да разбера всичко.

Синтаксисът се разбира като начин за използване на определен език (речник) на семантично маркиране. Синтаксисът определя кои тагове ще се използват за обозначаване на същността на обектите и техните свойства на страницата.

От предишното определение за синтаксиса беше въведено понятието същност. Какво означава това, приложимо към разглеждания проблем?

Същност – най-просто казано, това е типът информация (единица съдържание, информация), която насочваме към търсачките. Например, трябва да посочим съобщения на главната страница на блога, тоест да подчертаем същността на тази област с някакъв етикет, определяйки я като област за съобщения. Същото трябва да се направи и с публикационната страница, където трябва да посочите същността на областта, в която се намира съдържанието (статията), тоест да маркирате текста като област на съдържанието.

За почти всеки елемент от страницата можете да определите същността, тоест да посочите какво е: съдържание или рейтинг, или коментари като цяло. По този начин обектите могат да бъдат посочени на такива страници (ще взема прост блог шаблон като моя като пример):

• Начало - списък с обяви;
• Страница с публикации - коментари, съдържание, оценка (ако има такава), навигация;
• Обикновена статична страница - съдържание, коментари (ако има).

Освен това на всеки тип страница можете да посочите един и същ елемент - горен колонтитул, долен колонтитул (долен колонтитул), странична лента (странична колона), главно меню.

Всеки обект има свои собствени свойства, например:

• Област за съдържание на страницата с публикации - заглавие на статията, текст на статията, описание, име на автор на статията, дата на публикуване, категория, изображения, видеоклипове и други;
• Областта за списъка с обяви на главната страница, раздели и архиви е същата;
• Област за коментар – име на коментатор, дата, текст на коментара;
• Областта на съдържанието на обикновена статична страница е основно същата като в публикациите;
• Област за заглавка на сайта – заглавие, описание;
• Зона за оценка на страниците - максимална оценка, текуща оценка, брой оценки.
• Footer area (футър на сайта) - година на авторското право;
• Област на страничната лента (странична колона) - име на уиджети;
• Зона на главното меню - връзки.

Има и други области със свойства, но няма да ги разглеждам, тъй като във всеки речник за маркиране има няколко десетки от тях, а в маркирането от schema.org броят им обикновено е в стотици.

Ще разгледаме какви тагове и атрибути да използваме, за да посочим обектите и свойствата на всеки от тях в практическата част на тази статия.

Сега нека да преминем към основната идея на параграфа и да разгледаме основните формати на семантичното маркиране. Кратък списъкКлючови речници и синтаксис могат да се видят в мисловната карта по-долу.

Няма да разглеждаме всички речници и синтаксиси, тъй като това е безсмислено. Няма да ти трябват. Нека обсъдим само накратко основните формати за маркиране:

• Schema.org;
• отворена графика;
• Микроформати.

Ще се докоснем до някои от останалите съвсем малко.

Последната стъпка заслужава да се отбележи друг речник, а именно Data Vocabulary, който е разработен от Google и сега неговото развитие е спряно. Цялото внимание се насочи към Schema.org. Можем да кажем, че всички свойства и обекти, които бяха в този език за маркиране, станаха прототипи за маркиране от schema.org.

Доколкото разбирам, речникът на Data Vocabulary може да работи със синтаксис: микроданни и езика RDF, което може да се види много ясно в помощта на Google за материал за микромаркиране на навигация. Има 2 опции за маркиране:

Ще изпреваря малко. В първото изображение можете да видите, че микроданните от Schema.org се използват заедно с речника на данните. Факт е, че навигационните трохи със схема все още не се поддържат. Следователно се използва комбиниран вариант.

Мисля, че вече знаете въпроса за този въпрос, тъй като в описанието на всеки тип маркиране дадох неоспорим аргумент, че търсачкиТе самите препоръчват речника за маркиране на Schema.org. Това е точно това, което трябва да използвате. Но може да има много опции за прилагане на това микромаркиране, както от плъгини, така и чрез въвеждане на обекти и свойства в шаблони за дизайн.

Последният вариант е най-оптималният, тъй като това е еднократна работа и микромаркирането ще бъде на абсолютно всяка страница. Всички търсачки ще го видят, тъй като ще бъде вграден в шаблона. Но начинаещите може да имат проблеми с прилагането му, тъй като се нуждаят от поне минимум начално ниворазберете кода на вашия шаблон и вижте кой таг показва заглавието на статията, къде е кодът за показване на текста и т.н. Всички тези моменти ще трябва да бъдат обвити с маркери за микромаркиране.

Тази точка повдига и въпроса за комбинирането на различни речници на един сайт. Това е приемливо и в някои случаи не може да бъде избегнато. Това ясно се вижда в примера за маркиране на навигационен път, когато се комбинират вариант на маркиране на речник на данни и маркиране на микроданни от Schema.org. Няма нищо лошо в това. Самият Yandex говори за това.

Това зависи от вашата преценка. Ако смятате, че е по-лесно да използвате микроформати, тогава давайте. Аз лично ще покажа целия процес на микро-маркиране Schema.org, тъй като аз самият го внедрих и всичко работи с гръм и трясък без нито една грешка.

Нашата задача на този етап е да разберем дали шаблонът ни има някакъв формат за маркиране. Това е напълно възможно, тъй като повечето от използваните шаблони са преведени англоезични теми, които вече съдържат някакъв вид формат за семантично маркиране. По правило това е маркиране в микроформати, което изобщо не ни е от полза. По-добре е първоначално да го няма, тъй като това ще ни спести главоболието при отстраняването му.

За да проверите наличието на маркиране, можете да използвате както инструмента за микромаркиране от Yandex, така и инструмента за проверка на структурирани данни на Google. Предпочитам и силно ви препоръчвам да използвате валидатора на Yandex, тъй като е много по-прост.

След като отидем до валидатора на Yandex, въвеждаме адреса на страницата и кликваме върху „Проверка“.

Ако пише „Микро маркиране не е открито“, това означава, че в шаблона няма маркиране на трета страна. Това е много добре, тъй като не е нужно да губите усилия, за да го премахнете. Но бъдете внимателни, защото на един тип страница може да няма маркиране, но на друг ще има (например на страница със статия).

И така, анализирам страницата с публикацията и се оказва, че коментарите на шаблона са маркирани с микроформати (присъства vcard). Това се доказва от различни кодове в резултатите от сканирането.

Не се нуждаем от микроформати, така че трябва да ги изтрием. Може да се случи вашият шаблон да бъде маркиран в други формати за маркиране. След това те също трябва да бъдат премахнати. И е възможно маркирането от Schema.org да бъде внедрено веднага. Това също се случва, но много рядко, тъй като практически няма безплатни шаблони, които да си струват. Но лошите са стотинка дузина.

Сега нека да разгледаме процеса на премахване на маркиране на трети страни.

Тъй като в моя случай се оказа маркиране на трета страна, използващо микроформати, ще използвам неговия пример, за да покажа този процес. Ако имате друга маркировка, тогава принципът на изтриването й ще бъде подобен.

Всичко се свежда до премахване на етикетите и техните атрибути от маркирането, което имате. Единствената разлика между микроформатите и другите типове микромаркиране ще бъде, че всички типове с изключение на микроформатите добавят нови етикети и атрибути. Микроформатите не добавят нищо, но се записват в конкретен атрибут на класа html елементшаблон (например заглавие на статия), както писах в параграфа за основните типове.

Между другото, в точка № 6 от тази статия давам кода за маркиране на коментари, който трябва да бъде вмъкнат в шаблонния функционален файл functions.php. Този кодтрябва да излекува тези грешки от маркирането на микроформат на трета страна. Ето защо, ако имате този проблеме наличен, тогава първо препоръчвам да проверите този код във вашия шаблон. Той трябва да помогне. Това ще ви спести ненужната работа по ръчно изхвърляне. Ако нищо не се получи, тогава правим всичко на ръка, както описвам по-долу.

Сега нека да преминем към самия процес. И така, по-рано стана ясно, че имам допълнително маркиране от микроформати. При проверка във валидатора ни беше даден таг vcard, който създава грешки.

Сега трябва да отворим папката с шаблона, за да видим всичките му файлове и след това се обръщаме към тези файлове, които са отговорни за показването на тези елементи, където се намират микроформатите. Как да направите това, вижте списъка по-долу:

Надявам се, че го обясних съвсем просто. Въпреки че начинаещият може да има повече объркване в главата си.

Ето как тази част от кода с vcard първоначално изглеждаше в моя шаблонен файл.

След смяната стана така.

Направих промени и в стиловете.

Сега няма микроформати и дизайнът е запазен в оригиналния си вид.

Така че, когато сме премахнали стандартното маркиране (ако е присъствало), можем да вградим ново от Schema.org. Ние започваме този процес.

Нека започнем с малко обяснение и теория, тъй като винаги трябва да се подготвите преди практиката.

Първо, струва си да разберем какви файлове трябва да посочим необходимите обекти и техните свойства. Сега говоря за файлове за двигателя на WordPress. За други двигатели няма да кажа нищо, тъй като не работя с тях. Принципът на маркиране остава същият. Просто трябва да определите файловете къде се намират задължителни площиза маркиране.

• Single.php файл (записен файл): entity - област със съдържание (статия), свойства - дата на публикуване, автор, категория, заглавие на статия, изображения;
• Файл Functions.php (в моя случай - маркиране на кода на коментара): entity - коментар, свойства - текст на коментара, дата и име на коментатора;
• Файлове със списък с обяви index.php, category.php, archive.php (съответно основни, категории и архиви): entity - списък с обяви, свойства - дата на публикуване, автор, категория, заглавие на статията;
• Файл page.php (обикновена статична страница - по избор): entity - област на съдържанието, свойства - заглавие на текста и, ако има, дата, автор и други;
• Във файла header.php също маркирайте заглавката - обектът ще бъде заглавката, а свойствата ще бъдат заглавието на сайта + описанието;
• Файл sidebar.php (странична колона): entity - цялата странична лента, property - заглавието на всеки widget;
• Файл footer.php (долен колонтитул на сайта): entity - целия футър, property - дата на авторското право + име на сайта (не съм маркирал името);
• Файл header.php (горната част на ресурса): entity - главно навигационно меню, property - връзки + техните котви.

Сега относно таговете и атрибутите, които съответстват на всеки тип обект и съответните им свойства. Първо за същностите.

/***Списък с съобщения***/ itemscope itemtype="http://schema.org/BlogPosting" /***Съдържание на страницата за публикуване***/ itemscope itemtype="http://schema.org/Article" / ***Коментари***/ itemprop="коментар" itemscope itemtype="http://schema.org/Comment" /***Обикновена статична страница***/ itemscope itemtype="http://schema.org / Статия" /***Странична лента (странична лента)***/ itemscope itemtype="http://schema.org/WPSideBar"> /***Долен колонтитул (долен колонтитул на сайта)***/ itemscope itemtype="http:/ /schema.org/WPFooter"> /***Навигация на сайта (главно меню)***/ itemscope itemtype="http://schema.org/SiteNavigationElement"> /***Изображения***/ itemscope="" itemtype="https://schema.org/ImageObject" /***Постоянна връзка към страницата***/ itemscope itemprop="mainEntityOfPage" itemType="https://schema.org/WebPage" /***Организация * **/ itemscope itemtype="https://schema.org/Organization" /***Адрес***/ itemscope itemtype="http://schema.org/PostalAddress"

Сега етикетите на собствеността.

• Заглавие на страница (текст) - itemprop="headline"
• Текст за въвеждане - itemprop="articleBody" (може да се използва и за описание, ако е оформено като част от пълния текст)
• Дата на публикуване - itemprop="datePublished"
• Автор - itemprop="автор"
• Категория на статията - itemprop="articleSection"
• Изображение - itemprop="изображение"
• Текст на коментара - itemprop="текст"
• Име на коментатора - itemprop="creator"
• Дата на коментар - itemprop="datePublished"
• Линк (отнася се за главното меню и изображението) - itemprop="url"
• Година на авторските права в долния колонтитул - itemprop="copyrightYear"
• дата последна промянастраници - itemprop="dateModified"
• Адрес - itemprop="адрес"
• Улица - itemprop="streetAddress"
• Индекс - itemprop="postalCode"
• Местоположение на адреса - itemprop="addressLocality"
• Телефон - itemprop="телефон"
• Дължина на изображението - itemprop="width"
• Ширина на изображението - itemprop="height"
• Лого - itemprop="лого"

Това са основните свойства, които сега ще използваме.

По-нататъшните стъпки за маркиране на шаблона са доста прости.

Всяка област, която трябва да дефинира обект и свойство, използвайки таговете, предоставени по-горе, е обвита в някакъв вид общ таг. Това може да бъде таг за блок div, таг за статия, таг за обхват, заглавка H1 и други. За по-лесно разбиране заглавието почти винаги е обвито в H1 таг, както трябва да бъде. Ще има 2 етикета: отварящ и затварящ. И така с всеки елемент от сайта, а не само с хедърите.

Идеята е, че на всеки задължителен елемент ще трябва да бъде даден етикет на обект (посочете типа на съдържанието: статия или коментар, или списък със съобщения и т.н.) и свойства в неговия отварящ таг.

Сега тренирайте. Например, има файл с една публикация (статия) single.php. Да започнем с неговото маркиране.

Нека започнем с дефинирането на обекта. Шаблонът има общ таг, който обхваща цялата област със съдържание на публикацията (както текста на статията, така и заглавието и коментарите) и е различен за всеки. За някои може да е div блок. Имам тази статия. Естествено, този етикет се отваря в самото начало, където започва цялото съдържание, и свършва някъде, когато съдържанието свършва.

И в самото начало, вътре в началния таг на статията, трябва да вмъкна тага на обекта на областта със съдържание на страницата за публикация (дадох кодовете малко по-нагоре). Ще ви дам изображение (с възможност за щракване) на окончателното маркиране на записващия файл single.php и след това ще обясня какво се е случило и какво е станало накрая, ако на някого не е ясно. Изображението е голямо, но може да се кликне, така че можете да щракнете върху него и да го видите в по-голям размер или да го отворите в нов раздел и да го видите в пълен размер.

Първоначално цялата област със съдържание на публикацията се отваря с помощта на етикета на статията. Беше така:

И стана така:

Както можете да видите, етикетът на публикацията е включен в началния етикет на статията. Сега роботът за търсене ще разбере, че това е област, която съдържа съдържание. Ще възприеме тази област като обект. Много е важно.

Между другото. Много хора задават оценки на статии без плъгин и след проверка на страницата в Yandex или Google валидатор им се казва, че обектът на прегледа не е посочен. Това се дължи на факта, че рейтингът се публикува самостоятелно. Трябва да го поставите в тази област, която от своя страна трябва да бъде дефинирана от етикет за маркиране като област на съдържание (или обект за преглед). Тогава рейтингът ще принадлежи на обекта, тоест на статията. След това няма да има грешки.

Да се ​​върнем към процеса. Първо поставихме същността на обекта (обвихме цялата основна област с общ етикет), а след това маркирахме неговите свойства, тоест вторични данни: дата на публикуване, автор, тяло на статията (самия текст) , информация за издателя (адрес, организация, лого), дата на последна промяна на страницата, адрес начална страницаи така нататък. Всичко е абсолютно същото - във всеки отварящ таг задължителен елементпосочете подходящите параметри. По-долу предоставям обяснение какво се е случило преди да бъдат направени промените и какво се е случило след това.

Първоначално копираме 2 реда код непосредствено след отварящия таг, който обвива цялата област със съдържание. За мен това е етикет на статия с обект вътре в него, който беше поставен по-рано в текста.

Дата на публикуване. Беше:

Константин Хмелев

Константин Хмелев

".$текущо_име_на_категория."

".$текущо_име_на_категория."

Текст на статията. Беше:

ето код на трета страна

ето код на трета страна

Вие сами трябва да направите почти същото. Единствените разлики ще бъдат в таговете, вътре в които трябва да поставите таговете за обект и свойство. Техният ред също може да бъде различен. Или може да се окаже, че нещо изобщо няма да го има, например няма да има дата на публикуване или връзка към категорията. След това ще трябва да добавите тези данни към шаблона.

В предпоследния параграф на статията ще ви дам кодове, които можете да използвате, ако внезапно ви липсва нещо.

Така че сега трябва да проверим нашата страница в Yandex и Google валидатори.

Във валидатора на Google ще е почти същото. Не трябва да има грешки в тези данни. Единственият нюанс се отнася до микромаркирането на изображения, към което преминаваме.

Можете да маркирате всяко изображение ръчно, като го опаковате в същността на изображенията и зададете необходимите свойства, но това е доста неудобно, когато във всяка публикация има няколко десетки изображения. Нека използваме следния код.

Функция micro_images_captions ($a, $attr, $content = null)( екстракт(shortcode_atts(array("id" => "", "align" => "alignnone", "width" => "", "caption" = > ""), $attr)); if (1 > (int) $width || празен($caption)) върне $content; $caption = html_entity_decode($caption); if ($id) $id = "id ="" . esc_attr($id) . "" "; return "" . do_shortcode($content) . "

". $caption. "

Сега не е необходимо да добавяте етикет за маркиране на изображение към всяка статия. Отиваме до валидатора, проверяваме страницата с поне една снимка и виждаме следващата снимка.

Не трябва да има никакви грешки. Всичко е чисто. Всяко изображение трябва да бъде обвито с маркиране, точно както на екранната снимка по-горе.

Тук трябва да обвиете кода, който показва списъка с съобщения, с етикета за обект на списъка с съобщения. Това се прави точно по същия начин. Вътре в общия таг, който обвива целия код в шаблона, поставяме желания таг (същността на списъка с публикации в блогове е публикуване в блогове или можете да го направите по аналогия със страницата за публикации - статия). Вижте изображението (може да се кликне).

Както можете да видите, моят списък с съобщения се показва с помощта на етикета li list, тоест всяко съобщение е затворено в него. Вътре в списъка е почти същият като в самия запис - има дати, име на автора, заглавие на раздели, адрес, лого, издател и т.н. Можете ясно да видите това на страниците на блога. Структурата е подобна, само текстът на статията не е пълен. Като цяло маркирането е точно същото като за страницата за публикация, с изключение на етикета за обявяване на блогове.

Също така е необходимо да използвате малко по-различен код за маркиране на изображението за страницата с съобщения, тъй като тя показва не само снимки, но и миниатюри. Микромаркирането на миниатюри ще се извършва с почти подобен код. Ако преди е трябвало да се маркират на ръка, сега няма смисъл да го правите. Ето кода (поставяме го и във файла functions.php).

Функция micro_thumbnail($content) ( $ar = "!!si"; $br = ""; $content = preg_replace($ar, $br, $content); върне $content; ) add_filter("post_thumbnail_html", "micro_thumbnail ");

Свързваме се с валидатора и проверяваме началната страница. Показах ви само 2 обяви, защото... целият екран ще бъде много голям.

Ще има толкова много такива публикации в блогове, колкото са съобщенията на тази страница. Ако сте използвали статия вместо публикуване в блог, тогава ще имате няколко статии в зависимост от броя на съобщенията.

защото начална страницаТъй като структурата му е подобна на страниците на раздели и архиви, тяхното микромаркиране е идентично. Списъците с обяви се показват на всички видове страници.

И така, всичко, което остава, е да анализираме маркирането на коментарите, което е доста сложен процес за начинаещ. Остават и обикновени статични страници. Принципът на тяхното маркиране е подобен на записите, така че няма да го показвам.

И така, коментари. Нека опростим задачата до вмъкване на един код във файла functions.php и модифициране на функцията, която показва коментари на страниците на сайта. Първо вземете следния код и го поставете във файла functions.php в самото начало, точно преди отварящия таг< ?php. Если будет выдавать ошибку, можно попробовать его разместить после закрывающего тега?>в самия край на файла.

Има и опция за поставяне, когато трябва да премахнете отварянето на php кода в този код в самото начало (премахнете< ?php) и в самом конце его закрытие (удалить?>). След това трябва да поставите кода не преди или след отварящия (затварящия) php таг, а вътре в тези тагове до всички други функции. Понякога срещах проблем, когато тази конкретна опция за разположение работи.

Кодът не работи на всички шаблони!

id="comment-">

Пълният изходен ред на тази функция може да е различен, но същността му е същата. Трябва да има comments_number вътре.

За мен тази функция има следната пълна форма заедно с етикета за обвиване.

< ?php comments_number("Комментариев пока нет. Будьте первым!","1 Комментарий","Комментариев: %") ?>

В зависимост от шаблона трябва да намерите местоположението на функцията. Обикновено всичко е в един и същ файл comments.php. В моя шаблон тази функция се намираше във файла с единичен запис single.php преди показване на формуляра за коментар. Тъй като функцията ми беше обвита в таг за span text, вмъквам свойството commentCount вътре в нея.

Свързваме се с валидатора.

важно. Трябва само да опаковате броя на коментарите без никакви надписи или думи. Маркировката приема само числа!

Внимание: Не съм автор на функциите. Функциите за автоматично маркиране на коментари и изображения са взети от сайта http://seo-mayak.com/. Просто промених малко имената + коригирах нещо малко някъде.

Отворете файла header.php на шаблона за дизайн и потърсете отварящия заглавен таг. В него поставяме:

Itemscope itemtype="http://schema.org/WPHeader"

• Заглавие - itemprop="headline"
• Описание - itemprop="описание"

Ето готовата версия на изображението.

Ще се покаже във валидатора по този начин.

Тук също всичко е просто. Отваряме файла, който отговаря за изхода на страничната колона, като правило това е sidebar.php. Намираме блок или таг, който обвива цялото съдържание на цялата странична колона и вътре в него поставяме тага на обекта, съответстващ на страничната лента.

Register_sidebar(array("name" => __("Зона за вмъкване на джаджи в страничната лента", "xmarkup"), "id" => "primary-widget-area", "description" => __("", " xmarkup "), "before_widget" => "", "after_widget" => "", "before_title" => "", "after_title" => "",));

Интерес представляват последните 2 реда (before_title и after_title), които определят какво ще се показва съответно преди и след заглавието на уиджета. Както можете да видите, посочих, че ще има етикет за текст преди и след. Може да имате нещо празно там или някои други тагове, като например таг за блок div. Ако е празен, препоръчвам да добавите таг span, подобен на моята версия, и да посочите свойството name (itemprop="name") в отварящия таг (ред преди_заглавието). Ще получите следната конструкция:

Register_sidebar(array("name" => __("Зона за вмъкване на джаджи в страничната лента", "xmarkup"), "id" => "primary-widget-area", "description" => __("", " xmarkup "), "before_widget" => "", "after_widget" => "", "before_title" => "", "after_title" => "",));

В зависимост от шаблона може да има няколко такива части от кода. След това всички части ще трябва да бъдат финализирани. След промените проверяваме маркирането на страничната лента чрез валидатора на Yandex и трябва да се получи следната картина.

В зависимост от броя на уиджетите, съответният брой редове ще бъде показан при проверка.

Отворете файла footer.php и потърсете общ блок, който обвива цялото съдържание на долния колонтитул, включително авторските права. Вътре в отварящия таг поставяме етикета на обект itemscope itemtype="http://schema.org/WPFooter".

И вътре в отварящия таг, който съдържа датата на авторското право, поставяме тага на свойството itemprop="copyrightYear".

Много е важно вътре в етикета copyrightYear да има само дата под формата на число. Без странични думи или символи, в противен случай ще генерира грешка.

В работно състояние ще видите следното във валидатора.

Тук също всичко е изключително просто, но тази опция няма да работи за всички, тъй като структурата на конструиране и показване на менюто в шаблоните е различна.

Кодът, който показва менюто, е във файла header.php. Отиваме там и търсим следното съдържание:

< ?php wp_nav_menu(array("theme_location" =>"header-menu-top", "container" => "")); ?>

Линията може да е малко по-различна. Основното нещо е да намерите реда, който включва wp_nav_menu. Ще бъде опаковано в тагове. При мен и в повечето други теми принципа е подобен. Използва се навигационният етикет. Вътре в отварящия навигационен таг вмъкваме таг, който показва същността на този елемент, а именно главното меню:

Itemscope itemtype="http://schema.org/SiteNavigationElement"

След това трябва да се уверите, че атрибутът itemprop="url" е добавен към всяка връзка в менюто, което ще покаже, че това е връзка. Ако имате прост сайт, където всеки елемент от менюто е създаден на ръка, тогава внедрете този атрибут в тага на всяка връзка. Ако имате уебсайт на WordPress и менюто се формира във файла functions.php по стандартен начин, трябва да поставите следния код в същия файл, който автоматично ще вмъкне този атрибут към всеки елемент от менюто.

Функция nav($content) ( $pattern = "