Логично, что не имея опыта
Понять, почему это не работает как надо, сложно.
Может дело и в моём опыте(его отсутствии по данному вопросу), сложно сказать. Однако тут уже возникает вопрос, почему этого опыта нет? Не потому ли, что в реальных коммерческих проектах это используется не часто(по крайней мере на данный момент)? А раз используется не часто, возникает вопрос - а почему если это так стильно и удобно?
ХЗ в общем, время покажет. Если эта технология так удобна и не имеет недостатков, то скоро она будет везде и как следствие я буду вынужден её хорошо освоить :)
Любой косяк всегда можно исправить, а для этого нужно изучать технологии или находить хорошего специалиста. Конечно можно делать старыми способами, но отказов и косяков при этом будет больше. Современные технологии для того и придуманы чтобы улучшить работу проектов.
Если реализовать не используя новые технологии, то в скором времени появятся проблемы, кто не развивается тот умирает.
Вопрос в том, готов ли заказчик к тому, что после сдачи проекта и его реального "боевого" применения ему придётся нанимать специалиста и тестировщика, чтобы исправлять эти косяки. Не знаю о каких косяках вы говорите, в моём примере я решил проблему глючной загрузки фоновых фото просто передавая их сразу в фоновое свойство css.
И нет, далеко не всегда технологии придуманы для улучшения работы проектов. Точнее в теории - всё гладко, а вот на практике применение этих технологий вызывает уже другие проблемы. Та же проблема совместимости имеет место быть.
Использовать новые технологии - приемлемо. Когда заказчик поставлен в известность и когда это оправдано. Любой нормальный проект живёт не в сферическом вакууме(я не говорю про Ваш фреймворк, он как раз из этого вакуума так и не вылез), а значит нужно учитывать не только "здесь и сейчас" а ещё и "потом и тогда".
Лично я практически не сталкивался с кастомными css свойствами. У меня тут мало опыта, мне не стыдно это признать :) Но опыт работы(в моей нише, так сказать) подсказывает что эти "модные фишки" не особо нужны.
Может со временем я и приду к осознанию необходимости этих инструментов, кто знает. Загадывать не буду.
Сейчас все усложняется. А "специалист" должен обладать определенной квалификацией.
А если она есть, customElements наоборот, упрощает многие вещи. Ну вот, пример. У меня, достаточно продолжительное время экслуатировался собственный фреймворк, который в числе прочего, на определенные элементы (data-url) вешает функционал валидации и отправки запроса на сервер.
Важное я выделил цветом.
Я нигде не призывал вернуться к CSS 1. Но к использованию ненужных наворотов в клиентских проектах я отношусь резко негативно.
Проф деформация если хотите. Я как раз тот самый человек, который потом сидит и пытается понять почему это "говно" не работает так как задумано, откуда эта масса багов и как довести "это" до ума.
Вероятно это сделано для lazy load чтобы фоновая картинка не сразу грузилась, а отложено. Это обычное решение для lazy load, просто в данном случае баг.
Про custom elements в моем случае они там по делу используются для удобства разработки, в одном блоке как бы логично всё. Вот боюсь как поисковики будут воспринимать, если проблем не будет то все ок.
Да вполне может быть что проблема в lazy load. Однако это баг, да и вообще глупое решение. Зачем на фоновые элементы дизайна ставить lazyload? Ладно там на картинки в постах\сущностях. Даже если что-то не подгрузилось - не велика беда. Но без элементов дизайна сайт выглядит откровенно коряво. И как показал этот баг, работает такой подход "как бог на душу положит"...сейчас работаю, через пол часа - нет) Если стоит задача уменьшить вес страницы - можно просто уменьшить размер файла изображения. Методов - хватает, как на мой взгляд.
Вы заказчик, раз вам всё нравится - значит всё гуд) Проблем с ПС по идее быть не должно. Но это по идее и основываясь на моём опыте, у меня он в применении custom elements не особо велик. В любом случае я даже при чтении статей не натыкался на посты о том, что ПСки плохо индексируют такие блоки. Но опять же - это ничего не гарантирует :)
Я в курсе. Это просто пример не нужного наворота, который вызвал проблему. Не более.
Ну это как глянуть.. Вот напр возьмём код Тса.
судя по названиям там наверняка кнопки и чекбоксы-селекты. Ессно, всё это жирно смазано жабаскриптными свистоперделками. Так вот это не будет работать/поломает вёрстку в устаревших браузерах. А даже там, где будет работать - не факт что не будет тормозов и глюков. Про стоимость, тестирование и поддержку всего этого барахла даже не заикаюсь.
И вот ради чего всё это? Неужели нельзя было сделать "по-простому"? Я почти уверен что можно, но, да, для окончательных выводов надо знать больше, чем рассказал ТС.
А если это сделал действительно верстальщик, а не кодер, реализующий необходимый функционал, то вообще.. просто выёживание. А может даже и копипаст чужого кода без понимания, необходимости/целесообразности.
Деталей действительно маловато.
Может быть - такая реализация там действительно нужна и без неё всё будет гораздо сложнее. Но лично я в этом сомневаюсь.
В любом случае да - ТСа ждёт масса "счастья и любви" когда в будущем ему понадобиться внести какие то правки в этот код) А так как в любой живой проект правки вносятся постоянно...
Зыбко всё это. Без реального кода, без реальной вёрстки совершенно не понятно, оправдано ли применение этих наворотов или нет.
Это просто криворукость/тупость(не умение делать качественно) программиста который так сделал. А вот как раз в данном случае кастомный тег легко мог решить проблему т.к. в нём есть теневой DOM через который описывается элемент и фоновое изображение загружалось бы без проблем. Применение data- атрибута это чисто информационное описание по которому JS и CSS может выполнять некоторые модификации элемента на лету(то есть если значение меняется то и вид элемента тут же будет меняться). Для подключения фонового изображения в данном случае нужно было просто использовать CSS.
Суровая реальность такова - не существует людей которые не "косячат". Ошибки допускают все, особенно хорошо это заметно, когда разговор уходит от "сферического вакуума" и переходит к реальным примерам. Теневой DOM, custom elements и прочие танцы с утятами - заметно усложняют поддержку и сопровождение продукта. Повышают требования к специалисту. Увеличивают процент "эпик фейла".
Если это требует заказчик - вопросов нет. Если без этого нельзя обойтись - вопросов нет. Если это личный проект или тренировка на хомячках - вопросов нет.
Если заказчик этого не просил и это не обсуждалось, если необходимости в такой структуре нет и можно реализовать и без этого, если это клиентский проект и нужно учитывать что он будет потом как то "жить" после сдачи текущим специалистом - вопросы есть.
Спор в общем то пустой. Нет ничего плохого в использовании современных средств разработки. Напротив, это хорошо. Но такой подход накладывает ограничения на последующее сопровождение проекта и всё это должно обсуждаться. Хотя бы на уровне "Я Вам зафигачу шаблон используя самые современные методы. Будет круче яиц в смятку."
Реальная ситуация.
WP, покупной шаблон с themforest, использует Elementor. Для некоторых блоков контента написаны виджеты Elementor в шаблоне. У некоторых из этих блоков есть фоновое изображение. Задаётся в админке, в коде выводится через атрибут "data-bg".
Так вот фоновое изображение указанное таким способом иногда грузится, а иногда нет. Скорее всего там должен отрабатывать JS скрипт, который поставит изображение из "data-bg" в "style='background-image". Но зачем нужно это искусственное усложнение кода, почему сразу не передать фоновую картинку в "style='background-image" - не понятно. В итоге масса времени на отлавливание проблемы и поиски её решения.
Я это к чему. Ситуация конечно не идентичная, однако добавление лишних "фишечек" зачастую приводит к последующим проблемам. Если же нет стандартных способов решить задачу - тогда конечно, добро пожаловать в "современный мир")
ТС, глупая идея.
Собьёшь биологические часы, можешь подпортить организм и ради чего? Чтобы время быстрее пролетело? Или ты хочешь на себе какие-то эксперименты ставить во время сна?(ну там всякие осознанные сновидения и прочее)
Займись йогой, скачай какую нибудь игру, которую давно хотел пройти. А лучше не одну. Книги почитай в конце концов.
Если с пользой, то пройди какой нибудь вебинар, курсов в сети навалом. Тот же php на уровне функций за неделю вполне можно освоить... И это в общем-то не только php касается.
Сон - это бездарно потраченное время с нулевым кпд)) Мог бы я не спать - не спал, но отдых всё таки требуется)
Очень благодарна вам за четко структурированный ответ. Это то, что я, собственно, хотела понять. Поскольку моя задача - не конкурс проводить на "лучшего в профессии", а сайт доделать.
Не за что.
Доделывайте, кто ж против) WP популярный движок, прогеров не мало, фриланс бирж - тоже в достатке. Вполне можно подобрать специалиста без "напряжения пупка". Не 2000 в конце концов)
Напишите подробное ТЗ, да выберите себе подходящего спеца. Только помните что "кроилово часто ведёт к попадалову". Это я к тому, что цена работы(ни в плюс ни в минус) не должна быть основным фактором выбора.
Да, вот об этом, собственно, и была речь с самого начала. Есть сообщения типаPHP WarningPHP Fatal errorPHP Parse error (здесь в основном syntax error)а также ошибки в БД
Где вы это видите? Что вызывает эти ошибки? У вас на сайте что-то не работает? Какой то функционал сбоит? Или вы просто логи где-то проверяете?
Вам же уже ответили. Если у вас не работает какой то функционал, вываливаются эти ошибки с фронта(ну, видны на сайте), тогда да, вы можете вполне обоснованно требовать их устранения. По простой причине - проект не работает. Если же вы где то там в логах что-то нарыли, а на сайте всё нормально, то это уже совсем другой разговор в котором масса неизвестных.
Так что на Ваш изначальный вопрос:
Нужно ли закладывать в ТЗ требование относительно того, что на сайте не должно быть ошибок в PHP?
Ответ - можно.
Вы как заказчик можете это требовать. Но вы как заказчик, должны быть готовы к тому, что такое требования разом отсечёт использование всех сторонних плагинов и потребует разработки всего функционала под вас с нуля. На бюджете это тоже скажется значительно. Одно дело поставить woocommerce и потом над ним колдовать хуками\фильтрами, совсем другое разработать его замену. На вопрос "а зачем разрабатывать с нуля" ответ простой. Откуда мне, как программисту, знать - выводит ли какой-то плагин варнинг\нотис или нет? Особенно если на это ещё накладывается то, что сайт не в вакууме "живёт" и мало ли, на какую древнюю VPS вы его засунете и хз что там за окружение\версия php\БД и прочего.
Разумно требовать отсутствие ошибок в фронте и полной работоспособности функционала. Это вообще-то подразумевается, но да, чтобы избежать некомпетентных исполнителей такое требование вполне можно добавить в ТЗ. Я даже видел такие ТЗ)
Всё остальное - от лукавого.
Среди не знакомых с WP людей бытует мнение что это очень-очень простая CMS и вообще решить на ней любую простую задачу "как два пальца об асфальт".
Однако это совсем не так. В плане кодинга WP ничуть не проще чем аналогичные CMS. Конечно там нет "===" между CMS, но вордпресс легок именно в администрировании через админку и расширении плагинами для простого пользователя. В этом плане, да, у него нет конкурентов. Очень много плагинов, удобная админка, достаточно просто освоить и вникнуть.
Но для вас, как для программиста, это не будет иметь никакого значения. А вот отсутствие нормальных фильтров товаров "из коробки", не самая простая система доставки, зоопарк устаревших хуков\функций с кучей синтаксического сахара - уже будет. Кстати с синхронизацией с 1С там тоже не всё "кошерно", хотя платные решения есть. Да и вообще полностью бесплатных плагинов не сказать что очень уж много, довольно часто возникает ситуация когда плагин есть, задачу решает, но нужный функционал в платной версии.
Если бы у вас знаний не было вообще, для простенького шопа я бы советовал WP+Woo. Но если у вас уже есть опыт создания сайтов на опенкарте...то что вообще тут обсуждать?
"Лучший инструмент - тот которым ты владеешь" *не помню кто сказал* )
Де-юре у вас не магазин а обычный блог на вордпрессе. Отсутствует плагин магазина, нет нужного функционала. Хотя по факту конечно на магазин похоже, но той же статистики заказов у вас нет. А это штука полезная.
Для woocommerce не нужен плагин Advanced Custom Fields Pro, там из коробки есть атрибуты у товаров. Хотя он конечно не мешает, товары считай те же посты.
Вообще да, связка WP+woocommerce для ИМ на пару-тройку тысяч товаров без особых наворотов - самый оптимальный вариант. Много информации в сети, масса платных\бесплатных модулей, легко найти специалиста для небольших изменений, нет проблем с шаблонами(можно заказать под себя, можно купить на темфоресте).
Проблемы начинаются когда нужен какой то уникальный функционал. Всякие кастомные доставки с хитрым функционалом, навороченные фильтры атрибутов и прочее.
