Есть магазин на WP
Ставить кучу бесплатных плагинов не хочется, требуется более профессиональное решение.Ну, во первых звучит смешно... Собсно вордпресс разрабатывается и позиционируется как решение из коробки, расширяемое плагинами. Во вторых (исходя из первого) - ищите разработчика на вордпресс (желательно с каким-то опытом), которые предложат вам решение под задачу.
Подскажите пожалуйста куда двигаться: разработать новую тему на php, или взять пустую тему на underscore и написать надстройку на JavaScript? Какой из вариантов дороже? Какой вариант правильнее, если рассматривать с точки зрения на перспективу (возможно дальше будем делать приложение).Это вам подскажет только человек, добровольно решивший потратить часть своей жизни на изучение вордпресс как системы. Что касается приложения - то там есть много вариантов, часть из которых вообще никак с сайтом не взаимодействует, так как работает через апи, а часть наоборот - тупо оборачивают существующий сайт в свою имитацию браузера. Так что я бы не стал на этом акцентироваться.
Хранить html код в столбце поста кажется нецелесообразным по ряду причин:Угу, ага...
Лишняя трата памяти на хранение html теговОго, а лишние это сколько? Экономия на байтах чаще всего приводит к тратам на вычислительные мощности. Некоторые расчеты чуть ниже.
Уменьшение производительности (?)Производительности чего?
Стили/компоненты могут изменяться, а код останется прежнимСтили как раз и нужны для того, чтобы легко конфигурировать визуал, не привязываясь к коду. Код может быть каким угодно, но стилизация через теги пока что лучший вариант, который придумали разработчики.
Использовать собственные минифицированные теги, благодаря которым определенный парсер будет воссоздавать нужные блоки с помощью компонентов (возможно динамичесих)Ага, переизобретаем BBCode, найс... Для понимания проблемы - такие коды придуманы для форумов, с целью ограничить использование хтмл в пользовательском вводе. При этом подходе он худо-бедно оправдан, хотя и требует постобработки при каждом выводе, а это использование регулярок, что как бы совсем не бесплатно. В вашем же случае, источник текста более-менее доверенный, и ограничение в тегах больше мешает чем помогает.
Хранить каждый элемент поста отдельно в бд со следующим содержанием (element_name, position, content, post_id), используя отношения к родительскому посту, соответственно сохранится структура и рендериться пост будет через соответствующие компоненты в нужном порядке (однако как будет именно рендериться в шаблоне поста пока неизвестно)Базовые элементы и так должны храниться отдельно, другой вопрос почему они у вас рендерятся в одном порядке, а в другом месте в другом порядке? Заголовок, короткое описание, текст, главное изображение - отдельные поля, оглавление по сути часть текста, зачем его выносить отдельно - загадка, это же такой же текст, котрый автор волен располагать . Вариант с внешней таблицей по сути приводит нас к выносу части данных в EAV(отличный пример универсализации в ущерб производительности), что как раз будет серьезно напрягать выборки бд, если понадобится делать какие-либо поисково-выборочные манипуляции по этим данным.
Разбиваю строку на массив, из первого параметра получаю имя контроллера и создаю соответствующий экземпляр. Если нет второго параметра, вызываю действие по умолчанию: на сайте это отобразить каталог, или страницу со сатьями (uri соответственно mysite.com/catalog или mysite.com/articles). Если же есть второй параметр (это название конкретного растения или id статьи), вызываю другое действие и передаю параметр (получается mysite.com/catalog/aloe)то что вы реализовали к роутингу имеет такое себе отношение. Роутинг обычно опирается на правила, а увас тупо захардкорен контроллер. Что будете делать если сложность будет чуть выше, и например, добавится язык перед контроллером?
При запросе вида mysite.com/catalog/aloe/test, т.е. когда через слеш появляется третий параметр, та же страница с уведомлением для пользователя отображается без стилейЛогично, стили у вас лежат всегда в одной папке, а вы их каждый раз подключаете из разных "путей" в урл, от которых зачем-то высчитываете сколько папок "выше отмотать". Путь должен быть абсолютным.
Вот логика проверки, буквально, если в массиве получилось больше двух элементов, отобрази страницу ошибкиВообще логика должна быть такой, что если больше 2 параметров, то все что дальше помещается в какой-то массив, например $parameters, который можно получить из роутинга, и дальше в зависимости от значений что-то делать. Правильнее все же было бы сделать сопоставление пути с контроллером, экшеном и параметрами, как во взрослых роутерах, но для начала и так сойдет.
Мой инпут содержит всего 1 название фото, из-за в базу данных и отправляется 1 фотоДля загрузки большого количества файлов из одного инпута используется тег multiple.
иногда на сайте могут возникать ошибки http(404, 401, 500 и т.д.),Это абсолютно разные ошибки, и обрабатываться должны по разному.
пробывал в htacces:Логично что если сайт не работает, то и любое обращение к нему будет вызывать ту же 500 ошибку. Единственный способ что-то отобразить - статика, просто хтмл страничка оформленная в стиле сайта с нужным статичным контентом...
ErrorDocument 500 /error?error=500
А как вывести переменную?Не очень понятно что вы пытаетесь поучить и куда. Откуда взялся $res?
Не echo $res; а return $res; и получить её в $stdout?stream_get_contents() возвращает строку, что бы вы себе не навоображали...
Вроде запрос уходитЧто в пэйлоаде? Вангую что там ничего связанного с $_POST переменными нет...
contentType:"application/json; charset=utf-8"Так как вы явно указываете что будете передавать строку жсон в теле запроса, не понятно что вы пытаетесь найти в $_POST.
<?echo($_POST);?>Во первых отвыкайте использовать шорт теги, во вторых переменная $_POST это массив, и соответственно через ехо его выводить бессмысленно, и в третьих, как я написал выше, там ничего нет, так как данные передаются в теле запроса.
