не понял, как это гостевая во многих файлах и большого объема кода?
там кодировать-то на одну страничку.

отнюдь не один файл
http://www.lkcc.org:8500/downcount/down ... o=0&what=0

Analog Ну если ты скачал гостевуху, в которой тебе 99% не нужно и в которой ты не в состоянии разобраться — скачай гостевуху попроще-то

точно, спасибо
Но тут другая проблема - половина гостевух (в т.ч. с большим рейтингом) у меня не работает как надо.
Даже старая гостевуха которая работала, теперь при нажатии "Отправить" бросает в начальную страницу гостевухи и ничего не добавляется, в остальных при нажатии "написать" просто Рефреш случается.
Что не так ?
Пробовал AppServ старый, с пхп 4 и сижу сейчас на новом аппсерве - везде одна и та же фигня.
На денвере когда сидел все было ок.
Что не так ? гостевухи точно рабочие.

без кода сказать сложно, телепаты на море купаютси.
сам апач-пхп точно работают? простая форма принимает данные?

все работает, портал, форум - все ок, а часть гостевух - никак.
например вот эту захотел, очень популярна - а не работает как надо..
http://www.woweb.ru/load/55-1-0-4010

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

вопрос по РНР. Как сделать чтобы скачивать файл могли только зарегистрированные пользователи? ну или вообще.. как программно комуто разрешить или запретит качать файл с сервера?

.htaccess

pretorian Положить в закрытую папочку, отдавать скриптом типа


Добавлено спустя 1 минуту, 7 секунд
armadillo Basic Authorization неприятно будет увязывать с зарегистрированными пользователями…

Anoss угу.
Только папку лучше положить выше корня.

Нужна помощь с php.
Значит имеем: скрипт для загрузки картинок и хостинг от инфобокс.


Суть проблемы: в IE при попытке загрузить картинку просто ничего не происходит, Safari выдаёт сообщение:
----
Length Required

A request of the requested method POST requires a valid Content-length.
chunked Transfer-Encoding forbidden: /admin/imgupload.php
----
Картинка ессно не загружаецца.

В чём ошибка?))

по умолчанию он в темпкаталоге. права есть? проверяй на все папки.




// end if $error_flag
Добавлено спустя 39 минут, 58 секунд

Enctype у формы неправильно написан… enctype="multipart/form-data"

armadillo Anoss
спасибо за ответы

Но у меня возникли очередные ламерские вопросы )
1. Куда вставить Headers и что означает переменная $user_fn? ))
2. Осталось непонятным что означают параметры т.к. в изначальном скрипте у меня один параметр
3. На данный момент скрипт заработал, но он грузит картинки в папку где он расположен. Как бы это забороть?

Сейчас скрипт выглядит так:

Забудь про них, тебе же не надо этот файл обратно отдавать — вон ты и print закомментил..

Там, откуда armadillo скопировал свой код, поле в форме называлось «filename», а не «simg»



move_uploaded_file не в $simg_name, а в «"путь/к/папке/$simg_name"»

Разобрался) Всё работает. Спасибо за ответы

1)Читая мануал по MySQL главу 7.5.8 (refman 4.0 ru) пришел к очень интересному вопросу(или заключению, смотря как рассуждать).
Представим себе следующую ситуацию: (рассматриваем с точки зрения web программирования)
Есть некоторые данные которые могут редактировать скажем как пользователь так и администратор.
Пользователь решил воспользоваться своими правами редактирования и соответственно выполнил SQL запрос (возможно сам того не желая)
к базе данных(select запрос).
Ему в форме будут доступны данные которые он правит, а потом отправляет запрос на обновление.
В это время администратор тоже подал запрос на эти же данные, но до того как пользователь успел их обновить. А запрос на изменение данных подал позже.
В результате одни данные перекроют другие.
Впринципе, ничего страшного, но появляется некоторая несогласованность...
Вопрос №1: Как ее избежать?
Ответ №1
Можно использовать транзакции, тем более что InnoDB поддерживает их + блокировку строк. Но в контексте web программирования я не слишком понимаю как это выполнить (PHP например, после завершения сценария закрывает все подключения к БД).
Ситуация описана выше. Мы открываем нашу БД.
Делаем запросы:
START TRANSACTION - начинаем транзакцию
SELECT * FROM TBL WHERE ID = '14' LOCK IN SHARE MODE; - выбираем самые свежие данные и блокируем их.
НО! Дальше данные будут выведены в форму для редактирования пользователем, значит скрипт на PHP закончит свое выполнение а => закроются все открытые соединения. Наша транзакция и блокировка на данные будут утеряны, а значит администратор опять сможет получить к ним доступ и возникнет ситуация номер 1.
2) Извесно, что чаще всего хост провайдеры ограничивают количество подключений к БД. Часто видел ситуацию когда количество подключений к БД может быть не более 1.
Что это порождает? Невозможность использование транзакций.
Представьте, если на сайт одновременно ходят большое количество человек и скажем большое количество модераторов и администраторов. Чтобы использовать транзакции модераторам и администраторам нужны выделенные подключения или я не прав.
Чесно говоря не уверен в этом. Но в мануале написано, что вложенные транзакции не допускаются, и у меня в голове возникает следующая ситуация:
Пусть количество соединений(одновременных) = 1.
Администратор выполняет некоторые запросы к БД(они связаны с операциями, которые требуют объявление транзакции).
В это время приходят два модера и тоже начинают проводить свои операции, в то время как администратор делает свои дела(используя транзакции).
Результат: даже не знаю что из этого получится =)

Вопрос мой остается в силе:
1)Как избежать тех ситуаций, которые я описал( в рамках web программирования на PHP).

В ходе рассуждений возник еще один вопрос:
Транзакции - это последовательность операторов SQL, выполняющихся как единая операция, которая не прерывается другими клиентами. Тоесть пока происходит работа с записями таблицы, никто другой не может получить доступ к этим записям, т.к. субд МуSQL автоматически блокирует доступ к ним.
Это определение транзакции данное в книге MySQL5. Мануал по MySQL 4.0
расширяет это определение и говорит о том, что возможно использование блокировок на определенные строки и другие блокировки в рамках одной транзакции. Прав ли я, когда говорю что все блокировки, равно как и сама транзакция теряется, если скрипт заканчивает свою работу, либо явно вызвана команда о закрытии соединения с MySQL или же она будет не будет утеряня?

P.S. Простите что так много. Уже два дня мучаюсь над этим вопросом - много накипело =)

Ответов на сто процентов отвечающих на твои вопросы пожалуй я не скажу, но могу сказать что в 99% администраторы и модераторы не правят одни и те же записи, они их либо удаляют, либо переносят, а избежать тот 1% когда правятся одни и те же данные можно избежать разделением труда (модераторы правят данные причём каждый в своём разделе, а админы занимаются технической стороной)

Ещё есть вариант после правки данных перед записью их в БД смотреть не изменились ли они, и если да то выдавать предупреждение: "данные изменились и теперь выглядят <вот так>, а вы хотите записать <вот так> вы уверены ?"

Админы и модеры.
Возможно.
А как насчет модеров и пользователей?
В том же форуме например.

Немного поразмыслив пришел еще к одному выводу. Предложенное решение лишь отсрочит проблему, а не решит ее.
Если хранить в сессии например оригинальные данные и каждый раз проводить проверку как предлагаете вы, не изменились ли данные с момента их последнего вызова. Здесь будет 2 неудобства:
1)Падение производительности.
2)Не факт что данные влезут в объем памяти, предоставляемой хостером.
Кстати, у меня возник вопрос по этому поводу. Данные, которые хранятся в массиве $_SESSION расходуют память, выделенную под PHP, или же только дисковое пространство(где хранятся сессии)?