Вы не зашли.
Предположим, что вы воплотили в реальност плоды своих стремлений. Дальше, что?
Вы про локализацию или про весь этот плагин в целом ?
Если про локализацию, то уже придумал и сделал (как раз сегодня проверяю) - можно добавлять прямо из админки переводы названий пунктов меню для нужного кол-ва языков (сохраняется в тот самый menu.ini, как задумывал автор в директорию, соответствующую указанному языку, а при выводе меню на сайте подхватывается тот перевод, который соответствует текущему языку).
Если Вы про плагин в целом - то как закончу, буду использовать на паре обслуживаемых мною сайтов, а архивчик с модифицированной версией плагина выложу потом для всех желающих - надо только подробное описание будет оформить.
Обнаружил у автора ещё одну ошибку (либо я не понял какую-то "недореализованную задумку"). На этот раз пойдёт речь о попытке автора реализовать возможность поддержки локализации не только для интерфейса настройки плагина, но и для названий пунктов меню (отображаемых у пользователя на сайте). При включённой поддержке локализации автор предлагает указывать в пунктах меню идентификатор (вместо истинного имени пункта меня), который при отображении на сайте "разворачивается" в локализованное имя с помощью файла menu.ini в языковой поддиректории плагина (о чём свидетельствуют комментарий самого автора). Но дело в том, что абсолютно все упоминания этого механизма в коде содержали неверный префикс (название) плагина (должно быть "menu_pro:", а там везде указан "rmenu:"). После внесения исправлений задуманный автором механизм заработал. Вызывает некоторое недоумение, с чем могла быть связана эта ошибка (или я чего-то не понял в исходной задумке ?), ведь во всех других местах (где выводятся локализованные подписи к пунктам интерфейса настройки плагина) префикс был прописан верный.
Кстати, необходимость руками оформлять тот самый файл локализации menu.ini в случае, когда пользователю нужно задействовать механизм локализации, безусловно нельзя считать удачным решением (думаю, автор планировал как-то решить этот вопрос позже, но забросил свою разработку). Я попробую добавить какой-то механизм "визуального" редактирования файла локализации из админки, хотя пока не очень понимаю, как это можно сделать без чрезмерного усложнения кода.
Продолжаю делиться своими изысканиями. На этот раз - не ошибка в коде, а причина того, почему автор использовал то, что он назвал "ХАК" (библиотека, которую в его версии надо было руками извлечь из архива и сохранить в системную директорию /includes/ ). Дело в том, что автор, по всей видимости, просто не нашёл описание того, как в NGCMC задумывалось подгружать дополнительные библиотеки плагинов. Я проанализировал код движка и разобрался (до некоторой степени), как работает параметр "Library:" в файле "version". Оказывается ("открыл Америку"), подобные дополнительные библиотеки надо указывать именно там (по аналогии с параметром "Actions:"), т.е. сначала в этом параметре указывается желаемый идентификатор библиотеки (например, просто слово mylib), а затем (после точки с запятой) относительный путь к файлу библиотеки (от директории плагина с этим файлом "version").
Далее, для корректного подключения библиотеки, в теле файла с кодом плагина просто указывается команда
LoadPluginLibrary('menu_pro', 'mylib');ВНИМАНИЕ: запись в файле "version" отрабатывается только при "установке" плагина в систему, при которой происходит сохранение этой информации в "недрах" движка (в файл /engine/conf/plugins.php) для корректной работы функции LoadPluginLibrary !
Вооружившись этими знаниями, я сделал в нашем плагине поддиректоию "lib" и поместил туда тот самый "ХАК" ("dbtree.class.ng.php"). Чтобы это работало, я (до "установки" плагина) добавил в файл "version" строку:
Library: mylib; lib/dbtree.class.ng.phpА в файлы с кодом плагина добавил вызов LoadPluginLibrary вместо авторских @include_once ...
... небольшая инфа была на вики ...
Про web.archive то я и забыл - и правда, там есть, что почитать. Спасибо.
Вот только зачем же в марте 2018г. эту Wiki отключили :-(
Надо бы куда-то выложить ценную сохранившуюся информацию - пусть даже с пометкой "архив: возможно устарело".
Возможно, я пишу это только для себя, но всё же ... продолжу.
Нашёл ещё одну ошибку у автора. Сразу оговорюсь: возможно, здесь имеет значение версия PHP, и у автора раньше работало иначе, но тем не менее.
И так - в файле menu_pro.php в функции plugin_menu_pro_get_nodes есть строка, в которой эта функция рекуррентно вызывает сама себя для заполнения списка подпунктов меню:
$entries = plugin_menu_pro_get_nodes($nodes, ++$pos, $count, $dir, $url, $icon_dir, $icon_url);Но беда в том, что второй аргумент по описанию функции подразумевается передающимся "по ссылке", а не "по значению" (и алгоритм работы рассчитан на то, что переменная и правда получит новое значение в процессе работы этой функции). На сколько я понял, использование выражения с инкрементом (вместо просто имени переменной) сбивает передачу аргумента "по сылке" (т.е. какое-то новое значение уже "не возвращается" из функции), что и приводит к сбою в работе алгоритма.
Я просто прописал этот инкремент отдельной строкой перед вызовом функции, а в вызове оставил лишь имя переменной - это решило проблему.
Ну что здесь не понятного, можешь почитать редми https://ngcmshak.ru/readme/094/docs/index.html, файл news.categories.tpl . эта папка есть и у тебя ,там все подробно по шаблонам
Да, спасибо, эти все материалы у меня есть - жалко, что там почти ничего не рассказано про создание плагинов ("внутрянки" для программистов). Но я, вероятно, мыслю как-то совершенно иначе, чем все остальные :-) И не могу понять, почему там всё крутится вокруг "новостей": а если у меня их нет на сайте ? Совсем нет! Какое отношение имеют "категории новостей" к нужной мне статической структуре меню с пунктами, ссылающимися на произвольные статические страницы сайта? Сайты ведь бывают не только в виде бесконечной ленты новостей, разбитых на какие-то категории. Бывают и old-school сайты просто с набором страниц без каких-либо "новостей". Просто сайт с информацией об организации. Не магазин, не блог, не новостной сайт. Просто информационный, почти статический, сайт, из пары десятков страниц с какой-то информацией. Но всё же эти страницы иногда (примерно раз-два в год) дополняют, что-то корректируя и добавляя что-то новое (в том числе и корректируя подпункты в меню с ссылками на старые/новые страницы). Вот для такого случая и нужно обычное статическое "неавтоматическое" меню (и редактор для него в админке для владельца сайта). Думаю, автор этого плагина меня бы понял. Даже, если это нужно в единичных случаях - почему бы не существовать такой возможности ?
Как я могу предположить, идеологически NGCMS проектировалась под совершенно иной (более современный и популярный) сценарий использования сайта, но у небольших организаций бывают разные потребности, и не всем нужны новостные интерактивные порталы - иногда стоит совсем иная задача (например, небольшая общественная организация, использует такой сайт для выполнения минимума обязательных требований закона по раскрытию информации о совей деятельности).
Ну вообще с появлением твига этот плагин не нужен, все решается на уровне шаблона, и управлении категориями , в шаблоне файл news.categories.tpl оформляем все в соответствии с шаблоном, создаем категории в админке и там отмечаем показывать категорию или нет. Плагин не нужен , все уже автоматизировано.
Не очень понял, о чём Вы. Мне нужно было сделать обычное меню: "Главное", "О Компании", "Документы", "Информация", "Контакты". В некоторых пунктах по 3-4 подпункта... Никаких инструментов в админке для этого не было, меню было "нарисовано" руками в шаблоне на обычном HTML и корректировалось в текстовом редакторе руками. Вот я и делаю нормальный визуальный редактор пунктов меню для админки сайта.
Возможно, Вы описываете какой-то иной сценарий использования NGCMS - как новостной портал. Но у меня новостей фактически нет, а есть сайт организации с набором статических страниц ("статей" в терминологии NGCMS).
Плагин был написан скорее всего на php до 5 версии, и для движка версии 0.9.1 или 0.9.2. это было давно, релиз 0.9.5, есть utf версия на гите, часть плагинов переписана на версию php > 7 и с поддержкой твига. Так что возмущаться на старьё не есть гут. Можешь перепиши , за это большое спасибо.
Хочу пояснить - я искал средство визуального редактирования структуры произвольного многоуровневого списка для сайта (как обычно оформляют меню) для NGCMS, но ЕДИНСТВЕННОЕ, что было создано для этого движка с такой функциональностью - этот старый плагин. Если бы было что-то новее - я бы взял новее. Честно говоря, для меня совершенно не понятно, почему все эти годы практически никому не было нужно добавить в админку визуальный редактор меню, ведь если сайт делается не для себя, то им будут пользоваться люди, не умеющие сами корректно (не сломав разметку) редактировать файл шаблона, когда им захочется добавить подпункт в меню.
То, о чём я написал до этого на этом форуме - не "возмущение" (я наоборот очень благодарен автору за хорошую заготовку), а просто мысли вслух для таких же, как я, кто найдёт этот плагин на этом сайте и захочет его применить. Я не профессиональный программист, поэтому я не настолько уверен в своих силах, чтобы просто написать "Работаю над новой исправленной версией, скоро выложу". Я действительно уже кое-что переделал и сейчас хочу изменить интерфейс настройки меню (тот, что в админке плагина) - сделать его "древовидным" (а не табличным), да ещё с кастомным контекстным меню на пунктах и т.п. Но для меня это - совсем не просто (хотя я и использую готовую библиотеку TreeView). Если всё получится и будет иметь "товарный вид" - с радостью тут поделюсь с другими. Но я пока что даже не очень понимаю, как правильно модифицировать инсталлятор плагина, чтобы всё автоматически устанавливалось и работало "из коробки" (документации же никакой по "плагино-строению" нет), поэтому не знаю, чем дело кончится ...
Что касается версий - у меня написано в админке "0.9.5 Release + GIT 20170301", а PHP на тестовом сервере вообще v5.6 (потом, кстати, и правда надо будет проверить, работает ли это всё на седьмой версии, но думаю должно работать).
Так или иначе - буду рассказывать о результатах своего творчества, т.к. уверен, что хоть один человек кроме меня да захочет реализовать подобную функциональность на своём сайте.
Ещё одно исправление (не совсем ошибка, но, думаю, надо исправить): везде, где формируется адрес ссылки для пункта меню (как в файле menu_pro.php, так и в "админке" config.php), есть условие, проверяющее поле адреса для этого пункта меню - если оно не заполнено (является пустой строкой), то почему-то сразу вставляется ссылка на плагин (посредством функции generatePluginLink), даже, если никакого имени плагина для этого пункта меню не вводилось - не хорошо.
Я добавил там везде вторую проверку (на пустоту имени плагина), и если имя плагина не было введено (а основное поле адреса для этого пункта меню пустое), то формируется ссылка, состоящая просто из одного слэша (по сути - на домен сайта, что обычно эквивалентно главной странице). Как вариант, можно было бы сделать, чтобы в таком случае подставлялась ссылка из заглавия меню или какая-нибудь заглушка '#', но лишь бы не таинственное '/plugin///', как возникало в исходном авторском варианте.
Нашёл ещё одну ошибку в коде: в файле menu_pro.php в функции plugin_menu_pro_get_nodes есть участок кода, где заполняются разные поля (или как их назвать ? "подстановочные переменные" ?), доступные из шаблона - среди других, там должно формироваться значение для {level} , но оно не формировалось (в нём была всегда пустая строка). Я стал разбираться и обнаружил, что для формирования этого значения автор вставил вот такую странную строку:
$pvars['vars']['level'] = $nodes[$cur_pos]['tree_level' - 1];Возможно, я не знаю каких-то продвинутых нюансов PHP, но по-моему там имелось в виду это:
$pvars['vars']['level'] = $nodes[$cur_pos]['tree_level'] - 1;Но я (в порядке перестраховки) написал даже так:
$pvars['vars']['level'] = intval($nodes[$cur_pos]['tree_level']) - 1;После этого значение стало формироваться нормально.
Кстати, после этого исправления я обратил внимание, что при формировании пути к файлам-шаблонам пунктов меню (при обращениях к функции plugin_menu_pro_get_dir), та самая единица НЕ ВЫЧИТАЕТСЯ, и первый уровень отображаемого меню при обращении к той функции предсказуемо имеет значение "2". Возможно, автор даже специально не стал это исправлять, т.к., по сути, номер уровня там (в функции plugin_menu_pro_get_dir) нужен лишь для того, чтобы вовремя остановиться при "подъёме по дереву" пунктов меню в поисках существующего пути к шаблонам - не пытаться подниматься выше "корня", и там не так важно, считать ли "корневой" уровень (где хранится название меню) нулевым или первым - лишь бы стояло правильное значение в условии выхода из рекурсии (а там стоит сравнение с единицей). Поэтому, я НЕ называю это ошибкой, просто я бы сделал единообразно (чтобы не путаться).
И ещё - одной из первых своих модификаций я добавил возможность иметь каждому уровню меню свой собственный item.tpl на базе пронумерованных tpl-файлов в текущем skin. Т.е. я не трогаю реализованную автором возможность указывать разные skins хоть для каждого пункта меню, но добавляю некий автомат, который будет подхватывать item1.tpl, item2.tpl и т.д. из текущего skin для соответствующего уровня меню, если таковые (нумерованные) файлы там есть (в противном случае используется item.tpl как и у автора, т.е. у пользователя будет выбор). Потом отдельно напишу про каждое нововведение и выложу модифицированные файлы.
Нашёл ещё одну ошибку в коде: в файле menu_pro.php в начале функции plugin_menu_pro_get_dir проверяется, есть ли там реально на диске файлы шаблонов - так вот в этой проверке дважды проверяется наличие container.tpl вместо того, что бы проверить наличие и container.tpl, и item.tpl (скопировали и забыли исправить имя файла во втором условии).
Я понимаю, что прошло почти 11 лет и (похоже) никому, кроме автора, этот плагин не был никогда нужен, но я решил всё-таки поднять тему, т.к. сейчас пытаюсь допилить этот плагин под свои нужды и разбираюсь в его работе.
Буду отписываться по мере обнаружения того, что можно / нужно исправить и рассказывать об изменениях, если таковые смогу успешно реализовать.
И так, что нашёл в первый день - две ошибки / опечатки в коде.
Во-первых, в файле config.php в функции add() в одной из строк случайно вместо $par_node было вписано $parent_node (из-за чего не сохранялось изменение выбранного родительского уровня при редактировании пункта меню) - просто опечатка.
Во-вторых, в файле menu_pro.php в функции plugin_menu_pro_get_access был неправильно оформлен селектор case - в PHP (в отличие от других языков) нужно обязательно вставлять break после инструкции, выполненной по совпавшему case-значению, иначе будут выполнены инструкции всех case ниже по списку. Из-за отсутствия break в этой функции неправильно проверялись уровни/группы доступа пользователей (для отображения или скрытия разных пунктов меню).
И ещё пара моментов (не ошибки, просто была непонятна сначала задумка автора) - чтобы пункт отображался на странице, он должен быть active (Я сначала подумал, что 'active' - это про то, какой пункт меню выглядит 'активным' (как бы 'выбранным') изначально, хотя как раз лично мне это было бы совсем не нужно) - позже разобрался, догадался, посмотрев код.
Кроме того (самое неочевидное) - пункты первого уровня меню в настройке плагина являются не пунктами меню, а как бы названиями (заголовками) РАЗЛИЧНЫХ меню для сайта (коих может быть несколько), а уже их второй уровень будет списком "корневых" элементов отображаемого меню. Именно эти заголовки и используются для идентификации нужного Вам меню при вставке в шаблон (т.е. поле name именно этих заголовков нужно приписать к plugin_menu_pro_ , чтобы получить имя нужной TWIG-переменной).