Ссылки на страницы в разных папках
Прошу вас помочь мне в решении проблемы.. Может и вопрос простой и я зря раздуваю эту тему, но видно я ламер полный. Итак:
Работаю с РНР.
Допустим, имеем заглавную страницу сайта index.php с кодом:
<?php
include ('Shablon/head.php');
include ('Shablon/test1.php');
?>
Как вы поняли, результатом index.php будет результат файлов, находящихся в каталоге Shablon...
Теперь представим, что файл head.php (шапка сайта) содержит рисунок по пути:
src="Images/space.gif". Это означает, что в каталоге Shablon имеется папка Images.
Вот мы и подошли к проблеме: На заглавной странице рисунок не отобразится, т.к. в моем примере index.php будет искать в корневом каталоге папку Images, а она находится в каталоге Shablon...
Задача сразу же усложняется следующим. К примеру, есть у меня файл по пути Music/music.php. И у него почти такой же код, как приведен выше:
<?php
include ('../Shablon/head.php');
include ('../Shablon/test62626.php');
?>
И файл music.php тоже не находит рисунок, т.к. ищет туже злощастную папку Image у себя в каталоге Music..
Можно, конечно, решить проблему просто. Т.к. я делаю пока локально и в интернет ничего не выкладывал, то могу к рисункам (да и не только) прописать жесткий путь, типа http://localhost/Shablon/Images/aaa.jpg и т.д... Однако, возникнет проблема, когда я сайт буду размещать в интернете и появится доменное имя. И придется мне, бедному, во всех файлах менять жесткий путь к этим рисункам и не только...
Вообщем, не пинайте меня сильно..
Прошу помочь мне, уважаемые специалисты!!!!
Время 2.30 ночи - я пошел спать!!!!
Самый простой выход в любом случае - определять все пути в константах (или переменных, но константы лучше, т.к. они суперглобальны, если можно так выразиться). Так вот, можно (нужно!) пути описать в некоем файле, типа config.php (в нём же и явки-пароли к БД и всякая прочая муть):
define("IMAGES", MAIN_URL."/Shablon/Images/");
не забудь в файле head.php подключить его в самом вверху: require_once("config.php");
Таким образом, у тебя с самого начала работы скрипта есть совершенно чёткий абсолютный URL для твоих картинок - только имя файла подставляй:
Долго я со своими ругался, но всё же приучил делать путь к картинкам от корня, что и тебе советую. Учим HTML.
MFENDER!!! Понятно!!!! Тока вот немного интересно: а для файла test_1.php (что описан выше) значение этих переменных актуальны?! Или в нем, по аналогии c head.php тоже нужно этот файл config.php подцеплять?!
З.Ы.: Не пинайте, меня, плз... Знатоки для того и нужны, чтобы помочь ламерам, а не отправлять к мануалам :)!!!!
Да, ещё совет: чтобы не париться, просто все файлы .php держи в одном месте.
Да, я его подключаю почти во все скрипты... Делаем краткое проснение того, что я понял:
Итак, require_once("config.php"), что ты мне описал необходимо запихнуть в head.php.. И везде, где используется этот head.php, константы будут определяться... И никакой проверки на DEFINED, таже если я вызываю несколько страниц... Или я туплю :( ?! (Я наверно тебе все мозги проклевал?!)
так было у меня изначально, но со временем стало понятно, что структура не удобна малость.. Самый явный пример: index.php лежит в корне... - удобно для индексации в поисковиках через ROBOT.TXT. разрешаю индексировать только его, и никакие другие каталоги.. а вот в этих каталогах и лежат уже так называемые "рабочие" php
Ты думаешь, кто-то смотрит на robots.txt? Если хочешь запретить индексацию каких-то файлов - запрети их в .htaccess.
Яндекс и рамблер по крайней мере на робот клюют...
Кстати, мы так и не закончили обсуждение темы, а именно мой предпоследний пост
А что там ещё обсуждать? include и require подключают файлы и возвращают результат их выполнения. Соответственно, если тебе нужны
настройки из файла config.php, то нужно просто подключить его единожды в начале работы.
Моё личное правило - все пути на сайте - абсолютные начиная со слэша (от корня сайта) или реже абсолютно-абсолютные, т.е. http://...
Все пути внутри PHP в движке - от корня сайта, на константах. как у mfender.
Только в таком файле лучше не производить вывод и вообще какие-либо действия, кроме определения настроечных констант и пары жизненно важных функций.
Не совсем... Достаточно делать @defne, что короче и логичней. Однако, есть вариант, когда ситуация, что нельзя переопределить константу, ошибочная. Я в этом случае поступаю так:
if (!@define('SITE_ROOT', dirname(__FILE__)))
throw new DefineError('Can not define constant SITE_ROOT');
Хотя, по-хорошему, здесь надо сделать свою функцию, чтобы не дублировать эти строки, если потребность "определить константу во что бы то ни стало" возникает больше одного раза. Интересно, что
"@define or die()" работает, а "@defnie or throw" - нет.
Если ты имеешь ввиду класть их в одну директорию, полагаю, ты не прав. В проекте, с которым я сейчас работаю, ровно 2511 PHP-файлов. Представляешь, что было бы, если бы они лежали в одной диретории?
Плохая идея. Создаваемый сайт в будующем может стать лишь маленькой частью более нового сайта. В этом случае его логично будет перенести ниже по дереву, чтобы легко интегрировать с новой концепцией. Было company.com, стало company.com/buy-online/, например. В этом случае логично и картинки старого дизайна перенести на уровень ниже. Более реальный пример: я сейчас делаю сайт библиотеке родного универа. Я понятия не имею, на каком уровне он будет лежать от корня сайта. Это может быть и /structure/library, и /library, и что-то ещё. Его могут перенести на другой уровень уже после создания. Конечно, я не собираюсь мусорить своими картинками и скриптами не в "своей" директории. В общем, смотри define, который я привёл выше :)
Как можно переопределить константу? :eek: И где логика?..
Я в ужосе... Windows XP насчитывает порядка шести с половиной тысяч файлов в system32. Но там это чем-то оправдано. А у тебя тоже по функции в три строки на один php-файл? :eek:
Плохая идея. Создаваемый сайт в будующем может стать лишь маленькой частью более нового сайта. В этом случае его логично будет перенести ниже по дереву, чтобы легко интегрировать с новой концепцией. Было company.com, стало company.com/buy-online/, например.
Абсолютный, 100%-ый бред...
Если он станет как вы выражаетесь "маленькой частью нового сайта" что на самом деле весьма маловероятно, то в таком случае все решается созданием для него домена третьего (четвертого, пятого...) уровня. И тогда "было company.com, стало buy-online.company.com/".
Это как это?
Если он станет как вы выражаетесь "маленькой частью нового сайта" что на самом деле весьма маловероятно, то в таком случае все решается созданием для него домена третьего (четвертого, пятого...) уровня. И тогда "было company.com, стало buy-online.company.com/".
ну тут я с вами не согласен
это не лучшее решение создавать поддомены
это не лучшее решение создавать поддомены
Вопрос не о том как в принципе лучше делать (кстати а чем домены не угодили? например на этом сайте форум вынесен в отдельный домен и ничего страшного не происходит), а вопрос в том как выкрутится в случае если проект растет а пути стоят абсолютные...
Создание поддоменов не всегда приемлемо. Ссылочные факторы ранжирования в ПС в этом случае могут учитываться отдельно для каждого поддомена.
Запрет на группу файлов по маске:
<Files "\.(inc|sql|...другие расширения...)$">
order allow,deny
deny from all
</Files>
Запрет на конкретный файл:
<Files config.inc.php>
order allow,deny
deny from all
</Files>
А что такое "Ссылочные факторы ранжирования в ПС"? И какое это имеет отношение непосредственно к программированию? Кстати, о ссылках (в очередной раз): Google больше не желает иметь дело со сслыками в ссылкопомойках. И если раньше пресловутые "факторы" зависели от трудолюбия SE-оптимизатора, то нонче будет котироваться контент и его оригинальность. Т.е. хоть по домену на каждую статью делай - всё одно.
<Files "\.(inc|sql|...другие расширения...)$">
order allow,deny
deny from all
</Files>
Запрет на конкретный файл:
<Files config.inc.php>
order allow,deny
deny from all
</Files>
Это не запрет на индексацию, это запрет на доступ. Почувствуйте разницу :)
Я, конечно извиняюсь, но каким ещё способом запретить поисковой системе видеть результат работы скрипта (кроме как написать его на JavaScript), как не запретить к нему доступ???
User-Agent: *
Disallow: /file.php
Disallow: /directory/
2. Запретить индексацию и переход по ссылкам мета-тегом robots
<meta name="robots" content="noindex,nofollow">
Подробнее тут
ссылочные факторы ранжирования от Google :)
И какое это имеет отношение непосредственно к программированию?
Опосредованное. Но при создании сайта, и при программировании в том числе, необходимость оптимизации лучше учитывать. Все-таки основной поток посетителей приходят с поисковых систем. А большинство сайтов создается для широкого круга пользователей.
К примеру, содержание страниц храниться в БД, есть поля tilte, description, keywords. При формировании страницы соответствующие элементы заполняются данными из этих полей. В результате имеем уникальный заголовок, описание и список ключевых слов для каждой страницы. В системе управления контентом неплохо бы предоставить возможность определять частоту и приблизительно рассчитывать "вес" ключевых слов и т.д.
Кстати, о ссылках (в очередной раз): Google больше не желает иметь дело со сслыками в ссылкопомойках.
Все крупные поисковые системы не сегодня научились определять линкпомойки. И банят их нещадно. Но Вы как-то забываете, что внешние ссылки, и из каталогов в том числе, могут быть полезны посетителям сайта.
нонче будет котироваться контент и его оригинальность.
Да оригинальный контент всегда ценился. Но сбрасывать со счетов внешние факторы, мне кажется, очень преждевременно.
User-Agent: *
Disallow: /file.php
Disallow: /directory/
2. Запретить индексацию и переход по ссылкам мета-тегом robots
<meta name="robots" content="noindex,nofollow">
Подробнее тут
Большинство поисковых роботов плевать хотели на robots.txt и прочи мета- и noindex-тэги. Например, тот же Google игнорирует noindex...
Знаю. Меня за сутки посещают не меньше 15ти различных поисковых роботов. Но в error.log ошибка на отсутствие robots.txt описывается только от яндекса, гугля, рамблера и yahoo. Остальных он не интересует, они его даже не ищут.
:) Вот мы и пришли к соглашению, что крупнейшие поискоые системы прекрасно понимают директивы в robots.txt.
ух ты
у вас наверно весь траф идет из Зимбабве
там вообще про яндекс не слышали
у вас наверно весь траф идет из Зимбабве
там вообще про яндекс не слышали
Вот и я о том же... А те же Google, Altavista и Yahoo в Зимбабве имеют место использоваться. Так при чём тут Яндекс?
Вот именно, что нельзя. И тем не менее, когда твой модуль пытается определить константу AAA, может быть нужно, чтобы там было именно указанное значение и не иначе. В таком случае, если определение констанды не удалось, бросаем исключение. В моём текущем проекте такая константа - SITE_ROOT.
P.S. Я вообще против констант вне класса, но это уже другая тема.
Количество файлов=количество "активных" шаблонов+количество классов. Просто неимоверно выросший проект, потому и на PHP.
Если он станет как вы выражаетесь "маленькой частью нового сайта" что на самом деле весьма маловероятно, то в таком случае все решается созданием для него домена третьего (четвертого, пятого...) уровня. И тогда "было company.com, стало buy-online.company.com/".
Правильное решение, но я про него забыл, так как в моём конкретном случае оно неприменимо.
По поводу маловероятности тогже согласен, но у меня такое было.
Я так и делаю, но связь с местом для картинок я не понял.