Активность

Лента обновляется автоматически     

  1. Вчера
  2. support

    Аналог phpMyAdmin для MongoDB!

    Иногда удобно иметь GUI интерфейс для доступа к базе данных MongoDB. Аналог phpMyAdmin для базы данных mySQL. Только для MongoDB. Я использую программу Robo 3T - https://robomongo.org/ Это нечто вроде аналоги phpMyAdmin, только для работы с базами данных MongoDB.
  3. support

    настройка 1

    вот например шаблон subcategory-listing: {if $content_list} <div class="row featured-categories"> <ul class="thumbnails"> {foreach from=$content_list item=node} <li class="item col-sm-4 col-md-3"> <div class="thumbnail text-center"> <a href="{$node.url}" class="image"> <img src="{$node.image}" alt="{$node.name}"{if {$node.image_width} > 0} width="{$node.image_width}"{/if}{if {$node.image_height} > 0} height="{$node.image_height}"{/if} /> </a> <div class="inner notop text-left"> <a href="{$node.url}"><h4 class="title"><i class="fa fa-folder-open"></i> {$node.name}</h4></a> </div> </div> </li> {/foreach} </ul> </div> {else} <div>{lang}No Items Found{/lang}</div> {/if} Можно ведь даже методом тыка всё поменять, даже если не знаете html.
  4. Немного про процесс разработки, т.е. внесение правок в исходный код. В php+mysql всё просто. Внёс правку в код - и сразу видишь всё в браузере, нажав кнопку обновить. В случае с react + nodejs + mongodb всё немного сложнее, т.к. это приложения и они собираются из исходного кода, есть frontend, есть backend. Всё это собирается, компилируется из исходников, и запускается веб-сервер. т.е. есть два этапа, грубо говоря, копия для работы и копия для установки на веб-сервер. Сначала всё правится, тестируется, проверяется, затем всё собирается, компилируется и выкладывается на сервер и только потом магазин со всеми изменениями доступен посетителям. Принципиальная разница в том, что нужна сборка, компиляция исходного кода. В php тоже частично сейчас используется компиляция и сборка (например пропроцессоры css, sass, scss, всё это тоже по сути компиляция из исходников), но это всё-таки совсем другое дело. В проекте на nodejs + react сборка, компиляция - это прям стандартный процесс, без которого не обойтись, в отличии от php. Это и плюс и минус. т.е. внесли Вы правку в шаблон и хотите увидеть исправленный шаблон в браузере, для этого нужно взять все исходники, собрать, скомпилировать всё в кучу и запустить веб-сервер, только затем смотреть изменения в браузере. В этом смысле всё сложнее намного чем в php + mysql. Но это тоже решается, использованием так называем watchers, наблюдателей, т.е. Вы просто запускаете особым образом и сборку и веб-сервер. Всё собирается "на лету", т.е. сразу же всё собралось и перезапустились приложения и Вы точно так же можете видеть изменения в браузере. Нужно только запускать сборку и запускать приложения с вотчерами. Итак, хотим мы что-то изменить в магазине, написовать свой шаблон или ещё что, не важно. Будем считать, что у нас уже всё настроено, все зависимости установлены, всё запускается без ошибок. Процесс разработки выглядит так: 1. Запускаем сборку с вотчером: npm run build:watch Это значит, что не надо после каждой правки файла вручную запустить npm run build, все изменения в файлах автоматически отслеживаются и компилируются. Терминал не закрываем. Окно терминала должно оставаться открытым постоянно. Там будет видно, что сборка происходит после каждого изменения в файлах. 2. Запускаем приложения с вотчером. pm2 start process.json --watch Это значит, что запустятся наши приложения store и api и будет работать вотчер, который будет следить на именения, если код поменялся, приложения перезаупстились. Тем самым мы добиваемся более-менее похожего процесса разработки на php + mysql. В таком случае все изменения, что мы вносим код видны сразу же в браузере, просто обновляем страницу и видим изменения. Не надо после каждой правки все вручную пернсобираться, стартовать приложения каждый раз по-новой. Всё это происходит на локальном компе для разработки. После проверки, что всё хорошо, всё работает. Уже переноси всё на рабочий сервер в собранном, скомпилированном виде. На сервер уже будет работать собранная версия, без лишних библиотек, исходников и прочего. Это тоже и плюс и минус, по сравнению с php + mysql. Просто разные подходы и разные технологии. Но конечно следует сказать, что php + mysql гораздо проще в работе, в отслеживании всяких проблем и ошибок. Нет никакой компиляции, всё доступно здесь и сейчас, что на локальном компе, что на сервере.
  5. Благодарю. Не подумал про этот файл. У меня в редакторе он выглядел серым, но никак не белым. Но дело оказалось именно в нём.
  6. Для чего нужен файл package-lock.json ?! и для чего его нужно использовать и добавлять в системы контроля версий (git и т.д.). В этом файлы описана вся структура зависимостей, версий, что в каком поярдке ставилось, какие пакеты, каких версий, что от чего зависит, какие версии были у вложенных зависимостей и т.д. Это нужно для того, что б получить единое рабочее окружение для всех разработчиков. Если у Вас есть файл package.json и package-lock.json и Ваш исходный код без ошибок, Вы можете быть уверены, что у Вас всё запустится. Раз разработчик уже всё проверил и выложил свой lock файл, с описанием рабочего окружения, Вы тоже получаете такое же проверенное рабочее окружение у себя на компе. Просто выполняете npm install и выгружаете зависимости в том порядке и тех же версий, который были у разработчика в проверенном окружении. Почему это Важно и почему могут быть проблемы без package-lock.json?! Потому что версии используемыех зависимостей постоянно меняются, версии вложенных пакетов тоже меняют, т.е. какая-то несуществуюнная библиотека вытягивает какой-то свой пакет старой версии и только на этой старой версии эта библиотека работает и т.д., какие-то пакеты утаревают, меняют названия и т.д. и т.п. Вот всё это и описывается в package-lock.json, все эти возможные проблемные места. Важно сохранить рабочее окружение, проверенное, на котором всё запускается. Да, файл package-lock.json - это автоматически герерируемый файл при выполнении в первый раз команды npm install и по логике вещей, в системе контроля версий не должно быть автоматически генерируемых файлов, достаточно лишь списка зависимотей pakcage.json Но на практике это не вегда так. К примеру, сделали Вы проект, всё проверили, всё работает, удалили папку node_modules со всеми пакетами, оставили package.json с номерами версий и всё, добавили всё-таки в git или просто в архив запаковали и отложили архив до лучших времени, либо может передали другому разработчику. В этом случае, велика вероятность, что, к премеру, через год, у Вас ничего не запустится из этого архива, если Вы просто сделаете npm install Потому что за год поменялись многие пакеты, различные версии, зависимости внутри других зависимостей и т.д. и т.п. Даже у Вас как автора кода могут возникнуть такие проблемы, а сторонний разработчик даже и запустить проект не сможет. В итоге часто получается, так, что код, который работает без проблем сегодня, завтра просто не будет работать из-за изменений в зависимых пакетах. Вот для этого и нужен файл package-lock.json Который, условно говоря, делает снимок системы, на момент когда приложения запускалось и успешно работало. Благодаря такому снимку, любой человек, который будет работать с исходным кодом через год, к примеру, получит точно такое же окружение для запуска проекта как и год назад, т.е. с большой долей вероятности он его запустит без проблем и через год. Без такого снимка, без файла package-lock.json, только с файлом зависимостей package.json, есть большая вероятность, через город просто ничего не запутится. Так что, если Вы запустили проект, приложение и оно рабтает сейчас, на данный момент времени, возьмите Ваш сгенерированный файл package-json.lock и добавьте его в системы контроля версий. Для будущих пользователей Вашего приложения, они скажут Вам спасибо. Да и для себя тоже, если Вы отложите например в сторону работу с кодом и вернётесь к нему через год, условно говоря. Файл package-lock.json сэкономит Вам кучу времени.
  7. Для чего нужен файл package-lock.json ?! и для чего его нужно использовать и добавлять в системы контроля версий (git и т.д.). В этом файлы опоисана вся структура зависимостей, версий, что в каком поярдке ставилось и т.д. Это нужно для того, что б получить единое рабочее окружение для всех разработчиков. т.е. если у Вас есть файл package.json и package-lock.json, Вы можете быть уверены, что у Вас всё запустится. Рак разработчик уже всё проверил и выложил свой lock файл, с описангием рабочего окружения, Вы тоже получаете такое же проверенное рабочее окружение. Просто выполняете npm install и выгружаете зависимости в том порядке и тех же версий, который были у разработчика в проверенном окружении. Почему это Важно и почему могут быть проблемы без package-lock.json?! Потому что версии используемыех зависимостей постоянно меняются, какие-то пакет утаревают, меняют названия и т.д. и т.п. и Важно сохранить рабочее окружение, проверенное, на котором всё запускается. Да, файл package-lock.json - это матически герерируемый файл npm при выполнении в первый раз команды npm install и по логике вещей, в система контроля версий не должно быть автоматически генерируемых файлов, достаточно лишь списка зависимотей pakcage.json Но на практике это не вегда так. К примеру, сделали Вы проект, всё проверили, всё работает, удалили папку node_modules со всеми пакетами, оставили package.json с номерами версий и всё. В этом случае, велика вероятность, что, к премеру, через год, у Вас ничего не запустится, если Вы просто сделаете npm install Потому что за год поменялись многие пакеты, различные версии, зависимосит внутри других зависимостей и т.д. и т.п. В итоге чато получается, что то, что работало сегодня, завтра просто не будет работать из-за изменений в зависимых пакетах. Вот для этого и нужен файл package-lock.json Который, условно говоря, делает снимок системы, на момент когда приложения запускалось и успешно работало. Благодаря такому снимку, любой человек, который будет работать и исходным кодом через год, к примеру, получит точно такое же окружение для запуска проекта как и год назад, т.е. с большой долей вероятности он его запустит без проблем и через год. Без такого снимка, без файла package-lock.json, только с файлом зависимостей package.json, есть большая вероятность, через город просто ничего не запутится. Так что, если Вы запустили проект, приложежни и оно рабтает, возьмите Ваш сгенерированный файл package-json.lock и добавьте его в системы контроля версий. Для будузие пользователей Вашего приложения, они скажут Вам спасибо.
  8. Ниже пару заметок насчёт общего смысла, как надо настраивать веб-сервер для работы с nodejs, что б при открытии домена в браузере как раз работало наше приложение, как в демке https://cezerin.ru Смысл настройки веб-сервера для работы с NodeJS Пример рабочего конфига ngnix в файле nginx.conf, прицеплен внизу. Именно на этом конфиге работает онлайн-демка https://cezerin.ru Итак... в сравнении с php и веб-сервером, с nodejs всё немного по-другому. По умолчанию в магазине у нас два приложиния: backend - api, который сидит на 3001 порту - http://localhost:3001 frontend - сайт и админка, которые сидят на 3000 порту - http://localhost:3000 и http://localhost:3000/admin Нам надо настроить веб-сервер, что б был правильный разбор адресов при обращении к магазина по названию домена http://магазин.ру Принцип настройки: 1. Все запросы к серверу делаем в папку /public/content т.е. по умолчанию там READMe.md файл. Значит при открытии http://магазин.ру/content/README.md должен открываться README.md 2. API у нас висит на 3001 порту, т.е. localhost:3001 А frontend на 3000, т.е. localhost:3000 Нам надо настроить прокси для веб-сервера. т.е. при открытии 80 порта в браузере http://магазин.ру Нужно настроить что б все веб-запросы к сайту шли на localhost:3000, т.е. на приложение store, на frontend. 3. Все запросы к API идут на http://localhost:3001/api , т.е. на приложение api, которое сидит на 3001 порту. т.е. для запросов api настраиваем прокси, что б при обращении в браузере к http://магазин.ру/api всё шло на http://localhost:3001/api Всё это как раз и реализовано в приложенном рабочем конфиге nginx.conf. Так же надо будет поменять ip 127.0.0.1 на реальное название домена в конфигах в папке /config Убрать везде порты. Просто оставить, к примеру, localhost/api или просто localhost и т.д. Всё, что здесь описано, как раз сделано на примере онлайн-демки https://cezerin.ru т.е. это реальный рабочий пример устаноки, описание принципа запуска cezerin и настройки веб-сервера для работы с cezerin. Установка на виртуальную машину ubuntu 16.04 используя docker: https://github.com/cezerin/cezerin/blob/master/docs/how-to-deploy-a-cezerin-on-ubuntu-16-04.md Установка на виртуальную машину ubuntu 18.04 используя gitgub + docker контейнер для mongodb: https://github.com/cezerin/cezerin/blob/master/docs/how-to-deploy-a-cezerin-on-ubuntu-18-04-1-github.md nginx.conf
  9. support

    Подсказки по MongoDB!

    Запуск MongoDB: sudo service mongod start Консоль управления: mongo Как удалить базу и все данные. Заходим в консоль: mongo Подключаемся к базе shop: use shop; Удаляем: db.dropDatabase(); Удалить таблицу (коллекцию). db.collection_name.drop(); Например удаляем таблицу customers: db.customers.drop();
  10. Сделать backup базы в docker контейнере: смотрим название контейнера с mongodb: docker ps делаем backup: docker exec store-db bash -c "mongodump -d shop -o /data/db/backup" Восстановить backup базы в docker контейнере: смотрим название контейнера с mongodb: docker ps делаем restore: docker exec store-db bash -c "mongorestore -d shop /data/db/backup" Удалить все данные из базы:Заходим в консоль: mongo Подключается к базе shop: use shop; Удаляем: db.dropDatabase();
  11. Установка на виртуальную машину ubuntu 16.04 используя docker: https://github.com/cezerin/cezerin/blob/master/docs/how-to-deploy-a-cezerin-on-ubuntu-16-04.md Установка на виртуальную машину ubuntu 18.04 используя gitgub + docker контейнер для mongodb: https://github.com/cezerin/cezerin/blob/master/docs/how-to-deploy-a-cezerin-on-ubuntu-18-04-1-github.md Список установленных образов: docker images Список работающих контейнеров: docker ps Удалить работающий контейнер без остановки: docker rm -f qa_nginx Пример экспорта базы данных MongoDB, который работает в контейнере. Выполнение команды в изолированный докер контейнере: docker exec store-db bash -c "mongodump -d shop -o /data/db/backup"
  12. Команды для запуска cezerin. Установить зависимости, прописанные в package.json: npm install Собрать проект: npm run build Запустить компиляцию в реальном времени, "на лету", т.е. изменились файлы, внеси Вы правки какие-то в код, run build скомпилировал файлы автоматически, "на лету": npm run build:watch т.е. не надо каждый раз пересобирать js файлы после каждой правки. Запустили, оставили терминал открытым. Запустили приложения через pm2 менеджер с ключом --watch: pm2 start process.json --watch и правите js файлы, затем в браузере страницу обновляете и сразу видны изменения на страницы. Серверную часть (/src/api/server) перезапускать не надо. Внесли правку в файл и всё это сразу доступно в браузере, в запросах. Загрузить в базу стандартные страницы, индексы в таблицы: npm run setup Исходник с кодом в /src/api/server/setup.js При первом запуске так же загружаются настройки по умолчанию в таблицу settings. Исходник в сервисе settings, файл /src/api/server/servies/settings/settings.jsДобавить email админа и домен магазина: npm run setup vam@test.com http://адрес-магазина.ру Адрес магазина так же можно указать в настройках шаблона в Админке - Настройки - Общие - Домен магазина. Запустить магазин (приложения store и api): npm start или лучше запустить в фоновом режиме: pm2 start process.json Проверить работает или нет, будет видно, работают или нет приложения store и api: pm2 list Статус online - значит работают. Перезапустить процесс (например после сборки проекта): pm2 reload api pm2 reload store
  13. Как вносить правки в админку магазину и видеть сразу же изменения, просто обновил страницу в браузере. Без необходимости собирать исходники и делать рестарт приложения. 1. Запускать сборку с вотчером и оставлять терминал открытым: npm run build:watch Все правки будут компилиться "на лету". 2. Запустить менеджер pm2 с параметром --watch pm2 start process.json --watch Всё, теперь все вносимые правки в админке (папка с исходниками /src/admin), в каталоге (/theme/src) будут компилироваться автоматически, "на лету" и сразу же будут видны в браузере, после обновления страницы.
  14. Не за что. Да, всё в css colorbox.css Вообще, похоже на часть рамки. т.е. ищите стили для с выводом этой рамки и меняйте: images/border.png Я для пробы всё убрал, фон поменял, всё черёное, всё нормально. В люом случае, всё, что касается оформления colorbox находится в colorbox.css
  15. support

    настройка 1

    Есть. В /app/webroot/css/vamshop.css задать фон, тогда текст будет виден, как в demo2.vamshop.ru Для стиля: .featured-categories .thumbnail .title Укажите backgrounr-color: #fff; Тогда Ваша надпись категории будет на белом фоне и будет читаемый текст. А вообще, надо ж хоть немного основы знать html + css, тогда всё было бы намного проще. Без основ Вы ж ничего не сможете сделать.
  16. А может ещё по такому вопросу сможете сориентировать? Ума не приложу, где ещё можно покопать. Пришло в голову, что цвет фона в pop-up окне, при теме моего сайта и дизайне, будет уместней чёрный. Всё нашёл, где поправить (в основном, тот же файл css), спрайт с картинками перерисовал-перекрасил. Всё отлично. Но по нижнему и верхнему краю окна, тянется белая полоса. Не могу понять, откуда она. Перекопал сам css colorbox, сам скрипт на всякий случай посмотрел, в основной css заглянул, искал по цвету фоновому, по border. Тут пример
  17. borovel1

    настройка 1

    Попробовали но что то не получается! Есть ли какие то другие варианты?
  18. Благодарю, Александр! Избавили меня от ковыряния в кодах пару дней )) Проблему места для текста (его в принципе не очень и много - не длиннее названия товара обычно) решил очень просто - покопавшись в colorbox.css и назначив #cboxLoadedContent побольше margin-bottom, что для меня вполне приемлемое решение. А если просто (не делая выше названного) назначить поля по вертикали пикселей в 30-40 для #cboxTitle, то имя смещается на картинку и визуально это получается как упомянутая вами опция caption. Но в моём случае, это оказывается неудобным, так как фотографии очень разные по цвету и нельзя задать цвет текста, который подошёл бы к любому случаю.
  19. support

    настройка

    Метка: {$node.short_description|strip_tags|truncate:120:"...":true} По умолчанию ведь фон задан и всё видно - demo2.vamshop.ru Либо эту метку поставьте под картинкой, либо фон раскрасьте в /app/webroot/css/vamshop.css что б видно всё было.
  20. borovel1

    настройка

    здравствуйте! надпись категории накладываеться на картинку категории. можно надпись сделать под картинкой категории. Вы нам написали что нужно: ""В Админке - Оформление - Микро-шаблоны - subcategory-listing просто метку с название опустите чуть ниже и поставьте над описанием категории (decsription) "". подскажите пожалуйста какую метку с названием нужно опустить ? не видно названия категории в микро шаблоне( ((См. Второй файл Микро шаблон.txt
  21. Здравствуйте! Возможно, но там нет месте для большого текста, там даже название товара длинное не влазит, не то что описание. В /templates/шаблон/javascript/script.php меяняйте: $(".lightbox").colorbox({rel:"lightbox", title: false}); на: $(".lightbox").colorbox({rel:"lightbox"}); И в /templates/шаблон/module/product_info/product_info_v1.html в title атрибут картинки добавьте нужный текст. Например: {if $PRODUCTS_POPUP_LINK!=''}<a href="{$PRODUCTS_POPUP_IMAGE}" title="{$PRODUCTS_NAME}" class="lightbox">{/if}<img itemprop="image" id="img" src="{$PRODUCTS_IMAGE}" alt="{if $PRODUCTS_IMAGE_DESCRIPTION !=''}{$PRODUCTS_IMAGE_DESCRIPTION}{else}{$PRODUCTS_NAME}{/if}" /> Меняйте на: {if $PRODUCTS_POPUP_LINK!=''}<a href="{$PRODUCTS_POPUP_IMAGE}" title="{$PRODUCTS_NAME} здесь текст или метку добавить" class="lightbox">{/if}<img itemprop="image" id="img" src="{$PRODUCTS_IMAGE}" alt="{if $PRODUCTS_IMAGE_DESCRIPTION !=''}{$PRODUCTS_IMAGE_DESCRIPTION}{else}{$PRODUCTS_NAME}{/if}" /> или просто метку {$PRODUCTS_IMAGE_DESCRIPTION} добавить вместо текста. Но всё равно, по умолчанию нет месте для текста особо. Разве что на сайте colorbox смотреть примеры, описания настроек, может настройками что-то можно сделать. Может там есть опция типа caption - заголовка, т.е. текст который прям на картинке выводится.
  22. Последняя неделя
  23. Доброго времени суток! Подскажите, а возможно текст из описания картинки товара, вывести под изображением в popup (в карточке товара)
  24. Здесь нет такой проблемы, используется SSR (Server Side Rendering), т.е. генерация страниц на стороне сервера, всё индексируется, проверено на cezerin.ru демке. Вот ещё пример демки с сотнями товаров - https://izzi.com.ua/chehly Например справа сверху сортировка. Да, у них там есть небольшие проблемы с юзабилити, что страница вверх не прокручивается если фильтр слева внизу где-то выбрать, но всё равно, даже так видно, как всё работает быстро. т.е. если сравнивать с VamShop, это как ajax корзина на http://demo.vamshop.ru Нажали купить - и появилась корзина справа без перезагрузки страницы, но здесь ajax корзина - это весь сайт целиком, любая страница, любой блок. Это если коротко, т.е. можно вообще что б не было никаких перезагрузок страницы, всё внутри одной страницы с минимумом кликов мышкой. В статье по ссылке конечно зря налегают на то, что есть проблемы с SEO, нет таких проблем именно при таком подходе как в демке cezerin.ru. т.е. грубо говоря, обычное web приложение тормозит, крутится значок ajax, оно не заработает пока всё приложение целиком не прогрузится и это приложение сложно индексировать поисковым роботам потому что все адреса внутри "виртуальные". С SSR подходом нет необходимости грузить всё и сразу, всё грузится по необходимости, т.е. моментально отображается основная страница и уже внутри запущенной страницы грузится всё что нужно, без тормозов, именно благодаря такому подходу + react получается очень и очень быстрые сайты и для поисковиков такие приложения выглядят как обычные сайты. Да, это совсем другие технологии по сравнению с php+mysql и намного сложнее если никогда не работал с новыми библиотеками. Но это будущее, точнее уже настоящее. т.е. сейчас для всего, для сайтов, для компов, смартфонов будут одни и те же приложения, разработка ничем не отличается, что для сайта, что для приложения. Унификация всего и вся. и будет в том числе и для сайтов магазин приложений типа apple store и google play, я так думаю. В общем, сейчас как раз момент, когда происходит коренной пересмотр подходов к разработке сайтов. Теперь это уже не просто сайты, а приложения PWA (Progressive Web App) + SPA (Single Page Application). Да, для простых пользователей это конечно всё очень сложно и ничего не понятно, тут не поспоришь, нужно изучать совершенно новые подходы и технологии, но результат того стоит. В результате этих новых подходов к разработке получаются супер быстрые сайты, с качественными эффектами, анимациями, без лишних перезагрузок и кликов мышкой, а это самое важное - именно в этом будет главное конкурентное преимущество перед "обычными" сайтами. Скороть и удобство для пользователя. Это конечно никак не связано с VamShop. В VamShop тоже много своих плюсов, прежде всего простота и VamShop тоже очень быстрый, особенно на php 7. Это тоже не является проблемой. Просто это другой подход к разработке, более современный. Ещё одна ветка развития движков для создания магазина. Это новый подход к созданию сайтов/приложений. Обязательно буду следить за темой и постепенно изучать новый стэк технологий react + nodejs + mongodb. Но это конечно да, больше для всяких программистов, конечному пользователю по сути всё равно, что там и как сделано внутри. и в этом смысле VamShop намного интереснее, он гораздо проще, как автомат Калашникова, простой и понятный, нет ничего сложного, в этом тоже огромный плюс на самом деле, просто не сравнить насколько просто всё делается в VamShop.
  25. Наткнулся на статью по этим движкам- сам до конца не осилил, очень большая статья- но посыл общий, что для SEO не очень хорошо, вроде бы как ни гугл, ни, особенно, яндекс индексировать такие движки не умеют, по итогам, для маленьких компаний не рекомендуют. "Среднестатистическим сайтам задумываться об использовании JS-движков скорее всего не нужно — для рядовых задач есть более подходящие и простые решения. Смысл использования JS-движков появляется, если планируется создать по настоящему быстрый функциональный сайт для огромной аудитории. При этом стоит помнить, что полноценная поддержка подобных сайтов — дело не из дешевых." https://serpstat.com/ru/blog/sajti-na-javascript-dvizhkah/?utm_content=JavaScript-SEO-druzya-ili-vragi
  1. Загрузить ещё активность