Обратился друг — учит модыкс и уперся так сказать в стенку — не регистрируются новые менеджеры и не редактируются текущие.
Помогите разобраться)) доков в гугле по этой проблеме не нашел, а самому уровень не позволяет(знаю лодырь, но семью кормить надо вот и учусь сам урывками и леплю простенькие сайты)
при клике на ссылку выдает ошибку в консоли Uncaught TypeError: Cannot read property 'click' of undefinedonclick @ index.php?a=11:218
скрин joxi.ru/EA4aDaJfDGMpVr
У меня была большая проблема с предыдущим хостингом.
Прежде всего очень медленно работала админка, любое изменение на сайте было долгим и нудным. Все зависало, причем, сайт становился недоступным — ибо шел большой перегруз на сервер. На хостинге проблемы не видели. Создал страницу, загрузил картинку — подвисло все. Если объем работы был большой, то через какое то время становился недоступным сайт. В общем все было грустно и лишний раз что то делать не было горячего желания.
В конце концов я все таки решил перейти на новый хостинг и выбрал от Модекс клуба с анализом.
Огромное спасибо Николаю, который исправил достаточно серьезные ошибки, из за которых происходили все эти странные и неприятные вещи с зависаниями и доступностью.
Ну и кроме того нельзя не отметить скорость с которой все начало загружаться, открываться, двигаться — разница ощутима.
Что касается админки и работы в ней — то это в разы просто стало быстрее. Что называется- " не успел подумать и начать, а оно уже сделано". Просто милисекунды. Я даже не могу привыкнуть после старых тормозов.
Так что если вы сталкиваетесь с проблемами, то можно рекомендовать этот хостинг, чтобы ни посетителям не доставлять неудобства, да и самому приятно, когда твой сайт просто «летает» и с ним приятно и легко работать. Обращайтесь не пожалеете.
Отдельно надо отметить профессионализм Николая, который наладил все буквально в течении короткого времени, причем все в режиме приятного диалога, чувствуется «рука мастера». Спасибо.
Спорить?)) Даже не пытался. Я лишь воссоздал условия данные ТС и нашел причину по которой неправильно работала конструкция.
Не стоит в этом спорить со мной. Стандартный вызов тянет ровно то, что он и должен тянуть — значения имеющихся полей. В составе migx-поля другая ТВшка используется только как элемент интерфейса для редактирования migx-полей, но ни как хранилище его значений и тем более не как рендерер для вывода значений на стороне фронта.
Надо логически четко отделять TV-поле, используемое в миге и поле, используемое самостоятельно.
Полностью согласен, но на практике получается иначе: если назначить TV шаблону — стандартный вызов тянет именно его.
Дело в том что если назначить его шаблону, то можно и изменить его значение в документе.
Надо логически четко отделять TV-поле, используемое в миге и поле, используемое самостоятельно. Уточняю: вот у вас есть ТВ-поле list1, вы создаете еще migx-поле migxtv и в нем помимо всего прочего еще и прописываете «inputTV»:«list1» (не inputTVType, которое будет определять просто тип поля, а именно inputTV, которое указывает какое TV-поле использовать в этом элементе). Так вот, если вы в документе редактируете значение самого поля list1, как самостоятельного TV-поля, то и значение его будет записываться именно для поля list1. А вот если вы редактируете migx-поле migxtv, то значение записывается именно для migx-поля, а не для list1. Соответственно, значения этих полей будут выводиться отдельно для плейсхолдеров [[+list1]] и [[+migxtv]]
зы какая у Вас странная манера общаться. Или мне показалось?
Не показалось.
Создание второго подобного поля — скорее пример чтобы проверить что всё работает. Можно конечно просто залезть в базу и очистить значение первого поля select_list1, но это уже сложнее.
Дело в том что если назначить его шаблону, то можно и изменить его значение в документе. А вызов
[[!getImageList? &tvname=`test` &tpl=`@CODE: [[+list1]]` ]]
будет выводить значение не встроенного в MIGX поля, а обычного.
зы какая у Вас странная манера общаться. Или мне показалось?
xPDO-пример был показан, чтобы вы увидели в каком виде вообще у вас исходные данные лежат. А далее уже сами решайте что с ними делать и как.
А вот предложения «не назначайте его!!! никакому шаблону!!!» — на магию походят. В программировании не должно быть магии, должно быть четкое объяснение всему. У вас есть четкое объяснение зачем создавать второе поле, да еще и которое не надо назначать никакому шаблону? Если не желаете отвечать, можете проигнорировать.
Не спорю, для тех кто с xPDO на ты это может быть идеальный вариант. А вот для меня например логичнее и проще обойтись стандартными методами.
Обращаюсь к ТС — у вас всё правильно построено, но есть один нюанс:
Чтобы всё выводилось нормально, создайте новый TV — select_list2 (по тому же типу что и select_list1) — и не назначайте его!!! никакому шаблону!!!
Затем сделайте как делали раньше.
Надеюсь понятно описал.
Вот. Значит в БД у вас хранится то, что надо. Попробуйте в консоли выполнить
$doc = $modx->getObject('modResource', $doc_id); $value = $doc->getTVValue($tv_id|$tv_name); print $value; print '<br /><pre>'; print_r(json_decode($value));