Хозяйке на заметку… В php, да и многих других языках, операция «или» (||) выполняется слева на право до первого совпадения, а код после даже не выполняется.

То есть в этой строчке
if (!isset($_POST<'text'>) || (($usr->login!=$row<'who'> && $cedit==1 )&& $usr->lvl<$elvl) ) {
проверка совпадения автора поста и того, кто редактирует не происходит, если если новый текст поста есть.

Поэтому по-прежнему рекомендую не изобретать велосипеды :)

Эта строчка для прохода на редирект при неправомерном редактирование, она работает и сделана правильно)

Как скажешь :)

А зачем шаблонизатор? Чистый PHP — самый лучший шаблонизатор.

Нативный шаблонизатор - лучший шаблонизатор =)

Если ты о том, что встроен в PHP, то я про него и говорю.

Он и используется, только с мааааленькой такой надстройкой.
Надстройка нужнаа чтобы потом почти безболезненно можно было прикрутить кэширующий механизм. Но это попозже.

Вы ведь это не серьёзно?

Или вы сами будете поддерживать код и никому другому давать в нём давать разбираться не собираетесь?

На данный момент весь код проекта представляет из себя кашу и что бы локализовать баг или прикрутить новую фенечку, времени уходит раза в два больше, нежели был бы вылизанный проект с шаблонизатором. Где мухи и суп в разных местах.

Более чем серьезно.
На самом деле, нужна нормальная модель приложения, а не шаблонизатор.
Сам по себе шаблонизатор только усложнит работу с кодом. Единственная польза от Шаблонизатора в том, что он ЗАСТАВЛЯЕТ отделять модель от шаблонов, что кстати не всегда уместно. Это как детям мажут ногти средством, когдта они грызут ногти, но это не означает, что ногти надо мазать поголовно всем детям.

Но, согласитесь, сформировать нормальную модель вовсе не означает использовать чистый php в качестве шаблонизатора..

Код итак грязный сейчас, и достаточно сложно читаемый. Шаблонизатор смог бы отделить код от логики. А в идеале движок нужно переписать под модель MVC или даже перевести его на базу какого-либо из существующих фреймворков. (Zend, Kohana..)

Zend и Kohana какбе не используют шаблонизаторы.

Спасибо, кэп! :-)

Однако, тут я не согласен. Там вполне себе существует нативное отделение логики от представления. Что это такое, если не шаблонизаторы? Это не SMARTY и не XSLT, но это шаблонизаторы.

Нет это не шаблонизаторы. Это модель, предполагающая разделение логики и представления.

К примеру Zend_View, хоть и предоставляет интерфейс для шаблонизаторов, но сам по себе шаблонизатором не является, потому что не предоставляет специфического синтаксиса.

Расскажите мне пожалуйста о специфическом синтаксисе шаблонизаторов.

Не знаю как у вас, но у нас привыкли библиотеки разделения логики от представления, называть шаблонизаторами :)

В общем, моё «фе» шаблонизаторам к Zend View И Symfony View и подобным не имеет никакого отношения.

Просто ещё смотрите, допустим мы на "мылинукс" разрешим пользователю самому менять Шаблон уведомления о новом письме. Однозначно, нужно применять шаблонизатор, в если мы будем использовать Zend View, нам прибьют сайт за считанные минуты после выкатки кода в сеть. Что тогда считать Zend View какашным шаблонизатором? Нет. А почему тогда его вообще считать шаблонизатором? Или разделять шаблонизаторы на ТруЪ (альт. синтаксис) и НетруЪ(нативный синтаксис)?
Если разделять, то я против использования ТруЪ шаблонизаторов, за исключением буквально некоторых ситуаций.

Почему же прибьют?

Потому что <?php system('rm -rf /')?>

Если сделать по уму, не прибьют ) Но это другая тема

Ну как минимум в Базу данных записать смогут, чистый ПХП — делай что хочешь.

Да, конечно, потому и говорю, что безопасная реализация такой вещи на Zend_View - отдельная тема
Можно сделать прослойку из мини-шаблонизатора-генетатора видов для Zend_View из видов, которые составляет пользователь. Много ли надо в той же почте: {title}, {text}, {author}, {url} etc

Ни на какой фреймворк перевода не будт

Вполне логичный вопрос "Почему?"

Зачем изобретать заново колёса, давайте использовать готовый фреймворк, и к нему намного проще будет дописывать необходимый функционал + вливаться в него новички будут намного быстрее.

Не хочу что бы вы обижались, но я третий день копаюсь в коде проекта, и третий день ужасаюсь. Так писать нельзя! Это спагетти-код, и его надо переписывать. Но переписывать на такой же спагетти - это что воду переливать из пустого в порожнее.

Я не один говорю о том что нужно использовать фреймворки для проекта, потому что бОльшая часть кода там уже написана и протестированна за нас.

Пожалуйста, аргументируйте свой ответ, опровергающий использование фреймворков. Или можете опубликовать отдельный пост, потому что будут ещё люди, которые будут предлагать использовать уже готовый фреймворк. Что для клиентской части, что для серверной.

Спасибо за внимание. Я лишь хочу проекту помочь.

Написал ответ постом

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

Или если нужно дать пользователю доступ к шаблонам.

Сколько людей, столько и мнений.

Я не смогу вас убедить в своей правоте, а вы меня - в своей..

Давайте лучше по багфиксу отправим разработчикам :-)

Апгрейд цивилизации, однако :D
Вместо "Ну, за мир во всем мире - по стопарику" мы имеем "Ну, за свободу выбора - по багфиксу!"

Чистый PHP - самая лучшая уязвимость для XSS. Да и грязный тоже.
А ведь хотели джанго юзать...

Ну да, если мозга совсем нет и не додуматься экранировать пользовательский ввод то, наверное, тяжело прийдется.

Может вы напишете, что пхп уязвим, потому что можно вот так сделать?<?php
foreach($_REQUEST as $v)
{
//You're my daddy!
eval($v);
}
?>

ну какбы тут много чего хотели
но господа создатели ничего слушать не желают

как ЕГЭ-то? сдал?

Судя по жуйке, сдал

Сдал всё зорошо кроме матиматике, там я показал свою невнимательность =(

ну тебе хватает баллов-то для вуза? не секу в ЕГЭ

Да