Форум PHP

Здравствуйте, не судите пожалуйста строго, сразу говорю новичек и прошу за это прощения. я создаю сайт, страницу хочу сделать динамические, пожалуйста, объясните мне юзеру. Вот у меня есть к примеру 10 страниц, в каждой у меня есть название страницы, описание, ключевые слова, и текст страницы, всё храница в базе данных. Как мне правильно организовать работу с базой данных, что бы правильно отображалась вся эта информация на каждой странице, причем страницы динамические. т.е. адрес этой страницы у меня тоже забит в базе данных, и вот мне надо к примеру что бы по этой ссылке к примеру index.php отображалась информация о главной странице, тайтл мета теги и текст, а к примеру index.php?page=1 отображались услуги компании и так же вся информация с базы даных на этой странице Может я и не правильно выражаюсь, но думаю все меня поняли, заранее спасибо огромное.

[поправлено модератором]

никто не заказывал, я просто учусь, а если это насмешка с вашей стороны, то вы тоже не сразу всего научились и вам объясняли

Да нет, я не смеюсь, просто подумал, что для кого-то конкретно делается. )
Вам там ниже написали, правда не понятно для чего, ибо совсем не обязательно это и необходимо. Как и нет надобности держать в базе адрес станицы, к которой будут обращаться. В базе находится их содержание, каждое под уникальной записью, которую и указывают как значение параметра запроса, а адрес, это непосредственно ссылка на скрипт обработчик.
Говоря отвлеченно - у вас есть тетрадь, в нее вы вносите записи. Захотели прочесть что на странице 3, открываете эту страницу, захотели узнать что на странице 1, откроете ее, но тетрадь одна и та же, и рука при этом всегда ваша.

Просто я натыкался на сообщения, точнее на темы, где написанно что надо писать обязательно адреса страниц, поэтому и создал в базе даных адрес) просто я не понимаю алгоритм, как мне осуществит создание динамических страниц и как правильно это сделать. Поэтому и спрашваю)

А что значит адрес?

Вернемся к тетради, пусть она хранит записи о событиях за неделю - первая страница о понедельнике, вторая о вторнике и т.д. И называется эта тетрадь "события". Значит, чтобы узнать, что же произошло в среду, вы должны обратиться к странице 3 тетради события, и если это описать как команду к действию, то выглядело бы это так:
события-->страница-->3
Похоже на адрес? Вот так и формируются адреса, в случае с вызовом ваших страниц, вы должны прописывать ссылку:
index.php?page=3
А если, адрес:
index.php?page=2
Значит запрос ко второй странице.
Но не обязательно запрос может идти к индексной странице, например, вывод их в браузер осуществляет скрипт с именем pages.php, и тогда адрес мог бы выглядеть так:
pages.php?id=1
Зачем при этом в базе держать сами эти адреса? Вы их формируете также динамически как и все содержимое страницы. В базе могут конечно храниться и некие адреса, внешние, а вот внутренние (локальные по отношению к сайту), так это как ссылки на скрипты обработчики, из которых как из модулей может собираться страница. Конечно могут быть ссылки и на ресурсы сайта, например, кто-то оставил комментарий со ссылкой.

В общем - вы знаете что у вас есть записи в базе. Выводите например, меню. Получаете все id этих записей из базы, и прописываете их к одному и тому же адресу, который вы знаете, то есть изменяется только значение переменной page (в вашем случае). А держать их готовые в базе нет никакой необходимости.

хм, вообще-то в базе данных могут храниться и внутренние адреса, если можно так выразиться. тот же SEO-урл записи вполне себе может называться адресом.
например таблица page

|id|seourl|content
|1|index|...
|2|contacts|...
|3|about|...

и ссылки
site.com/index
site.com/contacts
site.com/about
etc.

:)
Вытер модератор, за что не понятно.
Может так тогда - вы внимательно прочтите, о каких адресах не понимает он, и не пишите об этом до тех пор, пока он не поймет этого. Я же это все знаю, мне этого познавать уже не надо.

я лишь попытался более внятно объяснить человеку, не пытаясь его запутать, без примеров про тетради :)
могли бы просто сказать, что адрес это строковый ключ (именно об этом он мог прочитать и ни о чем другом) и не ходить вокруг да около.

И что ключ? Да и не в этом соль, так как ключ=значение совсем еще не обязательно "лезем по нему в базу" за некой страницей. Проблема не в адресе как таковом, проблема в представлении.

>И что ключ?
seourl. это понятно что не обязательно. хотя если количество страниц может меняться, то скорее всего обязательно

Ему надо сперва понять, что такое есть "динамизм". А "seourl", это просто бред какой-то без этого основного понятия. Если не понимать, что из "Лего" можно лепить что угодно, то чего бы там не писали в инструкции к нему, все напрасно. Вот так и ваш seourl.

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

основы PHP, основы Mysql. направление - любую книгу по веб-разработке для новичков, только посвежее. всё

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

Как верстается номер газеты? Есть корреспонденты, верстальщики, редакторы... При этом макет страницы в процессе подготовки номера может меняться. Но как только номер отпечатан, все его не изменить.

Верстка страниц сайта, это почти тоже по сути, что и верстка номера газеты, только с одной очень важной разницей - если каждый номер газеты верстается один раз для всего тиража, то страница сайта верстается каждый раз для каждого посетителя в отдельности, даже если для каждого из них она выглядит одинаково. Это плата за динамизм, хотя существуют методы кеширования позволяющие "не верстать" постоянно то, что не изменяется во времени.

Есть еще одно отличие между страницей газеты и страницей сайта, это их макет. Макет страницы газеты одного тиража может сильно отличаться от макета страницы другого тиража, и это может определяться важностью какого-то материала на тот момент времени. А вот макет страниц сайта практически остается неизменным, изменяется только содержимое в областях ее. Вот в этих областях страниц сайта и происходит "динамизм". Хотя и макет иногда может изменяться, например, для некоторого раздела сайта макет страницы может быть другим.

Если к примеру представить вашу страницу так: заголовок (шапка страницы), слева колонка содержащая меню, блок новостей, и правая колонка в которой выводится основная информация, то это и будет макетом ваших страниц. Здесь верстальщиком выступает HTML, причем верстальщик этот работает по жесткому правилу - принять и разместить данные в постоянно определенные области. Дизайнером страницы будет выступать CSS.

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

То есть механизм динамического создания страниц сложнее, чем представление о том, что index.php?page=1, это взять что-то и показать. За этим простым адресом скрывается очень большая работа, которую двумя словами вам никто не опишет. Но если понимать, что не РНР породило страницы сайта, а мысль человека о том, что бумажную газету можно представить в электронном виде, и такая газета может содержать в себе не только текст и статические картинки, но и иное содержимое, которое не доступно для бумажного издания, и что самое главное, электронная газета может взаимодействовать с пользователем, быть интерактивной.

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

Если говорить применительно к макету страницы оговоренному выше, то упрощенно это можно представить так - index.php:

<div class=header><?php include "header.php"?></div> <div class=left><?php include "left.php"?></div> <div class=content><?php include "content.php"?></div>

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

Основным содержимым здесь управляет скрипт content.php. Именно ему предназначено разобраться с тем, что означает запрос index.php?page=1. Не сам URL, а именно параметры запроса, то что находится после вопроса - page=1. Такой запрос, это запрос переданный методом GET, параметры которого являются массивом $_GET - page, это ключ, а 1, это значение ключа. В РНР можно по разному получить как имя ключа этого массива, так и его значение, а как именно, это зависит от того, какую роль вы определили для ключа.

Представим, что вы можете получать три следующих запроса:
index.php?page
index.php?page=1
index.php?search=слово

Предположим, вы определились с тем, что имя ключа определяет тип содержимого, которое запрашивают (фактически определяют имя сценария). Значение же ключа всегда означает что-то конкретное. Тогда сценарий файла index.php должен определять этот ключ, например под именем $page и передавать его сценариям header.php и content.php. Сценарий header.php будет знать какой заголовок (для элемента title страницы) выводить, а сценарий content.php, какое содержимое запрашивается. При этом сценарию content.php также важно знать и значение этого ключа, которое ему передается тоже, например под именем $number.

header.php может при получении этого ключа выполнять простую работу (хотя в реальности конечно это более серьезное занятие) - получить из базы описание этого ключа (запрашиваемой страницы) и поместить его в html тег TITLE. То есть, каждый из сценариев кроме php-кода содержит описание html-кода страницы (так же как и сам index.php, общий макет страницы, что показано выше). Либо это могут быть подключаемые html-шаблоны.

content.php получая ключ, подключает сценарий определяемый этим ключом, то есть для примера выше, это будут файлы или page.php, или search.php. Каждый из этих файлов занимается получением и выводом определенной информации: первый выводит запрашиваемую информацию, а второй осуществляет поиск определенной информации во всем ее содержимом.

Если запрос был index.php?page, то значение ключа page равно null ($number = null), и можно определить в сценарии page.php, что в случае пустого значения получить и вывести список всех тем, которые имеются на сайте. При этом нужно учитывать количество тем, и если их много, то выводить их порциями - постраничной навигацией. А это, если такой навигатор используется и для страниц других запрашиваемых данных, тот же результат поиска (при запросе index.php?search=слово), то удобно сценарий этого навигатора держать в отдельном файле - файле функций, подключая его. При формировании такого навигатора, каждому его элементу прописывается url с запросом определяющем "номер порции" из этого списка тем, которые будут запрашиваться. Если значение ключа page присутствует (не равно null), был запрос index.php?page=1 ($number = 1), то сценарий page.php получит из базы содержимое страницы с ID равной 1 и выведет его на странице в правой колонке.

Но если используется еще и навигация, и как было сказано выше, она передает значение "порции" тем, то как тогда различить, что же такое есть 1 - номер страницы или порция тем? Все просто - навигатор в запросах имеет свой ключ и его значение. Например, если имя ключа определяющего "порцию" тем определено как "p", то запросы при наличии навигатора на странице, и запросе "порции 3" будут выглядеть уже так:
index.php?page&p=3
index.php?page=1&p=3

То есть, сценарий page.php должен определить - если значение $number равно null, то это запрос тем, и если тем больше, чем определено для вывода на одной странице и не определен ключ "р", то вывести первую порцию тем, а если определен то третью их порцию. В случае, если запрашивается конкретная тема (страница темы), то выводится эта тема, и если, например, число комментариев к ней также велико и требуется постраничная навигация, то действует так же как и выше, но уже выводит порции комментариев - не определен ключ "р", значит первую порцию, определен, значит ту порцию, которую указывает значение ключа "р".

Сценарий search.php будут осуществлять поиск в базе всех тем в которых присутствует запрашиваемое значение, в примере это "слово". И уже от результатов поиска осуществлять соответствующий вывод информации.

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

Скажите пожалуйста, вот так надо мне сделать? мне кажется этот скрипт мне не очень подходит да? чуть чут его надо переделать?

<?php  if( is_numeric( $_GET['page'] ) )      {      $result=mysql_query('SELECT * FROM `page` WHERE id_page=' . $_GET['page'] );      $row=mysql_fetch_array($result); {  include ('design/page.tpl');   } }  else {  include ('design/index.tpl');   } ?>

При значении ноль is_numeric() тоже вернет истину, хотя записей в таблице под таким номером у вас вряд ли найдется (если конечно вы не накосячите сами чего либо). А значит это не подойдет. Лучше так:

<? if($p = (int)$_GET['page']) {    $result=mysql_query('SELECT * FROM `page` WHERE id_page=' . $p);    $row=mysql_fetch_assoc($result); //mysql_fetch_array так как у вас не используйте     include ('design/page.tpl'); //почему у вас подключение шаблона вне условия? } else include ('design/index.tpl');

Уж как-то выработайте совой стиль отступов в строках кода, иначе такой бедлам как у вас ни в какие ворота.

К тому же. Я ведь вам писал, что можно либо определить ключу роль "ссылки" на скрипт/шаблон, а можно использовать вообще один ключ, а по его значению знать что запрашивается, ну например, какой раздел сайта.
А что у вас получается - вы так и будете для каждого из ключей прописывать такие условия, и подключая необходимый шаблон? А если много разделов, а если раздел имеет массу подразделов, тогда как? Да и в таком виде как сейчас у вас такой подход просто не будет работать.

это не моё, это я нашел пример, я сам ещё до конца не разобрался как и что лучше сделать( похоже мне не осилить, пока даже не знаю за что браться и что читать и изучать...(

Тренируйте свое воображение.
Все начинается не с того, как выдрать некую страницу из всего вашего содержания, а определения этого содержания. Если определено у вас, что есть разделы А, Б, С, и эти разделы описаны в таблице базы, и получили идентификаторы (обычно это первичный ключ с автоинкрементом) 1, 2 и 3, то условившись, что в GET запросе на эти разделы будет ссылаться ключ с именем "sec", легко узнать по запросу какой раздел запрашивает пользователь. Если разделы имею подразделы, значит достаточно назначить ключ, который будет идентификатором запроса к подразделам, например ключ "sub". А к страницам этих подразделов ключ "p".
Надо ли еще объяснять, что запрос:
index.php?sec=2&sub=1&p=12
запрашивает раздел страницу которая в таблице содержится в записи под номером 12, которая в свою очередь принадлежит подразделу с номером 1, который принадлежит разделу 2?
А вот какой запрос будет у вас при этом, так это как раз определяется структурой вашей базы, структурой ваших данных. Именно эта структура и будет определять параметры запрос в url, а не наоборот - придумали ключи, а на них навесили свои данные.
А так как меню, которое описывает содержимое ваших данных, строится тоже на этой структуре, то любой вновь добавленный раздел/подраздел в базу, будет автоматически отображаться в меню под постоянно определенным и известным вам ключом но под своим номером - номером записи в таблице базы.

Это не правило, и не значит что делать нужно именно так, но это принцип, на котором основывается связь между данными в базе и параметрами запроса.

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

а если к примеру вот у меня есть страница называется index.php и в базе данных есть на неё информация тайтлы ключевики и текст, как тогда реализовать, что открывается страница index.php и сайт сам автоматом достаёт эти данные, а если открываю страницу к примеру index2.php то что бы достал для этой страницы и так далее

По поводу index.php, index2.php, и не дай бог index3.php и далее.

Исторически так сложилось, что файл с именем "index" в настройках сервера является файлом по умолчанию, которому будет передан запрос. Расширение не обязательно ".php", как и не обязательно имя "index" по умолчанию. Вы можете настроить свой виртуальный сервер так, что по умолчанию это будет файл main.has - "main", потому что вам так больше нравится, а расширение ".has" вместо ".php", это для сокрытия истинного языка используемого вами, при этом в настройках сервера это расширение нужно добавить в исполняемые.

Но в итоге как бы вы не изголялись и чего бы вам не нравилось, в любом случае у вас есть файл по умолчанию, и достаточно пользователю набрать в адресной строке только имя вашего домена http://your-domain.ru/ и сервер отдаст браузеру именно страницу по умолчанию, и пусть это будет вами любимая - http://your-domain.ru/main.has. Именно эта страница зачастую и является домашней (главной) страницей сайта. Поэтому плодить клонов индексной страницы сайта (index.php, index2.php), это неумное решение. Несколько индексных файлов (именно индексных, а не index.php, index2.php...) могут быть, если у вас организованы субдомены.

И вообще - обращение к каждой странице сайта как к собственному файлу, это уже не динамизм, это статика. Зачем вам тогда база, зачем заморочки с РНР, сразу создавайте готовые html-файлы, и делайте обращение к ним.

Можно обращаться и по файлам в динамическом сайте, но только как файлам-скриптам определяющим, например, основные разделы сайта. При этом лучше называть такие скрипты уж чем-то понятным, соответствующем разделу, которым они призваны управлять. В этом случае каждый такой скрипт будет являться как бы "домашней страницей" для раздела, и должен либо "продолжать" дизайн сайта, либо иметь индивидуальный, но обеспечивать доступ ко всем другим разделам точно также, как и главная страница сайта.

Папирусы и берестяные грамоты

В древности не было понятия страниц, и пользовались папирусами - раскатываете рулон и читаете. Наскальные рисунки, знаки выбитые на плитах, это информация от наших предков, и хотя она не разбита на страницы, ее можно читать.

Но такое представление объемной информации конечно же неудобно. Так и появились книги, а с ними и понятие страница. Но понятие страница как физическая величина понятие чисто условное. Сказку о Колобке можно напечатать на разном количестве страниц. Есть газеты которые в общем то представляют собой лист сложенный в несколько раз - хотите разворачивайте, переворачивайте и читайте, хотите разрывайте.

Если говорить о книге, то она имеет оглавление, в котором можно узнать, что апогей драмы в аккурат произойдет на странице 126, вернее ее начало, так как эти страсти занимают целых двадцать страниц, а на странице 166 начнется развязка.

Заметьте, что страницы книги, это номера - это удобно? Несомненно, так как ориентироваться легко - из оглавления мы знаем "о чем речь", а по номерам легко находим эту "речь". А если бы страницы не нумеровались а прописывались по содержанию:

"Душевные переживания Анны Карениной"
"Анна решается броситься под поезд"
"Трагедия отменяется - поезд опаздывает на 12 часов".

Надо объяснять, что в этом случае найти нужную страницы будет гораздо сложнее, потребуется большее время, чем в случае нумерации?

Условности и конкретика

Предположим что у вас 500 страниц. Если ваш сайт статический, ничего удивительного бы не было в именовании этих файлов (заметьте - не названий страниц, а именно файлов) от name_file.htm, до name_file499.htm. А вот название, а правильнее сказать заголовок определяющий суть страницы, это то, что помещается в ее тег TITLE.

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

Читаем еще раз об уже не раз сказанном и очень внимательно ---> Вам надо как-то ознакомить пользователей о содержимом ваших страниц, то есть показать их анонсы (краткое содержание). Пусть такими анонсами служат заголовки страниц. Всего у вас 500 страниц. Сразу вывести их все - получится папирус в электронном виде, долго прокручивать (аналогично раскручиванию натурального папируса) такую страницу неудобно.

Стоп! Прокручиваем назад - заметили, что речь шла о 500 страницах существующих в вашем хранилище , и откуда ни возьмись зашла речь о странице анонсов? Но ведь такой страницы у вас нет в вашем хранилище, так ведь? Так откуда она взялась то, как появится? А взялась она из вот этого логического рассуждения - "Вам надо как-то ознакомить пользователей о содержимом ваших страниц, то есть показать их анонсы". Логического потому, что гораздо удобнее в краткой информации найти необходимое, и если вы лишите своих пользователей такой возможности, то вряд ли они будут раскрывать 500 страниц, чтобы понять если ли нужное для них на вашем сайте. Значит задерживаться у вас пользователи не будут. А появиться такая страница может только в том случае, если вы опишите такое условие в своем файле-скрипте.

Но так как такой электронный папирус из 500 строк заголовков будет неудобен, то нужно сделать еще один шаг на встречу к пользователю - отдавать такие заголовки порциями, постраничной навигацией, о которой уже тоже говорилось. А число таких заголовков в каждой порции, это величина условная, которую вы можете определить по неким критериям, или разрешить устанавливать ее пользователю. Захочет пользователь иметь в порции по 10 заголовков, и для пользователя будут существовать 500/10=50 страниц, которых в вашем хранилище данных НЕТ! Это виртуальные страницы, созданные по условию, а содержимое их определяется "кусочками" информации из каждых 500 страниц реально существующих в хранилище. А захочет пользователь иметь по 50 заголовков, значит получит 500/50=10 страниц. А захочет прокручивать папирус, значит выведет все 500 заголовков и получит одну страницу.

Эти страницы условные не только как физическая единица некой размерности, но и как содержимое! Они временные, живущие исключительно благодаря воображению пользователя (или вашему). Их вообще может не возникнуть, если пользователь не воспользуется этой возможностью - не сделает запрос на анонсы. И не буду еще раз повторять, что файл скрипта узнает о запросе анонсов по определенному программистом параметру запроса, как и все остальное.

Конкретно только одно - контекст определяющий содержимое страницы, которое определено в хранилище данных. И такой контекст единственная реально существующая на сайте сущность. А получают этот контекст прямым запросом к нему по тем же правилам, как к страницам условным - по определенному программистом параметру запроса.

Механизм

Ранее я говорил, что можно назначить ключу запроса роль выполняющую ссылку на файл обработчик области содержащей основной контекст в макете страницы. Это можно пояснить на примере массива, который будет имитировать хранилище данных сайта с тремя разделами, и тремя ссылками с запросами этих разделов. Поместите этот код в файле под именем index.php и запустите его.

<? $content = array(    'home'  => array('title'=>'Домашняя страница'),    'book'  => array('title'=>'Все книги'),    'prose' => array('title'=>'Вся проза') ); $page = $_GET && ($cont = array_values(array_intersect(array_keys($content), array_keys($_GET)))) ? $cont[0] : 'home'; $title = $content[$page]['title']; echo 'Выбрана страница '.$page.', с заголовком '.$title.'<br /><br />Для обработки страницы будет подключен файл '.$page.'.php<br /><br />'; ?> <a href="index.php">Домашняя</a> | <a href="index.php?book">Книги</a> | <a href="index.php?prose">Проза</a>

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

Вот вам и весь динамизм, и при этом запрос поступает всегда к одному и тому же файлу - index.php, все остальные файлы скрипты скрыты для пользователя, не присутствуют в url, а тем более не служат именами страниц!

База данных это тот же массив, только механизм работы с ним иной, и то что написано в примере непосредственно для базы данных не приемлемо. Но из примера вы должны уяснить важные вещи:
1. Структура данных определяет параметры запроса. Удачно продуманная структура данных залог не только оптимизации запроса этих данных, но и механизма "сборки" этих данных на странице.
2. Параметры запроса, это условия по которым работает сценарий, которые в конечном итоге и определяют окончательное содержимое страниц.
3. Обработка параметров запроса, это не просто цель получения данных, но и что не менее важно, это еще и проверка параметров на их истинность и безопасность.

Третье означает, что если запрашиваемый параметр не описан в хранилище данных (нет данных соответствующих этому параметру), то в качестве ответа будет выданы либо данные по умолчанию, либо страница ошибки - 404.

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

И выбор запрашиваемой страницы, и безопасность, и работа над ошибками в примере заключается в одной строке:

<? $page = $_GET && ($cont = array_values(array_intersect(array_keys($content), array_keys($_GET)))) ? $cont[0] : 'home';

И работает это просто - проверяем, если массив $_GET не пуст (есть параметры запроса), и если пересечение массива первичных ключей массива $content и ключей массива $_GET возвратят результат, а это возможно только в том случае, если ключ запроса есть в массиве $content (а значит ни какие "левые" ключи и ссылки на внешние файлы не прокатят), то возвращенное значение (а это будет имя ключа) с подставленным расширением ".php" определит файл который будет подключен для обработки запрашиваемой страницы.

Так как функция array_keys() будет возвращать ключ под индексом, в котором ключ присутствует в массиве, а работает сценарий, и он работает можно сказать с "анонимными" данными, то есть не оперируя именами ключей, то мы сами определяем для сценария, что получать мы будем ключ по индексу 0. А для этого мы берем не полученный пересечением массив, а его значения, функций array_values(), и присваиваем его переменной $cont. А так как пересечение может возвращать только один результат, то он и будет под индексом 0, что и делается в операторе - $cont[0].

Если в запросе "левый" ключ, или ссылка на вредоносный код, то ключ будет равен "home" - будут обрабатываться и выданы данные домашней страницы.

Хотите двигаться дальше - решайте задачи

Для понимания и возможности двигаться дальше, решите простую задачу.

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

Сделайте простой макет страницы - две колонки, левая и правая.

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

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

При запросе к конкретному содержимому, выводится это содержимое и заголовки в соответствующий тег.

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

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

Большое спасибо!)

Все запросы отправлять на index.php с помощью mod_rewrite, а уже на основе запроса формировать страницу

спасибо) буду теперь искать и читать, разбираться)

Это обязательно?

что это?

mod_rewrite, который как вашему вопросу, в том контексте как он представлен, никакого отношения не имеет.

не панацея ж

Если использовать mod_rewrite, это значит новая тема в разделе Apache. А так вам все в одной теме разжуют.)))
Да и прав Confirm, к динамическому контенту отношения не имеет.

так ведь и так и так mod_rewrite, только назначение разное