@Aleksanbr_77 жутко... Очень жутко. html смешанный c php, реально жутко. Почитай про паттерн MVC. и я уже говорил перепиши. Просто будет читаться удобней. PHP: echo"<form enctype='multipart/form-data' action='upload2.php' method=post>"; на вот такой вид. PHP: echo '<form enctype="multipart/form-data" action="upload2.php" method="post">'; И если это всё для загрузки фото на сервер и потом их показа... То это как то через чур много не нужного кода. Ты с БД работал? Ты написал целую кучу левого кода, а твоя задача при загрузке ложить имя файла в бд, и его так скажем конец ссылки, а при показе кнопок выводить имя файла и его ссылку. Твоя задача не делается таким способом. Даже для учёбы ты сделал бредовое решение этой задачи, а если ты это хочешь засунуть в реальный проект, то это бред. Так что как ни посмотри везде бред. Но это моё мнение, делай как хочешь. Я посмотрел и понял, что ты хочешь сделать. Хочу сказать одно важное замечание: Хоть ты всё и прокомментировал, код читается очень тяжело. Вот моя подсказка по дальнейшему твоему развитию: Гугли: php работа с базами данных для новичков. php MVC для новичков.
И ещё не заметил у тебя в коде вывод ошибок на php Почитай про него. Ссылка ниже http://secure.php.net/manual/ru/function.error-reporting.php
@romach Да ладно тебе, чувак просто только начал и ещё не понимает, что к чему и учится не бось как и я тупо собирая инфу по крупицам. Мне кажется самое главное его прямо сейчас поправить, пока он только начинает, сказать ему: где, что, куда и когда
Глянул твой код. Во-первых, он порезан, а зря. Из-за отсутствующих фрагментов сложнее его читать. Во-вторых там жесть с именами всего и вся. Транслит+инглиш с ошибками+несоблюдение ни camelCase ни snake_case это плохо. Отсутствие проверок на существование файлов, и "тут перебор имен файлов, главное, чтобы не попался файл с именем 0" - это тоже не очень здорово. Далее. Автор, я правильно понял, что ты просто забираешь все файлы подряд и показываешь их в том порядке, в каком забрал, а гарантией ух упорядоченности является вера в то, что файловая система отдаст их именно в том порядке, в каком бы тебе хотелось? Если да, то зря. Ты сам заложил в логике приложения непредсказуемое поведение оного, доверив часть этой логики внешнему программному слою, над которым нет контроля.
Двойная апелляция к большинству. Аяяяй Нет, не все работают с базами данных, на БД свет клином не сошелся. А то, что решение автора в корне неверное, я и так указал.
ах ты проказник! Может быть ты даже сможешь объяснить, почему именно "все" так делают? И в каких случаях что эффективнее? Можешь ли ты сам найти случаи, когда файлы эффективнее?
@Fell-x27 точно, на факт что первый файл который попадется в папке будет именно тот который я хочу! Сделаю сортировку массива! я вообще понятия не имею, к своему стыду, что такое camelCase или snake_case, так что если бы было сказано что что я их придерживаюсь, я бы сильно удивился, ниче, прогуглим-исправим! я удалил из папки на серве все фото и загрузил новое, оно загрузилось, но браузер отобразил старое фото, которого в папке уже нет, вот этот момент ??? - тоисть разделен на нескольео файлов? я не сильно разбираюсь в терминах- поэтому уточняю! Мне на оборот казалось что так лучше, разбить все на множество функций, я еще их соединял перед отправкой было больше! и лишнее удалял, ссылки тексты и т.п. правда одна переменная там лишней осталась, не к этому фрагменту, но и так... прошло. Еще есть в коде четкое указание, "после загрузки файла-открыть именно ту фотку, которая загруженна"! и на локалке оно работает, а на удаленке нет! ??? @askanim я понимал, что люди находящиеся тут нивчем не виноваты! поэтому не хотел шокировать лишний раз, но ты сам просил скинуть код! НУ ДЕРЖИ рас так просишь! И тот факт что ты не поленился туда заглянуть, да еще и разобраться, уже достоен уважения! Если бы я мог, пожал бы тебе руку! абреатуру MVC я уже когда то встречал, но не углублялся! исправлюсь! Я могу ошибаться, не эксперт, но в данном случае мое мнение что лучше не использовать БД, но для тренировки работы с БД я сделаю его - "код" и так тоже, убрал как лишнее перед отправкой сюда! и так код ты говоришь громоздкий! а кто то пробовал его тестить, на локалке потом на удаленке? в самом деле ведут себя по разному
Браузерный кэш. Не включай дурочку, бро. То, как внутри устроена БД - вообще тут не при чем. У тебя доступ к БД есть только через адаптер, все. Хоть она на файлах работает, хоть в оперативке хостится, хоть в параллельном измерении флуктуирует, прстигспди. Речь шла об использовании файлов, которые мы сами можем писать-читать-ковырять, в качестве хранилищ данных. А еще кроме файлов существует shared memory. И там тоже можно хранить всякое. Ты с уверенностью эксперта двинул тезис, что "все юзают БД". Я опроверг, сказав, что на БД свет клином не сошелся, и не надо апеллировать к большинству. А Игорь попросил тебя развернуто свой тезис подкрепить. И даже намекнул, что могут быть ситуации, когда использовать файлы предпочтительнее. И чтобы ты попробовал разобраться в вопросе. Показалось, что частей кода не хватает. Либо я просто что-то проглядел, потому что смотрел бегло. Дело не в локалке и удаленке. Нет разницы между локалкой и удаленкой. Есть разница между двумя серверами с разными операционками и файловыми системами. По-хорошему локалка и удаленка должны быть идентичны. Но почти все новички локально работают в винде, удаленно у них динукс, ессно, а потом оказывается, что код может вести себя по-разному. И вот тут как раз уже дело может быть в чем угодно. Для начала - снова попробуй на удаленке запостить фото, а потом открой код страницы в браузере, и найди там тег <img>, в котором эта фотка должна быть. Он будет создан. И погляди, какой там адрес для изображения указан. И попробуй его вбить в адресную строку. И погляди, что в нем не так, куда он ведет, где в нем ошибка. --- Добавлено --- upd: Блин, я упорно пропускал файлик *.inc, а это у тебя, оказывается, php-файл О_о Где ты нахватался этого? Это типа защита от прямого доступа? Чтобы по обращению к файлу, сервер плюнул исходник на страницу? Или у тебя настроено это отдельно? Или ты не задумывался даже? Не надо так делать. php-файл есть php-файл. --- Добавлено --- Погуглил, да, есть такая техника, и это плохая техника. Не надо ее использовать. --- Добавлено --- Ох щи... Всем привет от разрабов сайта php.net с документацией, которые тоже решили не настраивать сервер, им и так неплохо: http://php.net/include/layout.inc
@Fell-x27 Дык это, когда? Только давай без "у меня там пятьдесят страничек, незачем использовать бд" или "лень развернуть редис". Когда предпочтительнее юзать свой велосипед на файлах вместо специально созданного для этого инструмента?
@romach, случаи бывают разные. Есть случаи, когда часто запрашиваемые данные проще хранить, например, в компилируемом php-кэше, который, при использовании того же opCache будет после сборки жить в оперативе. И будет гораздо эффективнее БД. Без оверхеда в код сразу включается готовая работающая структура данных. Все, опять же, зависит от конкретного случая. Например, компонентам проще хранить свои настройки и прочую муть именно в таком виде, а не в БД. Да, надо писать свой инструментарий для обслуживания этого колхоза, но он, в конечном счете буде эффективнее. 30 компонентов не будут делать 30 запросов. Если они все разом подгружаются на страницу, хватит одного кэшфайла, который будет отрабатывать мгновенно. Плюс это избавляет саму систему от привязки к БД. Но это уже каждый строчит как хочет. Я вот раньше все в БД держал. Прошло сколько-то времени, и сейчас многие вещи, окромя сугубо "модельных данных", у меня вынесены из бд в компилируемые кэши, потому что так оказалось быстрее, экономичнее, разумнее в конкретно взятом случае.Не потому, что лень хранить в БД. Был бы вопрос лени наоборот, хранил бы в БД и не стал бы заморачиваться с выносом наружу и написанием обвязки для этого. Если же речь про тупо картиночки, то хранить пути к ним в файлах, а не в БД имеет смысл, к примеру, если сайт - лендинг с догружаемым контентом, и основная его задача - отображаться мгновенно. Контента там не тысячи миллионов объектов, а обработка нужна быстрая при минимуме ресурсозатрат. И без объяснения клиенту, что ему срочно нужно noSQL или memcache. Вон, спроси у Игоря про миллисекундо-дроч, он на этом уже собаку съел и может рассказать больше моего. В любом случае, все упирается в конкретную задачу и конкретные цели. Автору вот, сейчас, вообще пофиг где что хранить. Хватай первое попавшееся. Главное, чтобы это работало. Но категоричность Асканима была опрометчивой. Это больше для него, чем для автора, текст, я бы сказал.
@Fell-x27 я по книге Лауры томпсон учусь, там практически все файлы -функции лежат в папке inc и имеют расш.. *.inc. Не помню для чего это нужно! но взял из этой книги! а подход мой не верен в чем именно? хотел сделать такую "штуку" разработал алгоритм: открыьт папку_считать все файлы *.jpg _поместить в массив ну и т.д. и в принцепе своей цели добился, там мелочи остались, но я их доработаю.. не верен алгоритм или противоречит этому MVC? мне несчем сравнивать, я не знаю как делают все, -сделал так! а как надо? либо что порочесть? @askanim что то к тебе тут явно предвзятое отношение! Деды переживают, новое поколение растет
И как ты такое раскопал? Прямо как хакнул php.net А код там забавный: PHP: return htmlspecialchars(get_magic_quotes_gpc() ? stripslashes($var) : $var, ENT_QUOTES);
Лишний пример того почему не надо давать странные расширения файлам. Было бы .inc.php - схавала бы пхп-машина и выдала пустой лист. А так - нате вам сорсик. Что-то не припомню, чтоб у Лауры расширение было именно дот-инк.
В том, что ты надеешься, что получишь упорядоченный список файлов, хотя никто это никогда тебе не будет гарантировать. Хочешь упорядоченный список? Сам его составляй и храни. Хоть в БД, хоть в файле, дело твое. И выборку файлов с винта уже делай по этому списку. Тогда порядок будет гарантирован. Если ты не управляешь какой-то частью кода, то можешь не удивляться тому, что эта часть кода будет вести себя непредсказуемо. Я бы сказал, с душком местами. PHP: // Use this ugly hack for now to avoid code snippets with bad syntax screwing up the highlighter if(strstr($highlighted, "include/layout.inc</b>")) { $highlighted = '<span class="html">'. nl2br(htmlentities($code, ENT_HTML5), FALSE) ."</span>"; } --- Добавлено --- А вот, к слову о хранении данных в компилируемых кэшах, зацени, @romach, не в БД хранится ботва всякая: http://php.net/include/pregen-news.inc --- Добавлено --- Они вообще не парятся. PHP: function doc_toc_list($lang, $index, $file) { include dirname(__FILE__) . "/../manual/$lang/toc/$file.inc"; doc_toc_title($lang, $index, $file); foreach($TOC as $entry) { echo "\t<dd><a href='/manual/$lang/{$entry[0]}'>{$entry[1]}</a></dd>\n"; } } У них все что можно и нельзя в .inc хранится.
хм... если мне будет нужен лендинг, который отрисуется за миллисекунду, я просто сделаю рендер в index.html и nginx будет отдавать его, не дергая пыхомашину вообще. Если мне нужны хитрые расчеты, я положу их в редис и буду дергать по случаю. Если мне нужен вывод с поиском, сортировкой и фильтрацией, я возьму БД. Если же мне понадобится закэшировать отдельные компоненты, то я просто сделаю кэширующий слой. Список можно продолжать бесконечно, особенно учитывая что все можно совмещать. Суть одна - если у меня есть задача для которой уже есть инструмент, я не буду городить свой велосипед, в надежде что он будет работать быстрее, а мой код буду править только я, т.к. хрен ты найдешь специалиста, который добровольно захочет разбираться в этой системе костылей и подпорок. Не спорю, есть случаи когда действовать нужно нестандартно, но зачем с этого начинать?
А я не говорю, с этого начинать. Я бы на месте автора тоже хранил линки в БД, хотя бы потому, что ему сейчас нет разницы, где хранить, а БД - самое простое и удобное решение. Повторюсь, это все было не тебе адресовано, и даже не автору, а Асканиму. Он любит безапеляционно что-то утверждать, не всегда вдаваясь в детали. Он сказал "Все всегда юзают БД". И был одернут, что нет, не все и не всегда. При этом первая его реакция на ответ Игоря была "а БД это тоже файлы". Значит человек несколько плывет в теме. Не было сказано, как кто что должен делать. Не было указаний никому. Не было даже поднято тезиса "БД VS файлы". Было просто сказано, что "Асканим, не будь так категоричен, не все и не всегда юзают БД, это не единственное решение." То, что конкретно ты можешь сам разобраться в ситуации и решить для себя, что тебе нужно, вообще никто никак не оспаривал. Другое дело, когда один новичок учит другого новичка, хотя сам не совсем понимает, о чем идет речь. Причем первый не осознает до конца последствия своих советов, а второй еще не способен критически их оценивать, потому что не имеет достаточной базы. По этому я и вмешался. Надеюсь, с пользой для обоих.
Допустимо, если: 1) Тебе пофигу на то, что кто-то может пялиться в твой говнокод; 2) В одном из таких файликов не лежат пароли и явки от всего, чего можно. В общем, хрень эти ваши нестандартные расширения. Толку практического ноль, а головняк словить - легче легкого. Но как по мне, сервер, плюющийся исходниками - это жесть. Как минимум, их файловый кэш можно как нефиг делать тянуть себе курлом или фгетом, тут же пихать в eval и вуаля - даже парсить ничего не надо. У тебя всегда актуальная инфа на руках. И ладно бы, это было у них типа показательность, мол, вот как у нас все устроено, нам нечего скрывать. Так нет. Там костыли, говнокод и извиняшки в комментариях к ним.