Владимир

У вас или где-то висит обработчик onclick, который подавляет реакцию на щелчок по ссылке, или где-то пропущен закрывающий (или открывающий) тег, который мешает браузеру правильно пострjить DOM. Посмотрите в отладчике браузера, что появляется в консоли по щелчку.

Элементарно: вместе с формой должен грузиться скрипт инициализации ckeditor'а, либо инициализировать ckeditor после загрузки формы непосредственно в загрузчике.

Если по скорости, то однозначно CURDATE()/NOW()/CURTIME() - в этом случае вы просто передаете строковую константу в запросе (кто скажет, что это не строковая константа - ничего не понимает в программировании), во втором - сначала создается объект со всеми накладными расходами, потом вызывается его метод, который возвращает результат, который помещается в переменную, который потом из нее извлекается и подставляется в запрос, который после кучи лишних телодвижений уходит наконец в СУБД. А php - это все-таки не бинарный код, несмотря на все ухищрения разработчиков. А в первом случае всего этого нет.

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

Если я правильно понимаю вопрос, то вы решили объять необъятное: сделать универсальную маску на все случаи жизни. Сомневаюсь, что это облегчит вам жизнь, тем более, что уже есть много достаточно универсальных и удобных готовых решений, но раз вы спрашиваете, вам это зачем-то нужно)
Я бы порекомендовал использовать первый вариант с 2 атрибутами. Причина - это самый естественный и универсальный вариант. Вы один раз убьете уйму времени на написание и отладку, но потом будет достаточно передать шаблон и расшифровку. Второй вариант предполагает постоянное написание регулярок, что делает идею почти бесполезной. Другие варианты тоже не лучше. Например, использовать фиксированный набор управляющих символов и классов - это по сути все сведет к все тому же написанию регулярки вручную, которое присутствует в js нативно)

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

По поводу "нужно или нет?", "есть ли такое?" и "сколько будет стоить?" вам уже написали. Работа же по реализации начинается с постановки задачи, ее анализа и написания ТЗ.