@fornit1917, в yii1 базовые вещи только. прикрутить jsm serializer для yii-шных моделей это то еще веселье. С yii2 не работал (Они таки используют HttpKernelInterface?), но судя по исходникам у него все те же проблемы.
предпочитаю делать админки на angularjs + rest api (обычно пишу их на silex+doctrine). Максимальная гибкость выходит, не нужно работать с формами (можно напрямую десериализовать запрос в готовую для записи в базу энтити в случае простого CRUD, да и интерфейс выходит намного приятнее).
@mumrum, если для вас главное минимизировать время инициализации, в контексте компонентов аля MyMail оно ничтожно. В крайнем случае можно воспользоваться каким популярным DI контейнером, который умеет компилить всю инициализацию, но по опыту скажу что разница во времени выходит незначительной.
@mumrum, смотрите в сторону dependency injection. Настроил сервис один раз, и потом используешь. То что вы описываете попахивает каким-то извращениями.
@VoVanJinn, очередь задач это очередь задач. Как она реализуется в контексте WP я без малейшего понятия. Я обычно в таких случая использую штуки типа RabbitMQ/ActiveMQ, но думаю это не про данный случай.
@VoVanJinn, имею ввиду в админке жмете "сделать", а оно на стороне сервера его не делать будет, а добавит в очередь. А консольный скрипт будет все это делать, смотреть в очередь и забирать новые задачи.
@VoVanJinn, можно использовать очередь задач. Из админки вы добавляете в очередь задачу, запускается в фоне консольный скрипт и делает ее... Можно периодически уведомлять о прогрессе выполнения задачи.
Почитайте по нормализации. EAV не сильно сложный паттерн, но сразу хочется сказать что его реализация будет относительно медленной на выборку. Паттерны с наследованием таблиц обычно применяют в купе с ORM, если у вас есть мэппинг таблиц на объекты.
тут я добавил элемент i в первый параграф. При расчете offset его не нужно учитывать, так как он является дочерним элементом параграфа. То есть находится на уровень ниже. а нам нужно считать только те элементы, которые находятся на одном уровне с нашим курсором.
(вертикальной черной я пометил курсор, если что. Как такового выделения текста у нас тут не происходит).
Если вы возьмете диапазон выделения, offset начала и конца этого диапазона будут равны (что логично, ибо у нас ничего не выделено), но координаты курсора в тексте мы узнать можем.
В этом случае у нас курсор стоит где-то в тексте, а значит считать offset мы должны относительно этого TextNode (в DOM все есть ноды, даже просто текст это TextNode, который намного проще обычных элементов). То есть мы берем и считаем символы, и видим что перед курсором есть один символ, значит offset будет равен единице.
курсор установлен между параграфами. Там нету текста, то есть выделение начинается в контексте нашего блока контейнера. offset в этом случае мы должны считать по элементам, которые находятся перед курсором, а там у нас один параграф. Значит и тут offset будет равен единице.