FacedSID

Я сделал так:

1. Есть набор страниц в системе.
2. Есть модуль меню.

Модуль меню позволяет создавать разные меню. Например "Главное меню", "Меню на странице услуги" и пр., т.е. те меню, которые впринципе меняются раз в год )

В каждом меню есть возможность создавать пункты меню. Их два типа: внутренняя ссылка и внешняя ссылка. С таким подходом вы никак не привязаны к структуре сайта, можете создавать хоть по 10 разных менюшек на каждую страницу.

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

А вообще я бы рекомендовал не пользоваться WordPress. Как же я не люблю его, особенно после того как обращается клиент с интернет-магазином на WordPress.

.htaccess

RewriteEngine On
RewriteBase /

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d

RewriteRule .* index.php

index.php

$requestedString = explode('?', getenv('REQUEST_URI'));
$requestedString = $requestedString[0];

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

Если PHP в режиме mod_php, то файл кешируются. После изменения файла ничего не произойдет до тех пор, пока не закончится время жизни кешированного файла. Скажем так TTL для кеша стоит 5 минут, если вы выполнили файл, он закешировался, потом внесли изменения, то эти изменения вступят в силу только через 5 минут (с момента выполнения файла). Можно принудительно чистить хранилище.

На самом деле защита кода - это вечная песня!
Zend Guard и IonCube можно раздекодить. Например переписанным php интерпретатором. Все обфускаторы работают по одному принципу: перед передачей чистого кода в компилятор, любое расширение типа Zend Optimizer или IonCube декодят его, что бы PHP мог провести лексический анализ и сделать все необходимое для того, что бы транслировать его в байт-код. Переписанные интерпритаторы, просто вместо "выдачи результата" сохраняют "чистый" php код в указанный файл. Я такие вещи изучал еще лет 5-6 назад. Но еще в то время ребята из Zend перед обфускацией кода компресили его до неузнаваемости, но можно было потратить пару часов и восстановить исходный код большинства файлов. Скажем так...это очень хорошие и надежные инструменты, но способы украсть были, есть и будут всегда.

Недавно слава богу перевелся на PDO. Жизнь стала легче и прекрасней :)
А вообще для отлова ошибок подобного плана можно использовать обработчик ошибок, который будет выводить весь стек вызова и тогда уже можно будет наверняка отследить откуда пошли неверные данные. Почитайте про www.php.net/manual/ru/function.set-error-handler.php и www.php.net/manual/ru/function.set-exception-handl...

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