Почему темы делают как хотят! Есть решение
Встречали разработчиком тем, которые делают вывод артикулов не как в дефолте, из-за этого очень страдает поддержка плагинов написанных ранее, как вы решаете такие проблемы?
Встречали разработчиком тем, которые делают вывод артикулов не как в дефолте, из-за этого очень страдает поддержка плагинов написанных ранее, как вы решаете такие проблемы?
4 ответа
Потому что нет стандартов!
А если нет стандартов - все делают как хотят, в том числе и webAsyst, если взять две темы Default и Гипермаркет - то вы неприятно удивитесь, что там все разное и непонятно на что ориентироваться
Тема поднималась не один раз и вывод один - принять текущею ситуацию и ориентироваться на тему Default
Цитата:
Плагин работает на теме default? Работает.
Идите нафигВиновата тема дизайнаДа лучше всегда ссылаться на дефолт, большее количество плагинов на нее заточено.
Даже в теме dummy есть косяк, которую рекомендуют для разработки брать.
Может быть, уточните на всякий случай, что именно вы имеете в виду?
Да вот есть код, в дефолт удобно сделано
один всего лишь input, а не которые делают через type radio, зачем так
щас конечно переделал у себя, под новое, разобрался.
да и его может не быть в принципе
Делаю шаблон для продажи. Использую в основе тему Dummy. Подскажите, какие моменты нужно учесть для поддержки плагинов?
К сожалению не нашел никаких рекомендаций по верстке элементов в документации. Как мне показалось, очень слабая документация для тех, кто впервые делает темы для этого движка. Как я представляю, в дальнейшем после публикации темы, придется очень много допиливать и делать костыли для поддержки существующих плагинов. Может кто-нибудь сможет описать хотя бы какие-нибудь базовые стандарты, на которые стоит ориентироваться?
dummy можно взять за основу, но там есть косяк, в оформлении по шагам, не прописан класс, который берется у какого то плагина доставки, лучше взять за основу default, почти все на нее ссылаются
то есть я должен брать тему дефолт и особо не встревая в верстку делать тупо замену классов оформления? Чтобы уж наверняка все работало. Не кажется ли это каким-то бредом?
не обязательно, но как вариант, мной предложенный подойдет, главное надо знать какие плагины используют какой функционал, в основном это классы для артикулов что бы содержались, а еще лучше просто популярные посмотреть плагины, у них в руководстве написано подключение и уже подготовить почву для них, а потом когда начнут еще клиенты писать что не работает то да се, станет еще более понятно что и где добавить и выпустить обновление, а потом уже в новых темах будете сразу внедрять, ну как то тк.
забивать на такие нестандартные оригинальные темы
согласен с вами, но когда клиенты просят, приходится конечно же править, а то терять не охота.
А.... Вот откуда приходят клиенты, которые считают что по первому их зову разработчик должен все бросить и переделать все так, как им хочется....
Ну тут ты не прав) Клиент купил продукт, и он хочет им пользоваться, поднималась же тема, чтобы использовать классы из дефолта, тут либо разраб шаблона правит, либо разраб плагина подстраивается под клиента) в любом случае кто-то должен)
клиенту сложно объяснить, что вот тут типа не так, тема может все прекрасно работать, а вот плагин не будет, легче бывает быстрее поправить и выпустить потом обновление, чем вступать в переписку с клиентом.
Легче поправить !== приходится конечно править.
Ну да, видимо, вопрос терминологии. Просто участились случаи обращений когда открывают дверь в поддержку с ноги с лозунгом "вот доступы, настройте плагин". Хоть пулемёт расчехляй =)
тут с вам согласен, клиенту сразу кидают доступы, даже не читая описания плагина)
просто хотел спросить у разработчиков, кто делает темы, почему они вот так поступают, какой злой умысел преследуют или нет?
Ну я, конечно, немного утрировал, но готов поспорить. Хотя, все это может оказаться вопросом используемой терминологии. В данном конкретном случае не согласен с озвученным посылом: "приходится конечно же править, а то терять не охота". Не охота терять - тупиковая ветвь развития. Имхо, ессно.