virus бьывает =)))

Глянул тут код.. коментарии будут такими

а). О приёме данных из POST - первое что бросается в глаза есть отсутствие trim, а это весьма не маловажно... если я поставлю хоть 1 пробел в оба поля, они пройдут валидацию. Ошибка принципиальная, сводящая на нет всю проверку.

б).

был прав тот человек, который говорил о die

тоже самое, 1 в 1, но короче и так же понятно, если не ещё более понятно.
btw


в).
Между прочим, file_put_contents блокирует сама фаил на запись, когда она его пишет, это раз. 2 - она сама создаст фаил, если его не существует, это 2. 3 - она может работать в режиме полной перезаписи, так и добавления нового контента. После отработки сама же убирает блокировку - это 4. И это будет работать быстрее чем такой же код на PHP c помощью flock, is_writeable (нам нужен цикл, что бы проверять можно ли в него писать или нет, что бы дождатся момента когда можно это сделать!), fopen, fwrite, thruncate - ибо код функции написан на C, а не на PHP... так что она даже если работает помедленее простого открытия-закрытия, то уж 100% куда быстрее чем открытие, блокировка, очистка, запись, снятие блокировки и закрытие фаила на PHP

Так что по моему мнению код должен выглядеть где-то так, к тому же я добавил постраничный вывод, что бы она не была уж совсем такая простая... настолько простые никто не делает! Даже для учебных целей слишком тривиально!

Добавлено спустя 2 минуты, 8 секунд
P.S. Код не проверял, возможно постраничный вывод потребует отладки Не стоит у меня щас HTTP сервака на локалке что бы можно было бы проверить
P.S.S С сериализацией можно сделать так же как и делал virus, вытаскивая из фаила целиком сеализированные данные и потом обрабатывая с помощью постраничного вывода как у меня этот масив, получится тоже нормально. Но есть одна вещь - serialize/unserialize имеет весьма сложный синтаксис упаковки/распаковки переменных, потому что может упаковать всё что угодно - от переменной обычной до масива или целого объекта. А упаковка многомерных масивов весьма тяжелая вещь (в данном случае у нас двумерный масив получится, как это сделал virus). У меня же функция пусть вызывается много раз, но она распаковывает:
a). Масив из трёх элементов, одномерный
б). Только 15 записей за раз максимум, а не всю гостевую книгу (а в книге сами знаете, может быть и 5-20 записей, а может 200-400 и больше. Представте сколько сожрёт ресурсов распаковка такого большого масива.... Думать надо о таких вещах сразу, потому что это элементарнейшая оптимизация).

P.S.S.S. A вообще, в плане потребления памяти скрипт весьма весьма не продуман. Чем больше записей в гостевой, тем больше памяти съедает скрипт. В определённый момент можно натткнутся на лимит выделенной памяти на скрипт. Если уж писать действительно более-менее хорошую гостевую на фаилах, надо делать подобие SQL таблицы, с чёткой структурой, где одна запись это N байт. И с помощью fseek ставить в нужное место и читать PER_PAGE блоков, после чего закрываем фаил и уже работаем с выбраными данными. Единственный минус - придётся дописывать какие-то служебные символы в запись, что бы они имели чёткий размер. Если же делать динамический размер, то надо держать какой-то служебный фаил где отмечено, какая запись с какого байта находится и сколько она занимает... А это уже похоже на базу данных, тольк она PHP Проще использовать SQLite или MySQL Хотя если нету такой возможности, то можно и реализовать простейшие механизмы. Вообщем тут всё зависит от задачи которую надо выполнить и на что оно должно быть расчитано


Вывод: надеюсь я заставил вас задуматся/подумать

- спасибо за реабилитацию =)))

1 - Он говорил о том что надо выводить ошибку, а я говорю что вывод текста ошибки пользователю недопустим, это должно контролироваться error_reporting-ом и должно быть включено только в режиме отладки
2 - Сама проверка с помощью "or" так-же имеет принципиальную разницу, однако не такую сильную, просто это более показательно (это всё-же демонстрационный скрипт), во вторых так мы вызываем функцию, а так мы в рамках "if" мы делаем что хотим и как хотим (на моём примере "exit")

Тут ты прав

file_get_contents появился только в РНР-4.3
file_put_contents появился только в РНР5
Не смотря на то что РНР ниже 4.3 уже трудно найти РНР5 (пока что) стоит далеко не на каждом хостинге

Памяти станет не хватать когда сообщений перевалит за сотни (возможно тысячи), к тому времени человек успеет выучить РНР и написать своё (так как скрипт расчитан на тех кто учится а не тех кто просто юзает в реальных условиях)

У меня к примеру там где стоит гостевушка подобная этой (только написаная ещё в феврале) 44 сообщения занимают всего 14кб

Кстати построничный вывод у тебя перегружен сильно, всё тоже самое делается в 100 раз проще, в том случае если get-oм передавать не номер страницы а номер сообщения с которого начинать вывод (как на рнрВВ)

Да и в целом твой вариант помимо достоинств имеет КУЧУ недостатоков (первое что бросилось в глаза strip_tags перед записью в базу)

А уж на счёт демонстративности я и вовсе молчу, даже я не сразу смог его запустить, а когда подумал поправить то что ты возможно упустил то чуть не заблудился в коде
Кстати у тебя так-же проблемы с символами "\r" и "\n" в сообщении, в твоём случае надо не strip_tags а что-то типа rawurlencode или base64_encode, однако в таком случае сериализация вовсе теряет смысл, проще делать (пару лет назад я так и делал) explode
Добавлено спустя 52 минуты, 11 секунд


Вовсе шедевр, просто в музей генеальных решений можно заносить
Добавлено спустя 12 минут, 47 секунд

Надо записывать каждый пост в свой файл, и иметь файл "кеширующий" информацию о их именах и датах, что касается расхода памяти это единственный выход, но смысл моего-же скрипта АБСОЛЮТНО не в этом...

Про шедевр - дай другое решение Зато у тя 100% не будет проблем с одновременной записью Нужно бы добавить таймаут небольшой, что бы не крутить цикл на всю катушку. Пара миллисекунд хватит.

strip_tags вырезает теги HTML и PHP - и это правильно. Нельзя давать юзеру писать такие вещи в сообщении. Резать. Жётско и без предупрежедения - это нормальная практика любого нормального проэкта.

Возможно я уже отвык от таких мелочей

Дык, нормер сообщения... Да, возможно, но всё же юзеру боле понятен номер страницы...

Сколько можно цеплятся за PHP4? Он медлителен, да и не приучает писать правильно. А вообще по поводу того, что это учебный пример... вот так потом те, кто учатся, и пишут... в итоге имеем на кучу таких "умников" одного человека, который реально разбирается и понимает. А потом и получается, что PHP не рулит (а юзать сами не умеют), юзайте Java... она быстрее и.т.д. и.т.п... А в итоге у меня бегает Bittorrent трекер на PHP c солидным запасом на будущее, когда другие многие трекеры при половине моей нагрузке уже дохнут... А сервачки там и по мощьнее стоят чем мой.


ааа! Держите меня, я ща умру
Знаешь, вот расмешил так расмешил... Незнаю как вы, а это ПРОСТЕЙШИЙ код. Ты же умудрился в паре десятков строчек заблудится (которые кстати элементарно читаются, разделены на блоки, правильно отформатированы). А мне приходится иметь дело с кодами по 20к строк и больше.. а там чего только нету, и MySQL запросы с немеренными JOIN, и AJAX, и ООП... да вообще полный завал для человека со стороны и со средними знаниями PHP.. В этом и проблема обучающих примеров - они настолько далеки от реальности, что человек, столкнувшийся с реальным кодом понимает, что он ничего не понимает. Я таких "программистов по PHP" повидал достаточно уже, что бы в этом убедится... Не зря я свою зарплату получаю наверно, а она даже по нашим меркам (я не говорю про СНГ даже) выше среднего.

О \r и \n - да, с этим чутка запара будет, но это решаемо. Для фаилов вообще можно просто тупо сделать htmlspecialchars и nl2br ДО записи в фаил Потому что о каких может быть идти речь RSS и.т.д., если у тебя нету нормальной базы данных даже. Так что такая гостевая дальше чем просто вывести сообщения не пойдёт, а в этом случае нам обсалютно всёравно в каком виде там хранятся данные - в котором пришли. или в котором выводятся... второе куда лучше, ибо это почти как статичный HTML - быстро и не съедает много ресурсов. Для чего-то более большого я буду использовать базу, ибо это есть правильно. А вот в самой базе уже конечно, буду хранить в том виде, в котором пришло, но вырежу через strip_tags всё лишнее (а BB Code останется )

Ошибку пользователю надо показывать, но friendly. Тобишь в данном случае просто вместо самой гостевой вывести сообщение о том, что она в данный момент не доступна. Это будет правильно.
Добавлено спустя 10 минут, 49 секунд

И иметь кучу мелких фаилов на фаиловой системе? Нет, это точно хуже. Вообще тут надо юзать базу данных, только и всего.
Не, нормальный выход, это умное чтение из фаила, только и всего. Для небольшой гостевой нормально, но для более-менее часто посещаемой - надо базу данных. ФАКТ.
Вообще PHP без базы данных как то не вяжется Если что-либо храним, пользуем базу Если нету базы, есть SQLite. Нет и его - что это за хостинг такой... а халявный сыр только в мышеловке.

А смысла в скрипте.. Показать, как сделать не правильно (но об этом умалчивается), а люди не обращают внимания на приписки типа "Обучающий пример" - работает, значит можно юзать - Copy/Paste - оо, я крут, сделал гостевую! И не летайте в облаках что это не так Это именно ТАК!

Можно и нужно, фильтация должна быть при выводе и она есть!
Иначе как ты бы сюда запостил свой код ?

Хорошо не буду умалчивать, поясню.
ДА ЭТО НЕ ПРАВИЛЬНЫЙ ВЫБОР ДЛЯ РАБОТАЮЩЕГО САЙТА
Но структурно всё правильно
- отсутсвие фильтрации "исходников"
- наличие фильтрации при выводе
- разделение РНР от HTML
- разделение базы от вывода
я могу продолжать и продолжать
И именно это и демонстрирует скрипт...

Обидно что даже ты выдаёшь такие "финты" типа запись в базу "кастрированных" данных...
Добавлено спустя 23 минуты, 57 секунд

Для небольшой гостевой (способной за всю свою жизнь набрать меньше пары тысяч сообщений) нормально и на куче мелких файлов, а посещаемый сайт (или вовсе огромный портал) поставит себе гостевуху на базе (или вовсе форум) а "учебные" в свою очередь гостевухи редко за всю жизнь набирают пол сотни сообщений, и при таком раскладе мой скрипт очень даже подходит


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

virus я там отписал =)) сразу замечу, что понятно, что залитый скрипт с расширением jpg, допустим, не выполнится, но опять же =))) это собирание хлама... если не делать проверку на содержимое...
Добавлено спустя 17 минут, 15 секунд
З.Ы. на всякий слуай =) include из папки загрузки запрещен ? ))

Ну есть разница между форумом, специальными тегами для кода () и просто гостевой, где ничего, кроме как просто вывести текст, обрезав определённые вещи, не нужно Само собой что в нормальной системе форматирование производится при выводе, а в умных системах делается кеширование

Иногда проще сделать тупо и в лоб, чем извращятся и делать что-то пупер-умное для простых вещей - трата времени и сил KISS - Keep It Simple Stupid - это лозунг PHP А то некоторые пытаются на PHP сделать то, что можно на C/C++ или Java сделать (пример? PEAR - перегруженно, медленно, НЕ ЮЗАБЕЛЬНО (кто хочет поспорить, сразу предупреждаю - был _очень_ печальный опыт работы с PEAR::DB + Smarty... Результат: проэкт был переписан с 0. Благо ни я его начинал вообще, ни я его переделывал - я в проекте участвовал за месяц до запуска - когда почти всё готово было до момента, когда его взялись переделывать), так что по этому поводу спорить со мной бесполезно - опыт и факты вещь очень упрямая).

Вообщем проехали, тема довольно бесполезная, да и отписался ты щас правильно, поддерживаю

Ну постраничный вывод из базы данных вообще дико простой, 1-2 строки от силы С фаилами по сложнее, надо же определить начало и конец элементов масива, которые надо выводить + проверить, что бы не вышло из-за границ База то просто не вернёт данные, а при масиве будет ошибка о не существующем индексе, поэтому у меня ип слегка перегружен постраничный вывод
Вообще постраничный вывод у меня выглядит в текущем проэкте таким образом

Где $paging это уже HTML таблица со всеми данными в ней, просто передаю в шаблон и тупо вывожу - работает идиально и удобно
P.S. SQL_CALC_FOUND_ROWS рулит
Добавлено спустя 45 минут, 45 секунд
З.Ы. Можете поздравить, поступил в институт. Кафедра компъюторных наук, на программу "Бакалавр програмного обеспечения интернет технологий"
З.Ы.Ы. Со своей завтра пол года как встречаюсь

Проще поставить "strip_tags" вместо того чтоб поставить "htmlspecialchars" ?
И чем это проще ? (тем более что второй уже и так там стоит)

С точки зрения подсчёта страниц и их номеров одно и тоже в точности

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

strip_tags вырезает HTML и PHP код, тем самым физически убирая мусор. А nl2br и htmlspecialchars можно применить как до записи, так и на выводе - тут зависит от того, будем ли мы делать что либо с данными кроме простого вывода на экран или нет. Только и всего

Ну можно и так сделать постраничный вывод конечно, но не очень красиво, ИМХО Я лично в сайтах пользуюсь mod_rewrite, посему у меня урлы выглядят типа такого: http://example.com/news/today/2.html - 2 - это страница Если бы был ID, смотрелось бы слегка не красиво ДА и новости могут быть по категориям разложены, посему ID, с которого начинать тоже не всегда есть правильно.

Теги это не мусор, это часть сообщения, мало ли я хочу запостить исходник моей гостевой в неё-же ?

Не хочется начинать полемику но я (и не только я, это на всех форумах обсуждалось и не раз) настаиваю на том что до записи в базу вырезать что либо недопустимо...
Добавлено спустя 8 минут, 4 секунды

Так это не ID это порядковый номер уже из результата выборки
(правда на файлах выборку делать немного сложнее)

Кстати чтоб не касаться спорных вопросов о ресурсоёмкости обработки файлов предлогаю обсудить вариацию под MySQL
- ссылка - для тех кто на нормальных браузерах
- ссылка - для тех кто на устаревших браузерах
(написана синхронно с прошлым вариантом по этому все недостатки первой есть и тут, кроме конечно тех которые обусловлены файлами)

Господа, подскажите, что такое
и для чего он нужен. Желательно ссылочку на какой нибудь FAQ и т.п. Мне надо понять для чего это а не как работает и как его администрировать.
Заранее спасибо.

Peter_P
Это язык программирования типа perl или php.

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

Еще раз спасибо ответившим, я нашел уже в википедии кое-какую информацию по нему, точнее по просто pythonу - между ними, я так понимаю не очень большая разница?
Вопрос такой общетеоритический - есть некий статический сайт - странички одна статика + интеактивные сервисы написанные нашим субподрядчиком (я так понимаю на этом самом python), сервер (железка), на которой он стоит имеет следующую спецификацию ПО - Сервер базы данных – MySQL 4.0.22.
Веб-сервер – Apache 2.0.54 + mod_python (больше инфы нет). Правильно ли я понимаю что речь скорее всего идет о интерпретаторе языка mod_python? Просто связаться с субподрядчиком возможности нет.

Стоит модуль для языка python - так же как и для PHP, Perl, и.т.д. Это API что бы Apache понимал фаилы python и позволял им работать как WEB скриптам

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

PHP это WEB, а python всё же системный язык. Так что в этом коренная разница.
Кстати, Perl PHP уже давно перегнал, и сильно

Давайте поговорим о способах оптимизации работы сайтов любыми средствами - рефакторинг кода, кеширование и прочие другие решения, которые реализуются с помощью PHP и средств, работающих с ним в связке. Думаю это будет многим полезно
Своё напишу вечером, ибо на работе особо не разгонишься

_Psih эээ... ну ждем =)))