Для этой цели пользуюсь locationbar2.
К сожалению, из zencd.habrahabr.ru/blog/79606/ она может переместить в zencd.habrahabr.ru/blog/, zencd.habrahabr.ru/ — но не может на habrahabr.ru/
Код… Читаемый. За качество не скажу, не за несколько минут оно изучается.
А при попытке установки на денвер, инсталятор выдаёт: «Введите правильные данные для заполнения: Виртуальный путь (URL)».
Да, на предыдущем шаге сказано «без закрывающего слеша», а согласился инсталятор только при указании оного.
При первичном изучении админки всплывает вопрос: как дела с удобством управления, если на сайте несколько тысяч страниц?
Есть ли какая-то документация по Ronny-фреймворку, созданию модулей?
Ну и ещё меня заинтересовал, конечно, RunSTORE. Потому что osCommerce — тихий ужас, с Мадженто я не сжился, а за собственный плуг магазина — стыдно. Будет ли RunSTORE доступен вместе с Ronny?
О! А я как раз ищу на сайте ссылку на репозиторий :)
Конечно, меня не вдохновляет архивами с народа качать. К тому же интересно читать комментарии к ревизиям.
У меня однажды не выпадало в восьмом ишаке меню, генерируемое программно (на ASP.NET, а потому жуткими таблицами и js). Во всех остальных ишаках и в браузерах выпадало. Долго бился, после чего плюнул и сделал
/>
Работает.
У меня на одном сайте в две разные зоны сайта два разных пароля. До версии 3.5 выходил из положения так: в одну зону сайта логин Wave со своим паролем, в другую wave со своим. Имеется в виду, ФФ нормально сохранил пароли в таких условиях. Но стоило обновиться на 3.5, как ФФ стал всё время менять логин на нижний регистр. И соответственно, пароль каждый раз приходилось вбивать вручную и он пересохранялся в том логине, что с маленькой буквой. Второй логин висел незадействованный. Удалить все пароли этого сайта и каждый раз вбивать вручную — вариант, но не самый удобный.
На форуме мозиллы мне посоветовали
Есть такой аддон — Sxipper. Он позволяет создавать хоть десяток «персон» для одного сайта. Позволяет сохранять любые персональные данные — от логина/пароля до номеров кредитки и банковского счёта. Долго им пользовался. Единственный недостаток — много различных настроек и всё по-буржуйски. Удобен при регистрации на различных ресурсах — просто выбираешь «персону», остальное делает Sxipper.
Эти блоки никак не похожи на содержимое графических файлов.
Т.е. я о том, что произвольное содержимое (то, которое можно произвольно менять) ещё можно подогнать под коллизии. А вот содержимое, строящееся по определённым правилам, под коллизии подобрать гораздо сложней.
Почему-то в деме когда я кликаю на любую картинку, всплывает лайтбоксовый попап с перечёркнутым фотоаппаратом. Тогда как если в отдельном окне картинку открываю — грузится нормально.
И скриншотов с настройками что-то не вижу.
А вообще — спасибо, внятный способ, не нужно тонуть в море возможностей, не зная, что выбрать.
вовсе не означает что разработчики лепят внутри что попало и как попало, типа зенд все стерпит. Согласны? ;)
Угу. Я, правда, этого и не утверждал.
Чтобы программисту не нужно было разбираться в полностью новом коде при переходе с CMS на CMS
Есть ещё фреймворки и cms, написанные на них. Правда и самих фреймворков хватает. :)
Не совсем согласен в плане нескольких моментов
Я тоже не называл себя истиной в последней инстанции. :)
Извините, гугл пометил их как спам. Сейчас получил через веб-интерфейс.
Вы просили обстоятельных комментариев, а не придирок. Я попытаюсь, как сумею.
Именование — дело индивидуальное. В плюсах хорошее комментирование и документирование кода.
ООП, судя по всему, используется не в процедурном стиле, а более-менее действительно ООП.
А вот куски html в конструкторе как-то напрягают. Жёстко прописаны имена картинок и их размеры. Пусть даже это для пагинации и пути настраиваемые.
Работа с деревьями неплоха, только перемещение\копирование ноды получается ресурсоёмким. Но надо так понимать, делается из админки, следовательно, не так часто.
Модуль новостей — с наскоку не зная всей архитектуры не очень разобрался, но из общих впечатлений: работает кэширование. Функций шаблонизатора — их разбросано ровным слоем по коду. Как и запросы, которые хоть и через библиотеку, но строятся на местах. Т.е. при написании любого модуля много муторной работы, которую на себя должна бы взять одна-другая библиотека, а то и ядро…
Обработка ошибок, глобальный роутинг и инициализация, а также прочее ядро, естественно, в паре классов и одном модуле отсутствуют. Так что не могу судить
Итого, общее впечатление после нескольких минут изучения: код довольно тщательный (и заявленные на сайте системные требования подтверждают ;), но поддерживать и расширять его можно только хорошо изучив всю систему. Даже не так. Система не делает довольно много вспомогательной работы, которую я бы хотел видеть для написания своих модулей.
Написал. Честно предупредил, что интересуюсь из любопытства, с целью расширения кругозора, с тем, чтобы, возможно, запостить на хабре отзыв…
Ответа так и не получил.
К сожалению, из zencd.habrahabr.ru/blog/79606/ она может переместить в zencd.habrahabr.ru/blog/, zencd.habrahabr.ru/ — но не может на habrahabr.ru/
А что по коду осталось-неосталось — я только что и слышал немного о существовании форков и клонов. И что вообще-то нюка не блещет. Вот и всё.
А при попытке установки на денвер, инсталятор выдаёт: «Введите правильные данные для заполнения: Виртуальный путь (URL)».
Да, на предыдущем шаге сказано «без закрывающего слеша», а согласился инсталятор только при указании оного.
При первичном изучении админки всплывает вопрос: как дела с удобством управления, если на сайте несколько тысяч страниц?
Есть ли какая-то документация по Ronny-фреймворку, созданию модулей?
Ну и ещё меня заинтересовал, конечно, RunSTORE. Потому что osCommerce — тихий ужас, с Мадженто я не сжился, а за собственный плуг магазина — стыдно. Будет ли RunSTORE доступен вместе с Ronny?
Конечно, меня не вдохновляет архивами с народа качать. К тому же интересно читать комментарии к ревизиям.
Сделал
meta http-equiv=«X-UA-Compatible» content=«IE=EmulateIE7» /
/>
Работает.
На форуме мозиллы мне посоветовали
Т.е. я о том, что произвольное содержимое (то, которое можно произвольно менять) ещё можно подогнать под коллизии. А вот содержимое, строящееся по определённым правилам, под коллизии подобрать гораздо сложней.
И скриншотов с настройками что-то не вижу.
А вообще — спасибо, внятный способ, не нужно тонуть в море возможностей, не зная, что выбрать.
Угу. Я, правда, этого и не утверждал.
Чтобы программисту не нужно было разбираться в полностью новом коде при переходе с CMS на CMS
Есть ещё фреймворки и cms, написанные на них. Правда и самих фреймворков хватает. :)
Не совсем согласен в плане нескольких моментов
Я тоже не называл себя истиной в последней инстанции. :)
Вы просили обстоятельных комментариев, а не придирок. Я попытаюсь, как сумею.
Итого, общее впечатление после нескольких минут изучения: код довольно тщательный (и заявленные на сайте системные требования подтверждают ;), но поддерживать и расширять его можно только хорошо изучив всю систему. Даже не так. Система не делает довольно много вспомогательной работы, которую я бы хотел видеть для написания своих модулей.
Ответа так и не получил.