gro

Вы вполне можете использовать наследие процедурного php для этих целей, а именно — объявление статической переменной функции.

function Reg() {
  static $registry = null;
  if(null === $registry) {
    $registry = new stdClass;
  }
  return $registry;
}

Не использовал бы, т.к. глобальную переменную $___REGISTER можно случайно или намеренно изменить, а потом искать, где «собака порылась».
Если очень хочется использовать stdClass в качестве контейнера в реестре, то я бы предложил поступить так:

class Registry extends stdClass {
    private static $instance;

    private function __construct () {}
    private function __clone () {}

    public static function me ()
    {
        if (self::$instance === null)
            self::$instance = new self;
        return self::$instance;
    }
}

# Использовать так
Registry::me()->config = new stdClass;
Registry::me()->config->host = 'habrahabr.ru';
Registry::me()->config->admin = 'admin@habrahabr.ru';
Registry::me()->config->name = 'Хабрахабр';

а через htaccess не пробовали закрыть блог?

а для чего вообще session_regenerate_id использовать?

Интеграция с 1с это не более 5-10% от разработки интернет-магазина. Не стоит отказываться от CMS только из-за того, что в ней по умолчанию нет интеграции с 1С.

Я работал и с платными и бесплатными CMSками, для разработки в том числе и интернет магазинов. У платных в техническом плане нет абсолютно никаких преимуществ. Тот же битрикс почти во всем проигрывает друпалу и в скорости и в качестве кода. У друпала качество тоже не очень, но у битрикса совсем плохо. Волосы дыбом встают. Битрикс работает крайне медленно и невероятно сильно грузит базу.

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

Выбирайте Magento. Если цель — именно магазин — лучше не найдете.

Кэширование — это очень сложно. Если у вас вносятся изменения в БД, то появляется масса проблем с инвалидацией. Инвалидацию очень легко забыть где-нибудь вставить, даже если с этим помогает фреймворк/ORM.

Все «полностью автоматизированные» решения по кэшированию, создавали гигантские проблемы, потому что в каких-то случаях не инвалидировали кэш, когда нужно. Допустим, есть объект Profile со свойством balance. Пользователь покупает услуги, генерируется invoice, и либо баланс показывается закэшированный, либо инвойс не появляется в списке закэшированных инвойсов. Оба случая вызывают неистовое негодование пользователей, поверьте моему опыту.

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

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

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

В общем, готовых шаблонов на все случаи жизни нет. Только для read-only данных, и то с ограничениями. Задумываться о кэшировании желательно с самого начала реализации проекта, потом будет сложнее.

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

А есть замеры/цифры которые доказывают что DbSimple будет являться узким местом в нагруженных проектах?

для переменных использую camelCaps… тут пишут, что для функций лучше использовать метод с подчеркиваем, но мне он не нравится… использую camelCase и для функций.

Пользуюсь pyha.ru/go/godb/

mysql, для удобного и защищенного использования можно использовать godb pyha.ru/go/godb/

ни дизайном, ни версткой ни программированием на php/js/ryby

ни дизайном, ни версткой, ни программированием на php/js/ruby

А название, блин, кричащее.
так и нарывается ответ:
— Как стать фрилансером?
— Вы — уволены!

Для простоты понимания примеры можно сократить до следующих.
Первый: function Test() { this.qqq = a; }
Второй: function Test() { return {qqq: 'a'}; }

Теперь обратимся к спецификации ECMA-262, пункт 13.2.2. [[Construct]]

When the [[Construct]] property for a Function object F is called, the following steps are taken:
1. Create a new native ECMAscript object.
2. Set the [[Class]] property of Result(1) to «Object».
3. Get the value of the prototype property of the F.
4. If Result(3) is an object, set the [[Prototype]] property of Result(1) to Result(3).
5. If Result(3) is not an object, set the [[Prototype]] property of Result(1) to the original Object prototype object as described in 15.2.3.1.
6. Invoke the [[Call]] property of F, providing Result(1) as the this value and providing the argument list passed into [[Construct]] as the argument values.
7. If Type(Result(6)) is Object then return Result(6).
8. Return Result(1).

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

В стародавние времена был придуман способ хранить множество файлов по такому принципу:
1) было: /files/abcdefg.gif
2) стало: /files/a/b/c/abcdefg.gif
Глубину вложенности больше 3 на практике ни разу не видел, как и задержек. Вот по первому рецепту — задержки были, но тогда была еще ext2 и несколько тысяч файлов в папке. Точные цифры, к сожалению, не помню за давностью лет.

С массивами-то (Array) в IE (даже 6) вроде такой проблемы нет, а что касается объектов, используемых в качестве ассоциативных массивов, начиная с IE8 это уже исправлено:

var obj = {
	'lorem' : 'first',
	'ipsum' : 'second',
};

Итого, прав программист, но из-за IE6-7 пока приходится делать неудобно — без запятой после последнего элемента.