А, вон о чем речь. Я так понимаю, что этот ключ, по идее, должен предотвращать возникновение «подвисших» веток комментов, когда удаляется родительский комментарий. И получается, что при удалении комента из середины ветки, должны удалиться все комменты, для которых он является родителем.
Но, кстати, натолкнули на мысль: тут действительно могут быть проблемы при удалении топика с деревом комментариев — комментарии из дерева должны удаляться в определенном порядке. Надо будет перепроверить
С паролем проблем никаких быть не должно: вообще-то при регистрации на сайте пароль «подсаливается» и хешируется посложнее, чем просто md5, но если в таблицу с пользователями в поле user_password записать чистый md5, то движок это поймет и нормально выполнит авторизацию.
А вот со статьями не очень понятно. Только статьи не создаются? Другие разделы работают нормально? А админка работает? Или вообще ничего не работает, кроме главной?
Да в том-то и дело, что шаблон не всегда может помочь, т.к. редирект получается выборочный. Например, site.com/thebest — это топик и его надо редиректить на site.com/thebest.html, а вот site.com/people редиректить уже не надо, а надо отдавать движку, как есть.
И получается, что анализ надо самим движком делать — если совпадает запрашиваемый УРЛ с топиком — редирект, а если нет — обрабатывать как есть. Есть уже практически готовый плагин для этого, скоро опубликую.
Это все абсолютно верно. Если рассуждать с позиции «от кутюр». Мы же имеем дело с «прет-а-порте». Хорошо ли, плохо ли, нравится или нет, но это факт.
К тому же надо понимать, что эффективно заниматься моделированием данных можно только тогда, когда у тебя есть абсолютно четкое представление обо всей структуре данных и обо всех методах манипулирования ими. А когда тут моделируется, а тут — нет, то все моделирование улетает в трубу.
Конечно, это было б здорово, если б никто не мусорил. Но т.к. на практике мы этого добиться не можем, то нужно реализовать качественную уборку.
А вообще, если говорить об интеграции, то в общем случае должна быть полная абстракция от механизмов хранения данных, и это на уровне API должно выполняться.
Возможно, из-за каких-то манипуляций с БД (либо просто из-за сбоя) что-то сломалось во внешних ключах, потому эта проблема и возникла. И из админки, наверное, они не удаляются по той же причине.
Негативные последствия — это не будут удаляться комменты вместе топиками. Но эти последствия, как я понимаю, и так имеют место быть. Так что, я полагаю, ничего хуже этого уже не будет.
А логика очень простая, если задаться вопросом: для чего используются внешние ключи в движке? Вот не вообще зачем они нужны, а реально для чего используются в таких движках, как ЛС и Альто? Ответ: для каскадного удаления связанных записей в таблицах. А кто-нибудь встречал хоть один сторонний плагин, который создает новые таблицы, связанные логически с сущностями движка, и который бы создавал при этом свои внешние ключи? Я не видел ни одного.
Что получаем в итоге: при активном использовании сторонних плагинов целостность базы все равно часто нарушается, а гибкость кастомизации системы в целом ухудшается. Так какой смысл тянуть механизм внешних ключей? А организовать каскадное удаление сущностей не так уж и сложно. Нагрузка при удалении будет выше, но это не такая уж и частая операция.
Надо тестировать, чтобы убедиться, не будет ли проблем с новыми версиями. Могу предположить, что с MarkItUp, скорее всего, проблем не возникнет, и достаточно будет просто обновить содержимое папки common/templates/frontend/libs/vendor/markitup.
А вот насчет TinyMCE уверенности меньше. Но вполне допускаю, что и там обновление может пройти безпроблемно. Только надо обновиться аккуратно — некоторые плагины TinyMCE, написанные специально для Альто, нужно будет перенести в новую версию.
Проблема в FOREIGN KEYS — внешних ключах. Нужно либо их обновлять, чтобы задать связи для таблиц с разными префиксами, либо удалить совсем. Второй вариант проще, но не тестировался совсем, хотя скоро и планируется отказаться от внешних ключей.
1. Смотрите логи ошибок в /_tmp/logs/error.log
2. Веб-сервер должен перенаправлять запросы к несуществующим папкам и файлам на /index.php, для apache это делается через .htaccess (идет с движком, но должен быть включен mod_rewrite), для nginx — соответствующие настройки конфига
Это надо смотреть обработчик и разбираться в его настройках, либо изучить возможность как-то влиять на возвращаемое значение. Если там где=то задается путь, куда будет сохраняться, то, возможно, нужно слеш поставить в его начале — не просто «uploads», а "/uploads", тогда скрипт будет понимать, что это путь от корня сайта
1) составить регулярку так, чтоб делала нужную выборку с учетом всех условий. Например, конкретно этот пример решается такой регуляркой: ^[а-яА-ЯёЁ0-9]+продаж.*$ — сработает, только если хоть одна буква или цифра перед корнем есть, т.е. распродажа попадает под паттерн, а продажник — нет.
2) делать два массива — один с искомыми патернами, второй — с исключающими, и перебором проверять на оба набора.
Потребность такая возникает нередко, но готовой возможности такой нет. Qevix мне нравится все больше, тем более, что он поддерживается и расширять его проще, чем Jevix, и там можно гораздо удобней вешать дополнительные обработчики текста. Планирую в одной из будущих версий сделать его парсером по умолчанию и добавить новые возможности, включая эту.
Проблема в том, что система не может правильно распознать URL. Например, вот этот адрес site.com/people система воспринимает за адрес топика и пытается его открыть, но не находит.
Во избежание подобных коллизий лучше добавить .html к шаблону топика. Тогда система будет понимать, что site.com/people.html — это точно топик запрашивается, а site.com/people — это раздел «Люди»
Не очень понятен вопрос — о каких файлах речь? Если о загрузке изображений, то она работает через класс ActionUploader (файл common/classes/actions/ActionUploader.class.php).
Но, кстати, натолкнули на мысль: тут действительно могут быть проблемы при удалении топика с деревом комментариев — комментарии из дерева должны удаляться в определенном порядке. Надо будет перепроверить
А вот со статьями не очень понятно. Только статьи не создаются? Другие разделы работают нормально? А админка работает? Или вообще ничего не работает, кроме главной?
И получается, что анализ надо самим движком делать — если совпадает запрашиваемый УРЛ с топиком — редирект, а если нет — обрабатывать как есть. Есть уже практически готовый плагин для этого, скоро опубликую.
К тому же надо понимать, что эффективно заниматься моделированием данных можно только тогда, когда у тебя есть абсолютно четкое представление обо всей структуре данных и обо всех методах манипулирования ими. А когда тут моделируется, а тут — нет, то все моделирование улетает в трубу.
Конечно, это было б здорово, если б никто не мусорил. Но т.к. на практике мы этого добиться не можем, то нужно реализовать качественную уборку.
А вообще, если говорить об интеграции, то в общем случае должна быть полная абстракция от механизмов хранения данных, и это на уровне API должно выполняться.
Негативные последствия — это не будут удаляться комменты вместе топиками. Но эти последствия, как я понимаю, и так имеют место быть. Так что, я полагаю, ничего хуже этого уже не будет.
Что получаем в итоге: при активном использовании сторонних плагинов целостность базы все равно часто нарушается, а гибкость кастомизации системы в целом ухудшается. Так какой смысл тянуть механизм внешних ключей? А организовать каскадное удаление сущностей не так уж и сложно. Нагрузка при удалении будет выше, но это не такая уж и частая операция.
А вот насчет TinyMCE уверенности меньше. Но вполне допускаю, что и там обновление может пройти безпроблемно. Только надо обновиться аккуратно — некоторые плагины TinyMCE, написанные специально для Альто, нужно будет перенести в новую версию.
2. Веб-сервер должен перенаправлять запросы к несуществующим папкам и файлам на /index.php, для apache это делается через .htaccess (идет с движком, но должен быть включен mod_rewrite), для nginx — соответствующие настройки конфига
1) составить регулярку так, чтоб делала нужную выборку с учетом всех условий. Например, конкретно этот пример решается такой регуляркой: ^[а-яА-ЯёЁ0-9]+продаж.*$ — сработает, только если хоть одна буква или цифра перед корнем есть, т.е. распродажа попадает под паттерн, а продажник — нет.
2) делать два массива — один с искомыми патернами, второй — с исключающими, и перебором проверять на оба набора.
Во избежание подобных коллизий лучше добавить .html к шаблону топика. Тогда система будет понимать, что site.com/people.html — это точно топик запрашивается, а site.com/people — это раздел «Люди»
А вот со стеной не получилось воспроизвести, нормально запись добавляется