Форум eBanners.Ru: Реклама в интернете и раскрутка сайтов - форум по интернет-рекламе
Средняя механизация PHP-Nuke - Раскрутка сайтов и интернет-реклама - интернет-реклама
У вас есть вопрос по рекламе в интернете и раскрутке сайтов? Задайте его здесь и вам ответят. Вы уже всё знаете? Помогите тем, кто знает пока не всё. Правила форума|
Сделать стартовой|Добавить в избранное.
2006-01-13 newcontinent.ru optimization Alice V. Volkonskaia
На этот раз для опытов был выбран один из распрастранённых и вполне вменяемых и рабочих клонов php-nuke slaed. Очень хотелось посмотреть что там внутри.
В процессе исследования и оптимизации организма системы удалялись встреченные табличные теги, оформительские теги типа FONT, встроенная в тело тяжелая графика... и подобное в целях общего отделения ценности данных от их художественного оформления.
При исследованиях выяснилась целесообразность системной модернизации построения отдельных модулей.
Процесс модернизации непрерывен и продолжается постоянно. Модернизируемый код снабжается обильными комментариями по поводу иссследуемых деталей, так что можно следить за версиями нового портала.
Тестовая демонстрационная версия портала , там можно скачать новые версии или на
Средняя механизация PHP-Nuke
Краткое демагогическое вступление (торопливым можно пропустить): Основной девиз всех действий - упрощение и упрощение. Всяческих человеческих и программных сложностей. Второй принцип кодо-динамики это - "Программы пишутся для людей!" :) В том смысле, что, конечно очень даже хорошо, если код традиционно ориентирован и оптимизован для исполнения машиной, но основное его потребительское свойство - это легкость его прочтения и усвоения читателем, впрочем как и любого другого читаемого текста. И не просто читателем, а читателем, возможно до того не знакомого ни с идеями заложенными в коде, ни даже с самим способом их закладки в конечное блюдо. В каком то смысле любой осмысленный текст - это код, побуждающий окружающий мир к действию. И в этом смысле программный код мало чем отличается от литературного текста. Вообще весьма светлая и перспективная идея - совместить два процесса в одном - чтение скрипта (может быть даже первое ) и одновременное постижение примитивов скриптового программирования. Изучают же основы Basica в школе, ну типа как легко усовояимые и запоминаемые на всю жизнь алгеброические формулы разложения и преобразования условных сущностей этого мира. В этом смысле гигант програмной (в большей степени маркетинговой) Микрософт унифицировал конструкции программных языков. Ну в самом деле, давно пора было привести конструкции к единому общепринятому стандарту. А уж выбранный компилятор скомпилит гениальную програмиссткую мысль в нечто понятное, опять же выбранной, операционной системе.
1. Потрава табличных тегов и польза от Великого наследия.
Собственно оптимизация для этого случая свелась к традиционному вытравливанию, по возможности, разнообразной табличной вёрстки, тормозящей активные мозговые процессы дизайнеров и кодёров. Помимо явной неоправданности повсеместного использования таблиц к месту и не к месту, полное удаление или замена на благородные теги "< DIV >" улучшает сканирование содержания сайта поисковиками. Некоторые, говорят, в последнеее время, так вообще отказываются вчитываться в нагромождение табличных тегов и просто игнорируют огромные массивы ценного интеллектуального содержания нерадивых сайтов. И вот ещё одна дизайнерская новость в подачи содержания - почему бы не предъявлять данные в виде свободных кубиков.
. Вот для примера выведены . Блоки определены со стилем "display: inline" и свободно выводятся в линеечку. На мой, невоспитанный дизайнерскими изысками взгляд, совершенно без разницы в одну-две-три или боле колонок выведутся однотипные кубики новостей. По этому же принципу построены галереи замечательных художников , , , , и др. Великие и Великолепные. Кстати отличные учителя истинного дизайна мысли и вообще. И отличный источник аватар, взамен полутворческому похрюкиванию профессиоанальных рисовальщиков аватар. Конечно, , ,
[img]http://podol.ru/serov/t_1887.jpg[img]Амедео Модельяни
не позволят писать глупости, под такими аватарами будет просто неприлично тупить и писать форумскую чушь и вообще идиотничать. Так что и здесь воспитательная роль настоящего искусства просто необходима, особенно в экстремальных условиях теперяшних интернет форумов.
2. Всеобщая солидарность.
Особенно мучительно угнетение мозга и рук оптимизатора внутри типичного модуля PHP-Nuke. Отыскав нужное место где спрятался заветный цикл вывода содержимого модуля простак оптимизатор быстренько заменит по своему вкусу выводимый код и довольно потрёт наруженные руки. Но скорее скорого на руку оптимизатора постигнет разочарование и никакого эффекта от внесенных измененией оптимизатор скорее всего не увидит - сразу. А покопавшись в дебрях модуля оптимизатор с удивлением обнаружит существования целой кучи фенкций содержащих одни и те же циклы вывода данных. И только методично прошерстив их все можно быть уверенными, что подходящее оформленьице выводимых данных теперь будет при любом вызове модуля.
Что бы избежать мучительно ремонта агрегата модуля, можно прибегнуть к заведению одной основной функции вывода данных, например "view", совмещающей в себе анализ поступающих аргументов (эту идею следует развивить, так она, ко всему прочему, избавит от кучи ненужных параметров в адресах, кстати эта методика давно и упорно пропагандировалась Microsoft в том же учебном Basic(е)) .
На основе анализа поступающих аргументов-данных, внутри такой функции формируется один универсальный единственый запрос на отбор данных из таблицы с учётом заданных параметров. То есть если, например передан аргумент "seach" в виде набора поисковых фраз, то из него будет сформировано условие where, а если он не передан, то и не будет никакого условия для поискового отбора. С этой точки зрения условия отбора по категории (или по категориям) всего лишь одно из условия отбора, каковой можно производить по всем полям таблицы. Вот это уже почти концепция простого выбора и представления данных, через одну функцию вместо отдельных функций на каждую команду, где циклы вывода данных в HTML многократно повторяются. Может это и экономично для машины, но путанно для человека-sapience модернизирующего. Поэтому - "всё через одни ворота", с предварительным разбором передаваемых данных.
Вот это я постаралась сделать в модуле "links", там внутри полно моих соображений и идей по ходу дела, смотрите внутри.
Например забаdный приём вынесения голосования за сущность непосредственно в основной список и запуск команды голосования посредством js, на событие изменения ("onchange"), без дополнительной специальной кнопочки с громождением формы.
Вот еще забавная идея - встраивать короткие url(ы) сразу и непосредственно в код. Этим конечно увеличивается зависимость от наличия файла .htaccess, но это всего лишь ещё один необходимый файл, такой же как илюбой другой файл с вынесенными функциями, например, а нормальный хостер всегда предоставляет возможность использование своего .htaccess. Зато здесь же, неожиданно достигается и некоторая независимость модуля от разнообразия версий нюк типа index у них всегда впереди или module, или ещё какой другой файлик впереди вызывается. Это дело вкуса, конечно.
Модуль вполне рабочий, хотя и находится в стадии дальнейшей принципиальной оптимизации, точнее теперь сказать разработке.
3. Шаблонность решений. Долой ! И классовая независимость.
После долгих и мучительных размышлений неожиданно подрос вывод о неразумности использования внешних функций, обычно размещаемых в файле шаблона для окончательного, бесповоротного вывода данных. Это конечно жутко непринципиально в плане жесткого разделения данных от их вида. Но это всего лишь скрипт, а не фундаментальный продукт со строгой концепцией яйцеголовых теоретиков "данные-вид". И шаблон и модуль - это тот же PHP, так, что дизайнеру все равно придётся изучать скриптовый язык. Так лучше сразу в модуле и определять, тем самым кстати порождая ещё одну очень перспективную концепцию - "естественного сремление всякого модуля к полной независимости и личной свободе"! И даже по возможности к классовой независимости!. То бишь будет у него некий интерфейсик, может даже стандартизироованный, а может и не один. (Еще ни разу не получалось просто так выработать один единственный стандарт хоть в чём-нибудь сразу и для всех.) И вот в этот интерфейсик и надо будет подать всё необходимое от ядра или ещё откуда, а может и просто инициализируя ручками. Ну это всё теория и на будущее. А в будущем этих скриптиков вообще может статься не оказаться :(. А будет один чей-нибудь продукт наподобие Office ну или даже StarOffice :) Так что проще товарищи, проще! Это всего лишь скриптики.
В свете этих соображений внешний вид сформированных данных концептуально формировать только при помощи CSS или для пущих возможностей XML-XSL(если выживет) И тогда смена темы сведется в тривиальной подмене файла с определением стилей CSS никаких заморочек со сложнейшими построениями каталожных структур с файлами темы. Надо отметить что идеи эти вовсе не новы и давненько применяются умными разаботчиками например в punbb впрочем у продвинутых, тоже не мало проблем :). Но CSS это - есть наш последний и решительный ответ европейскому мракобесию PHP-Nuke и её местных клонических приспешников.
4. Концептуальное перерождение PHP-Nuke.
Вся эта мелкая оптимизация неизбежно приводит к идее большего концептуального перерождения системы, возможно напрочь отрицающего предшественников. Эта работа проводится непррерывно и отражается в очередных версиях размещаемых на тестовом портале и на
Одна из перерожденческих идей - это выделение стандартного набора функций для обеспечения нормального безбедного существования стандартного модуля системы, на основе которого можно было легко и быстро, а главное безошибочно создавать необходимое колличество специализированных модулей. В самом деле, есои присмотреться, то невелико различие между функциональностью модуля каталога ссылок и функциональностью новостей или контента. Разница только в литературном обозначении в общем то однотипных полей. В одном случае беспокойный мозг изобретательного проектировщика обзывает поле hometext и еще одно для полного содержания совсем уже поти неприлично "bodytext". В тоже время, точнее несколько раньше, вовсе не последние умы человечества неоднократно разрабатывали (и не раз) всяческие универсальные структуры данных. Свою живучесть демонстрирует стандарт тегов метаданных в HTML. Так чего же в который раз изобретать один и тот же велосипед!? Description! и никаких hometext-ов! И хорошо бы вставить в стандартный набор полей Key! - Очень необходимое поле для любогог модуля лписывающего любую сущность, будь то link или единца контента. Вот сленговые чудеса обозначения простых вещей - статья, новость, страница книги, описание ресурса в каталоге (краткое - description и полное - просто text). Кстати в каталоге - всё равно в каком - ссылок, фильмов, аудио-дисков, анекдотов, ... или даже особых таких специальных крышычек для особых специальных футлярчиков и т.п. ! И для всех пригодится поле author и mail, и date, и note... И никто не сможет поспорить, что всем сущностям пригодится label маленькая такая картиночка ну и побольше image и т.д. В этой 13 версии 2006 года для экперимента модуль "pages" был получен путями простого копирования скриптов модуля "links" и для пробы, основная контенто-выводящая функция сама была выведена в библиотекку "function/function". Хотя впринципе, вывести эту нахалку можно в любой другой файл подключаемый на ранней стадии. И туда же можно отвести всю компанию необходимых для нормальной работы модуля функций: save, add, vote. Обобществив стандартный набор функций для общих нужд всех модулей и сформировав таким образом интерфейс, как у всех более менее порядочных портальных систем.
В стандартные функции-методы придется передавать дополнительный параметр - имя таблицы с которой связан модуль или же использовать жесткую зависимость: например имя модуля = имя таблицы. Что бы избежать опасной передачи имени таблицы - лучше использовать внутренний case, его вариант предложен в новенькой коллективной функции "v()".
Конечно есть модули, в которых необходим чрезвычайно богатый набор специфических полей. Например в моделе службы знакомств каких только половых полей не понапридумывали, чтоб уж точно определить искомого партнёра. Несмотря на всю утопичность подобного подхода к знакомствам - проблема полевого богатства остаётся. И одно из её решений - это передача массива с подробными параметрами полей и затем обработка такого массива в цикле, гаопдобие как это сделано в MSAccess в конструкторе форм, достаточно заглянуть в файл описания формы в basic проекте - цельный метаязык описания формы. В PHP вполне можно обойтись штатными средствами и получить мечту малопрофессионального разработчика приложений - access для MySQL. Эта методика уже некоторе время орабатывается и будет предметом следующей статьи и версии какого-нибудь завалящего клона PHP-Nuke.
------------------------------------------------------------- -------------------
Дополнительные материалы:
Инструкция по установке оптимизованной клонической версии:
1.Распаковать архив и залить (закачать) содержимое папки portal к себе на сайт. Для простоты можно прямо в корневую папку сайта "www" или "public_html", а можно в какую-нибудь папку с красивым названием внутри корневой.
2. Отредактировать файл config/config.php
$dbhost = "localhost"; //
$dbuname = "login"; // Ваш логин к базе данных
$dbpass = "pass"; // пароль к базе даных (обычно логин и пароль высылает вам ваш провайдер)
$dbname = "db name"; // наименование Вашей базы данных
$admin_file = "admin"; //
$adminlogin = "admin"; // первичный вход в систему просто задайте любой ваш логин
$adminpassword = "admin"; // просто задайте любой ваш пароль
$prefix = "org"; // префикс к таблицам базы данных. По умолчанию org.
// Если Вы установите другой то нужно будет отредактировать SQL файл newcontinent.sql
// и заменить там префикс.
// Для редактирования можно использовать простые реакторы типа notepad, editplus.com ...
"Залейте" файл newcontinent.sql на в Вашу базу данных. Обычно это делается через phpMyAdmin которая есть у любого нормального хостера. Там нужно будет открыть Вашу базу и выбрать команду SQL в верхнем меню и указать SQL файл на вашем локальном компьютере с sql-инструкциями. В нашем случае это файл newcontinent.sql.
После выполнения вышепредложенных действия портал должен заработать. Это нехитрый механизм усатновки практически любой нюки. Всяческие инсталяторы практически делают всё это же самое, только в интерактивно-ламерском режиме :) Но настоящий то проффи никогда не сподобиться пользоваться кривыми или же даже прямыми инсталяторами, а выполнит всё в точности как написано да ещё и с глубоким пониманием производимых процессов, и никак иначе. Иначе, извиняюсь но ...
Но, что бы контролировать Nuke в качестве администратора, нужно срочно выполнить важнейшее действие И те кто до сюда не дочитал - те сами виноваты! Нужно мгновенно вызвать файл admin.php! То есть [путь_к_вашему_портала]/admin.php . Ну грубо, вызвать в командной строке файл admin.php, который лежит в корне (основной папке) портала. И при первом вызове Вы сможете завести заветную запись главного администратора! Задать для наиглавнейшего администратора подходящий умный секретный логин и хитрый пароль (и их надо придумать заранее). В дальнейшем их конечно можно переправить и главный админ может завести ещё кучу дополнительных админов для своего сайта. Сами понимаете, что если вы сразу не заведёте такого главного админа, то его с удовольствием заведёт кто-нибудь другой, при случае и этот кто-нибудь другой сможет полностью распоряжать своим сайтом как администратор.