Теперь все скрипты доступны в обновленном формате в нашем магазине USCRIPT.PRO

Перейти в магазин

Дополнительные поля для материалов
Суть идеи:
Скрипт, который позволит добавлять дополнительные поля к материалам.

Например чтобы для модуля "Каталог файлов" можно было добавить дополнительное текстовое поле, которое появиться у каждого материала.

Типы полей:
- текстовое однострочное;
- текстовое многострочное;
- числовое;
- дата;
- время;
- изображение;
- ...

При добавлении нового поля можно редактировать их CSS и HTML.

Страница управления подключенными полями.

! Не забывайте комментировать и оценивать идею. Это повышает степень её востребованности и увеличивет шансы на реализацию.
Впервые предложена: 12.08.2011 пользователем mehaNik
Обсуждения / дополнения к идее:
SleepWalker7798 Спам 02.10.2011 01:48
SleepWalker7798 Печаль. Плохо что uCoz скрипт PHPCODE выводит результат работы php скрипта через AJAX. Из-за этого получается, что нельзя сделать значения дополнительных полей индексируемыми. Это ощутимый минус для такого скрипта.... А у меня были таки чудесные планы на эту тему, хотел даже API использовать, а в итоге в нем особой надобности нету, так как если я буду через пхп скрипт пропускать все материалы, то их просто напросто не проиндексирует поисковик.

Надеюсь в будующем функционал возможности php на юкозе станут пошире.
mehaNik Спам 12.10.2011 18:50
mehaNik $RCODE_N$ позволяет работать с PHP без яваскриптов
SleepWalker7798 Спам 17.10.2011 22:54
SleepWalker7798 Прошу прощения, что не откликался.
Насколько я знаю, этот код кэшируется, верно?
А мой пхп срипт должен возвращать динамические данные...
mehaNik Спам 17.10.2011 23:07
mehaNik приведите пример пожалуйста
SleepWalker7798 Спам 18.10.2011 00:40
SleepWalker7798 У меня был такой замысел:
Я хочу, что бы дополнительные поля можно было так же как и обычные поля прописывать в шаблонах (с использованием кодов в стиле юкоз).

Для того, что бы заставить эти поля работать на сайте, мне нужно перед выводом каждого материала парсить в нем все коды полей и заменять их значениями этих полей. Я планировал разместить php скрипт вместо $BODY$.

Правда до этого я думал, что API возвращает полный HTML вида материала, оказалось, что это не так... Что негативно отразится на скорости работы скрипта, так как придется заново парсить весь шаблон (тут кэш был бы очень полезен).

В добавок в api не возвращаются данные о всех полях материала, то есть, при таком алгоритме, юзеру придется отказаться от большинства стандартных полей uCoz и полностью перейти на мой скрипт.

В общем теперь уже проблема в другом... Вопрос в том, есть ли смысл продолжать писать этот скрипт дальше, используя изложенный выше алгоритм? По моему мало кому понадобится скрипт, который, по сути, блокирует все поля юкоза и замещает их своими.

Или у юкоз планируются какие-то нововведения, которые помогут обойти эту проблему? К примеру возможность получить содержимое кода $BODY$ (функцией аля ucoz_getinfo или через api), так как в GET такие данные, естественно не поместить (плюс возможность освежить кеш, с помощью пхп скрипта).

Вторым вариантом решения (и по идее на данный момент единственным) есть замещение кодов с помощью JS. Из-за этого поля будут бесполезны для СЕО, но в них можно будет хранить к примеру коды или ссылки (к примеру для реализации онлайн кинотеатра, онлайн манги и прочих подобных вещей, возможно для некоторых характеристик товаров в онлайн магазинах).
mehaNik Спам 18.10.2011 11:58
mehaNik Я не углублялся в алгоритмы реализации этого функционала, но навскидку мне приходила мысль рендерить дополнительные поля в шаблоне материалов а не перекрывать $BODY$. Это ведь функционал дополнительных полей. Зачем отказываться от полей которые предоставляет система?

В кешировании я невижу ничего сташного. Если мне, например, для модуля блог необходимы дополнительные поля для изображений, то несколько часов мне ничего не решают, пока данные закешируются. Если цель рендеринг контента для поисковых систем, то это время мизерно. Если для вас каждая секунда дорога, то можно попробовать при добавлении материала рендерить аяксовый контент для пользователей пока не закешируется контент для поисковых систем.
SleepWalker7798 Спам 19.10.2011 10:27
SleepWalker7798 В принципе такой вариант возможен, но так нельзя будет обрабатывать коды дополнительных полей.
То есть, что бы к примеру заменить %%КОД%% на его значение, мне нужно пропустить через скрипт все содержимое материала.

Если просто вставлять скрипт, допустим через $RCODE_N$ в шаблоне вида материалов, то можно будет вывести блок сразу со всеми полями (естественно с определенным шаблоном). Нельзя будет допустим написать что-то в этом духе

%%CODE%%
....
$MESSAGE$
....
%%CODE2%%


можно будет получать шаблоны подобного вида:
$MESSAGE$
.....
%%CODE1%%.....%%CODE2%%.... и т.д.

то есть по сути будет что-то типа глобального блока ($RCODE_N$), в котором будет шаблон с дополнительными кодами.

Такой вариант удовлетворителен?
mehaNik Спам 02.11.2011 17:11
mehaNik Гугл теперь индексирует аякс и явасткипт. Так что можно с кешированием не заморачиваться. Пруф - http://searchengineland.com/google-can-now-execute-ajax-javascript-for-indexing-99518

P.S. По поводу RCODE_N продолжаю дальше смотреть реализуемость. Появятся новости - отпишу.
SleepWalker7798 Спам 06.11.2011 01:23
SleepWalker7798 Спасибо за информацию. До меня эта новость тоже дошла
SleepWalker7798 Спам 23.10.2011 22:24
SleepWalker7798 позволять то он позволяет ($RCODE_N$), вот только скрипту не передают никаких данных по поводу того, откуда вообще этот запрос произошел. С помощью $RCODE_N$ нельзя определить с какой страницы был послан запрос (и соответственно нельзя определить id материала)... капец просто...
Shooty Спам 16.09.2011 20:14
Круто офигительная тема!!!!
test Спам 28.08.2011 13:28
Нужная вещь.
[G]XPert Спам 12.08.2011 23:05
[G]XPert Можно реализовать с помощью PHP.

Все текстовые поля (дата, время, числа - в том числе) можно хранить в файлах на PHP-сервере.

С изображениями сложнее. Их можно грузить на PHP-сервер (дальнейший вывод таких изображений будет осуществляться посредством запроса на PHP-скрипт) или в файловый менеджер сайта (для получения прямых ссылок).
mehaNik Спам 12.08.2011 23:39
mehaNik По поводу изображений то думаю тут пока нет смысла реализовать загрузку изображений на сервер этим скриптом. Возможно во втором релизе :).

Для начала думаю будет достаточно дать возможность указать урл картинки с тем, чтобы она протом отображалась в материале.
Добавлять комментарии могут только зарегистрированные пользователи.
[ Регистрация | Вход ]