WebMan
В данный период я не оказываю услуг и не занимаюсь сторонними разработками
+434
Репутация
6110
Рейтинг
Идея интересная и полезная. Такой компонент вполне можно было бы встроить в раздел «Дополнения».
Что нужно доработать для этого, на мой взгляд:
Версии. Для каждого языка сделать список версий движка, чтобы можно было переводить и потом скачивать пакет для нужной версии. Делать только один перевод для всех версий не прокатит, так как константы и языковые файлы не только добавляются, а и удаляются от версии к версии.
Предыдущие переводы. Для новых версий использовать (автоматически подставлять) перевод от предыдущей версии, если это возможно, и показывать константы, оставшиеся без перевода. Это можно делать разово, например, при создании новой версии перевода на выбранный язык. Также придётся сделать проверку констант на изменение по сравнению с предыдущей версией — вдруг какую-то константу изменили.
Статистика по папкам и в целом. В списке папок стоит добавить колонки с количеством оставшихся не переведённых констант во всех файлах этой папки и её подпапок и с процентом перевода этой папки, включая вложенные подпапки. Это нужно чтобы переводчик наглядно видел, где и сколько осталось перевести, а не перебирал все папки и файлы в поисках оставшихся недоделок. И на основной странице перевода показывать то же самое суммарно по этой версии перевода (по всем файлам). Также в списке версий перевода можно показывать всем посетителям кто переводчик и на какой процент завершена работа.
Доступы. Добавление языков, добавление новых версий движка, создание установочного пакета после готовности перевода — это дело админа сайта. Пользователи могут подать заявку на перевод выбранной версии на желаемый язык. Админ утверждает или отклоняет этого переводчика. По готовности перевода админ генерирует пакет, который потом могут скачать все желающие, а доступ переводчика прекращается.
Версии пакетов. При необходимости что-то изменить в уже созданном пакете проходим всю цепочку заново: новая заявка от переводчика, исправление ошибок и перегенерация пакета. На странице языка возле версии движка нужно будет отображать дату и время создания последнего пакета. Это же время и дату в каком-то общепринятом формате (например, ГГГГММДД-ЧЧММСС) добавлять в имя файла пакета. Это нужно чтобы пользователи легко понимали, были ли изменения в пакете с момента его последнего скачивания.
Перевод с помощью ИИ. В идеале, в режиме редактирования можно добавить кнопки перевода с помощью ИИ: «Перевести весь файл» и «Перевести все константы без перевода» над списком констант. А также кнопки-иконки «Перевести константу» справа возле кнопок редактирования и очистки. Это ещё больше упростит работу переводчика, останется лишь проверить корректность перевода. Но это красивая хотелка на будущее.
Хранение. Переводы лучше хранить в файлах, согласен. А данные по версиям и статистике отлично лягут в БД в таблицы компонента.
Работы, конечно, ещё много. Зато это позволит подключить сообщество к переводам, сильно упростит работу переводчиков и в итоге сделает InstantCMS ещё более популярной в мире.
Про нарушения Вам уже объяснили, повторять нет смысла. Попробуйте перечитать и понять.
В Документации вообще мало описаний методов и свойств классов. Зато в коде много комментариев. Да и сам код чистый, легко читается. Попробуйте разобраться в нём и сделать описание нескольких классов. Это же опенсорс система, создаётся и поддерживается многими людьми. Почему бы Вам вместо претензий о нехватке чего-то не пополнить достижения сообщества своим трудом и добавить недостающее?
Обращаться к таблицам напрямую опасно, так как у других пользователей могут быть другие названия базы или префиксов. Ну и такой код плохо читается, другим людям будет труднее понять Вашу задумку. Вы же опубликовали пост для других людей? Так зачем создавать им проблемы и сложности?
Просьбу Вы не сформулировали. И это, кстати, зря. Минимально нужно было спросить: а всё ли годится для публикации, может кто-то что-то подскажет? То есть, именно то что Вы сейчас делаете в комментариях. Очевидно, что решение хотя и рабочее в Вашем конкретном случае, но не готовое и не полноценное.
У меня нет описания методов класса modelComments и писать его я не предполагаю. Там код достаточно простой, заинтересованные программисты поймут.
Если у Вас «нет времени» разбираться в Двойке и в теме поста, то это ещё один повод делать публикацию не Форуме, а не в блоге.
Во-первых, Захар, Вы же достаточно взрослый, чтобы читать и соблюдать правила ресурса? ;-)
Во-вторых, а других вариантов Вы не признаёте? Только или разрешить нарушать правила, или забанить? ;-)
Давайте попробуем поискать третий вариант: соблюдать правила и получить помощь одновременно.
Вам модератор уже подсказал, что:
1. Это не готовое решение, оно не даёт полный желаемый результат.
2. Такой подход неэффективен и может запутать читателей Вашего блога. Вы же этого не хотите? Вы же хотите помочь людям?
Поясню. Прямое обращение к БД лучше не использовать, от этого теряется совместимость и читабельность кода. Так же лучше не писать свой код там, где уже есть готовые методы в CMS. Например, для добавления подписки на камент есть метод modelComments->addTracking(). Этот и другие методы для работы с подписками на каменты можно найти поиском названия таблицы 'comments_tracks' по коду системы.
Оба пункта нарушают правила блогов на этом ресурсе. Поэтому такие публикации лучше делать на форуме с вопросом/просьбой подсказать какие-то конкретные нюансы.
Размышления приветствуем! На форуме в подходящей ветке или во «Флуде», если такой ветки нет. Форум — это и есть большое коллективное обсуждение.
В блоге выкладывают готовые решения или ответы на какую-то тему.
Но это не волшебный автомат, решающий любые задачи за пользователя.
По сути. Причин описанной Вами ситуации может быть много, а для анализа разных причин нужны разные инструменты. Начните с "Инструментов разработчика" в браузере для выяснения, что происходит с кнопкой в коде страницы. Если источник проблемы окажется на стороне сервера, тогда и "Расширенная отладка" сможет пригодится.
Максимум, на что меня хватит - несколько примеров с картинками, что я и делаю.
В первом своём каменте Вы уже привели ссылку на пост про схему работы движка Двойки, он как раз и показывает как "Всё начинается в index.php...".
Уберу это в следующем обновлении.
Если будут вопросы - задавайте.
В версии 2.13 появилась фича "Форма авторизации теперь системная. Можно изменять хуками как угодно". Можно ли авторизоваться по другому полю, кроме почты, и что для этого нужно сделать - я ещё не выяснял. Возможности заменить числовые id на красивые строковые значения в адресах профилей пользователей точно нет.
Почему бы не разрешить галку "Занимать всё свободное место" для любых блоков, а не только для контента?
Сайт написал в личку. Он ещё в процессе доработки, так что не сильно хочу светить на нетематических ресурсах.