Все эти шаблонизаторы не нужны, они всё равно будут приводить код к формату php (компилировать) и потом его исполнять. Я застал smarty на первой ветке и долго плевался от него пока lokanaft не переделал шаблон на php. В итоге только нагрузка на железо снизилась, а в остальном также надо изучать сам шаблонизатор и доступные данные, кторые можно передать ему. Так не проще ли потратить это время на изучение php. А вот вариант с правкой файлов существующих шаблонов из админки, это уже можно рассмотреть. Опять же если попадется «злобный админ», так он может и напакостить с этой опцией неплохо.
Loadырь
Простите, перепутал с подписками. Посмотрел файлы компонента избранного, хуки для форума присутствуют, вохможно они отключены в «Админка — компоненты — управление событиями»?
А настройки форума смотрели? Вкладка «Просмотр темы».
То есть, получается, если у второй книги 3 главы, а у первой 2, то у первой будут пустыми ячейки. А если автор назовёт свою главу не «Глава 1», а к примеру «Первая Глава. О волке», то вообще ничего не получается. Куда ставить новое название главы?
Все записи в таблицах заполняются не слева на право, а сверху вниз. В этом случае не важно сколько глав будет в книгах, все главы будут в одной таблице и у каждой главы будет свой book_id. У глав одной книги этот book_id будет одинаковым.
З.Ы. Мое мнение, что файлы каждый раз парсить, дробить на главы и т.п. перед выдачей читателю, лишняя нагрузка на «железо» и лишнее время ожидания для читателя. Проще из базы вытянуть данные уже готовые к выдаче, чем вот это всё.
И хозяину пришлось переделывать логику когда стало много книг.
Да, бывает. Практика показала, что запросы к БД бывают разные. Их периодически надо оптимизировать, как сами запросы, так и саму структуру базы данных. Перед выходом 2.18.0 Fuze решал вопрос, как мне создать запись в одной из 16800+ категорий и при этом не повесить сайт наглухо. Старая версия cms обрабатывала запрос на пересчёт количества записей в категориях более 40 сек. Новая версия справилась менее, чем за 1 сек. Функционал остался прежний, но скорость обработки стала на несколько порядков выше, что в свою очередь снизило нагрузку на «железо». Тут всё очень сильно зависит от опыта разработчика.
Всё зависит именно от того в каком виде у вас сами книги. Если вы их печатаете прямо на сайте или «парсите» из файла, то тут лучше в базе хранить, а если вы отдаете читателю сам файл книги на просмотр, то тут хранить только в файлах остается. Но в случае с файлами вы не сможете заблокировать доступ к некоторым страницам книги или сделать платной 70% книги или главы и т. п.
Вы видимо с базой данных никогда не работали, поэтому вариант с платным дополнением вам наверное лучше подойдет.
Но если хотите знать, то как я писал выше вам надо определить «минимальную единицу». Например книгу можно разделить на тома/части. Тома/части можно разделить на главы. Главы можно разделить на страницы. Страницы можно поделить на параграфы )), но это в вашем случае уже точно лишнее. Поэтому у вас получатся такие таблицы:
1. Страницы всех глав всех книг
2. Главы всех книг
3. Тома/части всех книг
4. Книги
Плюс добавится таблица с авторами всех книг. Итого — максимум пять таблиц в базе данных будет.
Опять же, если пользователь вашего сайта захочет почитать, то каки образом вы ему предоставите эту возможность? Как вы будете хранить книги? и т. п. вопросы вы не озвучили. Если книга это файл в формате pdf, doc, txt и т.п., которую можно скачать, то для этого достаточно создать поле для загрузки файлов в нужном типе контента. И ничего более не надо делать. Если вы делите книги только на главы и показываете читателю всю главу сразу на одной странице, то у вас будет всего три таблицы в БД:
1. Главы всех книг
2. Книги
Плюс добавится таблица с авторами всех книг.
Чем больше будете добавлять книг будет расти число записей в этих таблицах, а не количество таблиц.
В безплатном компоненте Книги говорится, что книги хранятся в файлах на сервере, а не в БД. Насколько это лучше или хуже?
Доступ к информации будет одинаковым, но хранение в базе позволяет структурировать данные и использовать эту структуру более удобно.
ruccich, вам надо сначала определиться, что будет у вас «минимальной единицей» — книга, глава или страница главы. Что из этого будет отображаться на экране пользователя. Это и будет ваша основная таблица. А далее к ней будут подключаться таблица с данными по главам, (если будет постраничный вывод), таблица с данными по книге, таблица с данными по по авторам. Потом если захотите, то привяжете таблицу с данными какие пользователи на какой главе/странице остановились и т. п.
кто бы хоть часть сделал?
12 и 13 уже есть в дополнениях
Тогда смотрим в логи ошибок.
Скажем иначе оба сайта физически расположены на одном сервере или на разных?
Но сайт почему-то по адресу test.ru не отрывается, ошибка 500
Смотреть логи этой ошибки, скорее всего к базе данных нет доступа.
Ночную версию инстант с биллингом ставить на сайт с биллингом старым или можно и на сайт без биллинга ?
Ночная сборка не предназанчена для обновления действующего сайта. Она только для первичной установки.
Смотрите на работу сторонних хуков? Особенно тех, где есть слово "..form.."
Просится обновление компонента iforms и возможно других. Для начала в файле system\languages\ru\loadir_iforms.php удалите или закомментируйте строку содержащую LANG_GUEST
И не забывайте, что в некоторых релизах есть раздел «В этом релизе удалены файлы:», который иногда обязательный к исполнению. Например тут instantcms.ru/novosti/release2160.html