Особой разницы не заметно.
Разница в милисекундах незаметна при том, что пока данный модуль приложеиня не задействован - проверен только в "тепличных" - условиях без посетилей.
Запросы уже написал.
Для себя сегодня на локали репетировал, получается на 1200 записей в среднем 0,6 секунд. Вот когда записей в 10-ки раз больше, и это уже не локаль, то хозяева хостинга могут обидиться на мой "
UPDATE WHERE... LIKE '%\n%'
ночью буду запускать + возможно сделать простой в выполнении каждый раз по 1-5 секунд ждать.
согл. потверждаю. вплоть до истории болезни...
д.
Иногда при нехватке данных, хостер просто регистрирует домен на себя.
p.s. Я в таких случая регистрирую на соседа ;)
Ребята я же помощи просил, а не критики.
как текст хранится в базе:
Чтобы выводить его в более-менее понятном виде, пользую
<pre>
Тогда получается форматированный текст но длинные предложения вылазят.
Могу на лету заменить \n -> br, но затраты времени ЦП недопустимы.
p.s. взглянул на свежую голову, временно решение проблемы найдено с помощью формирование текста на лету! ☝
Дальнейшее решение вижу в изменении организации текста в самой базе. Правда ЦП не хочется по начам насиловать ;)
Согдасен, либо самому написать :)
А то действительно получается, после установки скрипта в директориях оказываются непонятные фаилки дамперы.
Ладно поглядим, что нам скрипто покажет, вроде цена не кусачаю.
Но необходимо также и рассылка по mail адресам зарегистрированных пользователей.
p.s.
Получается nulled - негласная отплата своими нервами или трудом разработчикам у которых своровал скрипт., Так как те кто его обнулили, постарались над ним...
там так и есть :)
для <p> я предусмотрел стили.
Но длинные предложеняи порождают скрол.
Раньше с подобной проблемой я боролся путём указания явной ширины DIV в стилях, а тут, хм.. не получается.
выставлял в ститлях ширину для pre или<p> (он в тексте преобладает) рез. нулевой
отписал в ЛС
Скинул.
Вот-вот :)., получается либо компактно но неудобно для конечного пользователя, либо форматировано но с скролом :))
