Хранить html код в столбце поста кажется нецелесообразным по ряду причин:Угу, ага...
Лишняя трата памяти на хранение html теговОго, а лишние это сколько? Экономия на байтах чаще всего приводит к тратам на вычислительные мощности. Некоторые расчеты чуть ниже.
Уменьшение производительности (?)Производительности чего?
Стили/компоненты могут изменяться, а код останется прежнимСтили как раз и нужны для того, чтобы легко конфигурировать визуал, не привязываясь к коду. Код может быть каким угодно, но стилизация через теги пока что лучший вариант, который придумали разработчики.
Использовать собственные минифицированные теги, благодаря которым определенный парсер будет воссоздавать нужные блоки с помощью компонентов (возможно динамичесих)Ага, переизобретаем BBCode, найс... Для понимания проблемы - такие коды придуманы для форумов, с целью ограничить использование хтмл в пользовательском вводе. При этом подходе он худо-бедно оправдан, хотя и требует постобработки при каждом выводе, а это использование регулярок, что как бы совсем не бесплатно. В вашем же случае, источник текста более-менее доверенный, и ограничение в тегах больше мешает чем помогает.
Хранить каждый элемент поста отдельно в бд со следующим содержанием (element_name, position, content, post_id), используя отношения к родительскому посту, соответственно сохранится структура и рендериться пост будет через соответствующие компоненты в нужном порядке (однако как будет именно рендериться в шаблоне поста пока неизвестно)Базовые элементы и так должны храниться отдельно, другой вопрос почему они у вас рендерятся в одном порядке, а в другом месте в другом порядке? Заголовок, короткое описание, текст, главное изображение - отдельные поля, оглавление по сути часть текста, зачем его выносить отдельно - загадка, это же такой же текст, котрый автор волен располагать . Вариант с внешней таблицей по сути приводит нас к выносу части данных в EAV(отличный пример универсализации в ущерб производительности), что как раз будет серьезно напрягать выборки бд, если понадобится делать какие-либо поисково-выборочные манипуляции по этим данным.
Теперь вопрос можно ли написать свою систему плагиатаМожно, разрешаю, пишите. А если серьезно - аналитическая составляющая такого продукта будет стоить как отдельный маленький гугл. Не считая вычислительных мощностей и сложности самого кода, там еще и база статей и текстов с полноформатным аналитическим поиском должна быть, а ее надо еще откуда-то взять, что тоже весьма нетривиальная задача. Про размер этой базы и стоимость хранения я вообще молчу. А ее еще и поддерживать в актуальном состоянии нужно...
или внедрить какой то существующий на свой сайт?Есть сервисы с доступным апи, читайте что умеют, сколько стоят, что предлагают и как использовать на соответствующих страничках сервиса.
Есть ли гайды, туториалы?Для подключения апи достаточно понимания принципов работы таких сервисов и доки от поставщика. В случае самостоятельной реализации думаю общие принципы можно посмотреть в каких-нибудь сторис от гугл/яндекс разработчиков, они часто работают с полнотекстовым нечетким поиском...
Конечная формулировка вопроса такая: как отправить данные из формы в php-скрипт,у формы есть атрибут action, отвечающий за урл на который будут отправлены данные. Достаточно нажать кнопочку субмит.
в написании самого скрипта вроде ничего сложно нет.Как всегда, дьявол кроется в деталях...
размещать сайт на хостинге в открытый доступ;А есть че размещать то? Хоть один сайт с полутора функциями? Что-то базовое, типа авторизация-регистрация-блог?
создавать формы для ввода данных , которые будут записывать введенные данные в файл либо отправлять по указанному e-mailОк, первый вопрос отпал...
В каких технологиях мне нужно разобраться? Надо ли учить PHP и MySQL?Любой современный язык под веб подойдет. И базовый SQL синтаксис для начала. Если работы будете "чисто для себя" делать, этого достаточно. Если для заказчика - либо учить что-то из фреймворков, либо брать готовые цмс и настраивать, что тоже вполне работа.
Здравствуйте, существует проблема защиты данных клиентского приложения передаваемых серверу и обратно.Какая конкретно проблема?
как защитить данные?От кого?
Можно ли использовать HTTPSРазрешаю, можно.
и как это сделатьНа сервере ставите сертификат, в клиенте прописываете урл апи с https.
или же нужно создавать свои модули шифрования под сессии?Если приложение передает критические данные (например банковские транзакции или шпиёнские документы), можно использовать сквозное шифрование с какими-нибудь убердлинными ключами, однако перехват ключей при хэндшейке при атаке митм никто не отменял. Впрочем, как и в случае с хттпс.
не совсем так, задача стоит обезличить курьеров и операторов перед друг-другом и курьера перед другими курьерами, что бы не было сговора или передачи данных клиента и увода на сторону курьером в данном случае.Кмк, реализовать это на базе сайта в разы проще чем через что-либо другое, включая тг. Я вижу это как что-то напоминающее я.такси - рассылка задачи и ожидание первого ответа. Так как приходит просто запрос, вы не можете на него реагировать обратно никак, корме кнопок. Соответственно связи в обратную сторону (от курьера к оператору или к другим курьерам) у вас не будет, кроме заранее заданных комманд/кнопок. Зачем тут тг - загадка.
Сама специфика бизнеса такая, в которой из-за сговора в частности, клиенты уходят из компании. а переходят к курьерам.
Решение не для спама и тп, решение для того, что бы обезопасить клиента и только
На каком Фреймворки такое сделать, кто что посоветует с чем работать и как начать?Вообще пофиг, любой подойдет, такое можно и на голом пхп или питоне накалякать (да и не только на них).
так-же, где хранить эти сылкис (имя/фирма) использовать для этого БД или какой-то есть другой способ?Можно в бд, есть и другие способы, например в файлах, если операция разовая - можно в памяти (редис, мемкэш), можно что-то типа как описал Владимир Коротенко, почему нет...