LiveStreet CMS

Пользователь авторизован, исполняется на домене с LS.

Продолжаю без особых успехов сражаться с движком. Пока единственное, чего достиг, это отсутствие сообщений при исполнении этого кода (никаких ошибок!):

error_reporting(E_ALL);
ini_set('display_errors', 1);
define('LS_VERSION','0.3.1');
define('SYS_HACKER_CONSOLE',false);

set_include_path(get_include_path().PATH_SEPARATOR.dirname(__FILE__));
chdir(dirname(__FILE__));
require_once("../config/config.php");
require_once("../classes/engine/Router.class.php");

$_REQUEST['blog_id'] = 2;
$_REQUEST['topic_title'] = 'xz_topic_title2';
$_REQUEST['topic_text'] = 'xz_topic_text_2';
$_REQUEST['topic_tags'] = 'xztag1, xztag2';

$oEngine = Engine::getInstance();

require_once('../classes/actions/ActionTopic.class.php');

$topic = new ActionTopic($oEngine, 'add');
$topic->SubmitAdd();

Однако топик не создается. SubmitAdd сделал публичной функцией, но ничего не помогает.

Может я не туда копаю?

Может попробовать «статические страницы» сделать через экшн.

А как вставить php в статические страницы?

Один из тех редких случаев, когда ответ содержится в вопросе.

Очень мило. Нет, правда.

Это я понимаю — сам сталкиваюсь. Нет проблем.

Чуть больше пафоса, господин девелопер.

Готов дорабатывать, но отсутствие целой таблицы в двух ревизиях стало подозрительным, потому и спросил. Теперь разобрался, что слепой. И, к слову, разработчика я не дергал.

Ой, забыл про него. Спасибо.

Спасибо, повеселили :)

Ну, про толк уже говорилось.

Думаю, не только я буду премного благодарен за реализацию этого до релиза с шаблоном. Просто это ключевой момент, и если ввести предопределение путей к экшенам уже после нового шаблона — последующие шаблоны уже не будут совместимы.

Давайте разовьем тему — так же ввести голосование за эти комментарии с обснованиями оценок. Естественно, с возможностью за них голосовать. Ну и само собой — с обязательным комментированием оценок к комментариям с обоснованием оценок, куда без этого.
Собственно, это — обоснование моего минуса топику.

В смысле, поддерживаю.

Забавная корреляция livestreet.ru/blog/wishlist/269.html

Черт, кажется я только сейчас понял шутку про «денормализацию». Прошу прощения.

В этом случае, все-таки «декомпозиция». Если уж придираться к терминам, то «нормализаия БД посредством декомпозиции таблиц».

При использованпии ключевых слов в адресации — это совсем даже не «дублирующие даные», ключ же остается прежним — ID, а URL — просто ячейка, информация из которой будет задействована при большинстве (если ни при всех) запросов к строке.
Мы же говорим о варианте «/blog/wishlist/269/puti-k-ekshenam», а не о «/blog/wishlist/puti-k-ekshenam»?

Да.
Во-первых, это не обязательно для поисковиков — это важно.
Во-вторых, глубина для поисковиков — это доступность, начиная с главной. Т.е., если эта ссылка будет, к примеру, на главной — она вполне даже доступна, и считается вторым уровнем.
В-третьих, Яндекс и Гугл прекрасно индексируют страницы, доступность которых более ста кликов. Даже для сайтов с нулевым PR и иЦ — могут быть проиндексированы в течение месяца. И это я не на ходу придумываю :)

Конечно же, проще в той же таблице, никакого выигрыша в оптимизации нет, т.к. основные запросы к таблице топиков — это их вывод и ссылки на них, где этот url и будет задействован. Излишняя декомпозиция — таки враг.

А насчет мифа о «лучшем индексировании с .html» — стоит просто задать себе вопрос: правда ли, что страница /blog/wishlist/269.html лучше проиндексирована, чем страница /blog/wishlist/? И после этого перестать забивать голову подобным.

Еще одним важным плюсом осутсвия .html — увеличение глубины в структуре. К примеру, /blog/wishlist/269/comment/12121
Гооврить о пользе этого — смысла нет, это просто пример, но где это может пригодиться — вариантов множество.