Александр, не совсем понятно про что именно Вы написали? Если Вы пишите про "Активность" на указанном Вами сайте, то да, она работает, и возникает вопрос: применяли ли Вы хак из этой темы и если да, то первый или второй вариант?
Пишите подробнее, пожалуйста. Вас будет легче понять.
Что касается указанной Вами странички, то судя по её коду она открывается в обход движка ICMS, напрямую с диска. Хак тут непричём.

WebMan
В данный период я не оказываю услуг и не занимаюсь сторонними разработками
+434
Репутация
6108
Рейтинг
Спасибо за исправление Val! Проверил. Таки да, активность без исправления не работала. Теперь всё нормально. 😊
Ага, это решает задачу для новых сайтов. Я тоже буду стараться делать таким образом. Но для обновления CMS на старых это не всегда подойдёт. Хотя и там можно обойтись без хака, понаделывать 301-х редиректов в .htaccess, если страниц немного.
Вы по-своему правы, sofcom, любые нестандартные вещи на сайте в будущем могут создать проблемы. Но ведь это не повод для отказа от них, если это нужно, верно? Вместо этого можно поискать наиболее простые и надёжные варианты решения, что мы сейчас и делаем
А задачи бывают разные. Иногда заказчики хотят видеть страницы в корне сайта, иногда переводится на новую CMS существующий сайт с сохранением старых страниц по их прежним адресам. Да мало ли какие нужды бывают. Поэтому лучше иметь возможность выбора как сделать желаемое, чем не иметь её.
С точки зрения СЕО — спорный вопрос. Все современные поисковики прекрасно переваривают и выводят в выдачу страницы с любыми адресами, даже без ЧПУ. Но адреса с ЧПУ нагляднее, в том числе и для пользователей в результах выдачи. И как по мне, так некоторые адреса в корне смотрятся лучше. Например, site.ru/about.html в корне выглядит проще и понятнее, чем site.ru/pages/about.html в непонятном разделе pages. Это моё субъективное восприятие, конечно. Каждый воспринимает по-своему. Но и это тоже вполне подходящая причина иметь возможность выбора разных вариантов для разных пользователей.
А задачи бывают разные. Иногда заказчики хотят видеть страницы в корне сайта, иногда переводится на новую CMS существующий сайт с сохранением старых страниц по их прежним адресам. Да мало ли какие нужды бывают. Поэтому лучше иметь возможность выбора как сделать желаемое, чем не иметь её.
С точки зрения СЕО — спорный вопрос. Все современные поисковики прекрасно переваривают и выводят в выдачу страницы с любыми адресами, даже без ЧПУ. Но адреса с ЧПУ нагляднее, в том числе и для пользователей в результах выдачи. И как по мне, так некоторые адреса в корне смотрятся лучше. Например, site.ru/about.html в корне выглядит проще и понятнее, чем site.ru/pages/about.html в непонятном разделе pages. Это моё субъективное восприятие, конечно. Каждый воспринимает по-своему. Но и это тоже вполне подходящая причина иметь возможность выбора разных вариантов для разных пользователей.
Спасибо, Val, хак работает. Страницы доступны и по сокращённому адресу (в корне сайта), и по старому полному. При этом остаётся возможность редактировать и удалить страницы обычным способом.
Решение найдено. В принципе, можно было бы закрывать тему. Но подожду немного, может кто-то сможет сделать то же самое через .htaccess. Мне кажется, что для непрограммистов менять что-то в .htaccess проще, чем в скриптах. Да и при обновлении системы хаки теряются и их нужно делать заново.
Решение найдено. В принципе, можно было бы закрывать тему. Но подожду немного, может кто-то сможет сделать то же самое через .htaccess. Мне кажется, что для непрограммистов менять что-то в .htaccess проще, чем в скриптах. Да и при обновлении системы хаки теряются и их нужно делать заново.
Когда-то тут была подобная тема. Но сейчас я её не нашёл, поэтому создал новую. К модератору: если та тема не скрыта, перенесите это соощение в неё.
По теме. Стандартными способами в Двойке невозможно сделать страницы в корне сайта (с адресом типа site.ru/page.html) без указания типа контента в адресе. В некоторых случаях это создаёт проблемы при разработке. Зато можно попробовать вариант с заменой части адреса в htaccess. Идея в том, чтобы создать тип контента, который будет использоваться для подобных страниц. Назвать его, например, root. И потом в htaccess написать правила для RewriteRule, чтобы если в адресе есть строка '.html', то есть расширение с точкой, указывающее, что запрашивается страница, а не раздел, и при этом на втором и далее местах в строке отсутствует слеш '/', то есть, запрашиваемая страница находится в корне, тогда перед адресом страницы после домена сайта добавляем 'root/'
То есть, если приходит URI вида /page.html, то меняем его на /root/page.html. Естественно, делать это не редиректом, чтобы для пользователя адрес остался прежним, в корне сайта.
Особенности варианта:
1. Страницы должны быть только одного типа контента. В большинстве случаев этого хватает.
2. В htaccess нужно менять REQUEST_URI, так как все запросы страниц и раделов перенаправляются на index.php, а ядро потом определяет реальный адрес по REQUEST_URI.
У меня не хватает знаний по htaccess, сходу сделать так не получилось. Может кто-то сможет реализовать идею? Если это возможно, конечно.
Если это невозможно, тогда остаётся только хак ядра, что не очень хорошо.
Как вариант для разработчиков InstantCMS 2 для будущих версий, можно будет сделать опцию в настройках, где админ сможет указать тип контента, который будет использоваться в случае, если запрашивается страница без типа, то есть, страница из корня сайта.
По теме. Стандартными способами в Двойке невозможно сделать страницы в корне сайта (с адресом типа site.ru/page.html) без указания типа контента в адресе. В некоторых случаях это создаёт проблемы при разработке. Зато можно попробовать вариант с заменой части адреса в htaccess. Идея в том, чтобы создать тип контента, который будет использоваться для подобных страниц. Назвать его, например, root. И потом в htaccess написать правила для RewriteRule, чтобы если в адресе есть строка '.html', то есть расширение с точкой, указывающее, что запрашивается страница, а не раздел, и при этом на втором и далее местах в строке отсутствует слеш '/', то есть, запрашиваемая страница находится в корне, тогда перед адресом страницы после домена сайта добавляем 'root/'
То есть, если приходит URI вида /page.html, то меняем его на /root/page.html. Естественно, делать это не редиректом, чтобы для пользователя адрес остался прежним, в корне сайта.
Особенности варианта:
1. Страницы должны быть только одного типа контента. В большинстве случаев этого хватает.
2. В htaccess нужно менять REQUEST_URI, так как все запросы страниц и раделов перенаправляются на index.php, а ядро потом определяет реальный адрес по REQUEST_URI.
У меня не хватает знаний по htaccess, сходу сделать так не получилось. Может кто-то сможет реализовать идею? Если это возможно, конечно.
Если это невозможно, тогда остаётся только хак ядра, что не очень хорошо.
Как вариант для разработчиков InstantCMS 2 для будущих версий, можно будет сделать опцию в настройках, где админ сможет указать тип контента, который будет использоваться в случае, если запрашивается страница без типа, то есть, страница из корня сайта.
Хотелось бы что-то типа github.com/maximebf/php-debugbar
а то не удобно постоянно жать на запросы в футере.
было бы классно еще получать статистику по времени выполнения экшонов, хуков, виджетов..., чтобы можно было отслеживать "тормознутые".
Посмотрите Класс расширенной отладки для InstantCMS 2.0.1 (v.6).
Краткий список возможностей:
--------
• Расширенная информация о времени работы CMS и её частей/операций
• Лог автозагрузок классов и инклудов файлов и суммарная таблица инклудов.
• Лог обращений к БД (SQL-запросов и коннектов).
• Лог работы с кэшем.
• Лог и суммарные таблицы событий и хуков.
• Лог и суммарная таблица виджетов.
• Подсчитывается время работы контроллера (полезно для создателей компонентов).
• Подсчитывается время рендеринга шаблона (пригодится разработчикам шаблонов).
• Фильтры для логов операций – позволяют выводить только интересующую информацию.
• Информация об ошибках, о входных данных и результатах работы отслеживаемых операций в логах.
• Контрольные точки в коде для получения подробной информации о php-скриптах.
• Информация о памяти скрипта (суммарная и в контрольных точках).
• Настраиваемые логи отладки выводятся под подвалом страницы, не изменяя саму страницу.
• Управление параметрами отладки производится через новую вкладку «Отладка» в админке.
• При отключении отладки она практически не влияет на скорость работы CMS.
• Цветовое оформление логов и другой информации сделано через отдельный css-файл.
• Текстовые строки из настроек в админке вынесены в языковые файлы.
Можете внести свои обоснованные предложения и дополнения. Возможно реализую и их тоже.
Всё общение по "Отладке" — в моём блоге, чтобы не захламлять эту тему.
Уважаемый Tor, я не совсем понял, что именно Вы хотели сказать. Возможно, это из-за недостаточно точной пунктуации в Вашем сообщении. Попробуйте переформулировать Ваш посыл или уточнить его смысл расстановкой знаков препинания.
Если отвечать на то, что я понял, то могу сказать, что не все "человеки" умеют программировать. Да это и не необходимо. У некоторых гораздо больше таланта в том, чтобы используя наработки других людей, создавать свои классные, интересные и посещаемые сайты. У них другие способности и цели. Поэтому пусть каждый занимается своим делом: разработчики Инстанта — создают клёвый универсальный движок, умеющие программировать — расширяют его функционал, "человеки" — из этого всего создают свои сайты, а имеющие много необоснованных претензий к другим людям — держат их при себе. Всем интересно и все довольны. 😊
Если отвечать на то, что я понял, то могу сказать, что не все "человеки" умеют программировать. Да это и не необходимо. У некоторых гораздо больше таланта в том, чтобы используя наработки других людей, создавать свои классные, интересные и посещаемые сайты. У них другие способности и цели. Поэтому пусть каждый занимается своим делом: разработчики Инстанта — создают клёвый универсальный движок, умеющие программировать — расширяют его функционал, "человеки" — из этого всего создают свои сайты, а имеющие много необоснованных претензий к другим людям — держат их при себе. Всем интересно и все довольны. 😊
"SEO-теги для фотогалереи, фотоальбомов и фотографий" появятся в блоге picaboo как только он проверит мой пост.
Для afinskiy, там есть описание где и что править для изменения вывода в атрибутах ALT и TITLE картинок. В сам патч я эти изменения не вносил, так как у каждого могут быть свои предпочтения.
Для afinskiy, там есть описание где и что править для изменения вывода в атрибутах ALT и TITLE картинок. В сам патч я эти изменения не вносил, так как у каждого могут быть свои предпочтения.
Для фотогалереи и фотоальбомов сео сделал.
Вопрос по фотографиям — что делать с ними? Добавить отдельные поля чтобы можно было заносить для каждой фотографии вручную? Это увеличит размеры базы данных и увеличит поле редактирования инфы о фотографии, стоит ли оно того? Автоматом подставлять из тегов и описания в соответствующие мета-теги? Или это всё для фоток — лишнее, можно не морочить голову?
Вопрос по фотографиям — что делать с ними? Добавить отдельные поля чтобы можно было заносить для каждой фотографии вручную? Это увеличит размеры базы данных и увеличит поле редактирования инфы о фотографии, стоит ли оно того? Автоматом подставлять из тегов и описания в соответствующие мета-теги? Или это всё для фоток — лишнее, можно не морочить голову?
Спасибо, тогда так и сделаю, если не наберу на свой блог к тому времени. 😊
picaboo, с сеоурлами, к сожалению, не помогу. Это надо чётко представлять принцип работы с урлами всей CMS и каждого компонетна в оnдельности, а я настолько глубоко пока не копал.
Эх, жаль, на блог не накопил. Постараюсь сегодня-завтра доделать и выложить сюда патч SEO для фотоальбомов. Надеюсь, он тут не затеряется.
Эх, жаль, на блог не накопил. Постараюсь сегодня-завтра доделать и выложить сюда патч SEO для фотоальбомов. Надеюсь, он тут не затеряется.
Если этот патч вам полезен, то добавьте кармы до создания блога, пожалуйста. Выложу в него ещё несколько патчей, так как на форуме они потеряются.
SEO для разделов каталога
—
В архиве патч для версии 1.10.1.
Для чистой CMS просто распакуйте файлы из архива с заменой. Этот файл (uc-seo_readme.txt) можно после распаковки удалить или не копировать вообще.
Если вы уже вносили изменения в какой-то из файлов, которые правит фикс, то НЕ накатывайте файлы из архива, а внесите изменения руками в подходящие места.
Выполнение двух запросов к базе данных обязательно в обоих вариантах.
Выполняем два SQL-запроса в phpmyadmin (при необходимости измените префикс cms_ в именах таблиц на ваш):
Правим три файла. Вносить изменения в файлы нужно именно в той последовательности, в которой я написал. Иначе при добавлении строк вначале файла нумерация более дальних сдвинется. Табуляцию для красоты сделайте сами 😊
Файл \admin\components\catalog\backend.php
Перед строкой 1383
добавить строки
В строке 552
исправить "ordetto" на "orderto". Это сделаем исправление сортировки, походу.
После строк 628 и 552
добавить строки (в двух местах!)
Файл \components\catalog\model.php
Строку 322
меняем на
Строки 305 и 267
заменяем на три строки (в двух местах!)
Файл \components\catalog\frontend.php
После строки 472
вставляем строки
—
В архиве патч для версии 1.10.1.
Для чистой CMS просто распакуйте файлы из архива с заменой. Этот файл (uc-seo_readme.txt) можно после распаковки удалить или не копировать вообще.
Если вы уже вносили изменения в какой-то из файлов, которые правит фикс, то НЕ накатывайте файлы из архива, а внесите изменения руками в подходящие места.
Выполнение двух запросов к базе данных обязательно в обоих вариантах.
Выполняем два SQL-запроса в phpmyadmin (при необходимости измените префикс cms_ в именах таблиц на ваш):
ALTER TABLE `cms_uc_cats` ADD `meta_keys` VARCHAR(250) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL DEFAULT ''; ALTER TABLE `cms_uc_cats` ADD `meta_desc` VARCHAR(250) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL DEFAULT '';
Файл \admin\components\catalog\backend.php
Перед строкой 1383
{tab=Доступ}
{tab=SEO} <div style="margin-top:5px"> <strong>Ключевые слова</strong><br/> <span class="hinttext">Через запятую, 10-15 слов</span> </div> <div> <textarea name="meta_keys" style="width:97%" rows="2" id="meta_keys"><?php echo @$mod['meta_keys'];?></textarea> </div> <div style="margin-top:20px"> <strong>Описание</strong><br/> <span class="hinttext">Не более 250 символов</span> </div> <div> <textarea name="meta_desc" style="width:97%" rows="4" id="meta_desc"><?php echo @$mod['meta_desc'];?></textarea> </div>
$cat['ordetto'] = $inCore->request('ordetto', 'str');
После строк 628 и 552
$cat['orderto'] = $inCore->request('orderto', 'str');
$cat['meta_keys'] = $inCore->request('meta_keys', 'str'); $cat['meta_desc'] = $inCore->request('meta_desc', 'str');
Файл \components\catalog\model.php
Строку 322
$item = $this->inDB->get_fields('cms_uc_cats', "id = '$id'", 'parent_id, title, description, published, fieldsstruct, view_type, fields_show, showmore, perpage, showtags, showsort, is_ratings, orderby, orderto, showabc, shownew, newint, filters, is_shop, is_public, can_edit, cost');
$item = $this->inDB->get_fields('cms_uc_cats', "id = '$id'", 'parent_id, title, description, published, fieldsstruct, view_type, fields_show, showmore, perpage, showtags, showsort, is_ratings, orderby, orderto, showabc, shownew, newint, filters, is_shop, is_public, can_edit, cost, meta_keys, meta_desc');
cost = '{$cat['cost']}'
cost = '{$cat['cost']}', meta_keys = '{$cat['meta_keys']}', meta_desc = '{$cat['meta_desc']}'
Файл \components\catalog\frontend.php
После строки 472
$inPage->addHeadCSS('includes/jquery/lightbox/css/jquery.lightbox.css');
if ($cat['meta_keys']) { $inPage->setKeywords($cat['meta_keys']); } if ($cat['meta_desc']) { $inPage->setDescription($cat['meta_desc']); }
Прикрепленный файл
ucseo_q0nkq.zip
32 Кб