У меня был такой замысел:
Я хочу, что бы дополнительные поля можно было так же как и обычные поля прописывать в шаблонах (с использованием кодов в стиле юкоз).

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

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

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

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

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

Вторым вариантом решения (и по идее на данный момент единственным) есть замещение кодов с помощью JS. Из-за этого поля будут бесполезны для СЕО, но в них можно будет хранить к примеру коды или ссылки (к примеру для реализации онлайн кинотеатра, онлайн манги и прочих подобных вещей, возможно для некоторых характеристик товаров в онлайн магазинах).