Модульное программирование на PHP или как написать маленький портал. Модульное программирование на PHP или как написать маленький портал Несравнимый portal php mod

Я попытаюсь тут разъяснить то, как я подхожу к написанию сайтов, где могут применять подключаемые модули. Пример тому известный скрипт PHPNuke. Как бы не ругали его, подход, примененный в нем, к модульному программированию очень удобен. Но из-за корявости общего кода применять такой скрипт на серьезных сайтах, точнее скажем порталах, с большим количеством посетителей, не рекомендуется. Почему? Скрипт работает медленно, очень большая нагрузка на базу данных. Можно еще очень много чего описать, но это уже материал для другой статьи. Если кому интересно, то в интернете полно описаний этого движка. В «неудобоваримости» PHPNuke я убедился сам. Мой основной проект NVIDIA BIOS Collection в начала базировался на PHPNuke, но постоянные проблемы с хостингом заставили меня начать разработку своей система портала с нуля. Из PHPNuke я взять только суть модулей, все остальное же делал сам. И так для начала. Прежде всего, надо продумать систему каталогов, что и где будет лежать. Вот примерный вариант.

/
/mods/ - каталог для хранения модулей
/img/ - картинки
/include/ - каталог вспомогательных файлов
это что нам сейчас пока надо. Применять блоки и скины мы пока не будем. В моем портале также были другие каталоги
/blocks/ - Тоже своего рода модули, но не выводящие сами информацию, а возвращающие заполненную переменную.
/js/ - каталог для Java скриптов
/theme/ - каталог выбора тем или, грубо говоря, набор скинов для сайта.
/files/ - файлы для скачивания
ну и другие каталоги.

В корневом каталоге храниться всего один файл index.php и вся работа идет через него. Теперь надо решить как будет выглядеть сам сайт. Для нашего примера подойдет наипростейший вариант дизайна, верх сайта, низ сайта, а в середине наша информация из модулей. Для этого в каталоге include создадим два файла top.php и bottom.php, что соответственно будет верхней частью дизайна и нижней частью дизайна.

top.php width="100%" id="AutoNumber1">

здесь выводится шапка
Меню сайта - Модуль1 - Модуль2	"; ?> Предвижу комментарии, где скажут, почему я не вывожу HTML код отдельно, а php отдельно. Я приучил себя к написанию 100% PHP кода, с одной стороны не очень и красиво может выглядеть, но мне так удобнее. Если кто-то хочет писать по-другому, то тут я не советчик. Заметьте переменную $PAGE_TITLE в top.php. В моей реализации вся информация о модулях храниться в базе данных, где помимо имени файла модуля храниться также и его название, которое потом и кладется в $PAGE_TITLE, для вывода его в головок браузера. bottom.php

"; ?> Также создадим файл конфигурации config.php и положим его в каталог include. config.php Вот примерная схема работы index.php Теперь создадим два файла mod1.php и mod2.php и положим их в каталог mods. mod1.php "; echo "А здесь можно посмотреть на модуль номер 2"; ?> mod2.php "; echo "А здесь можно посмотреть на модуль номер 1"; ?>

Поясню немного вот эту строку

If (!eregi("index.php", $PHP_SELF)) { die ("Access denied"); } В каждый модуль желательно включать такую проверку во избежании вызова файла модуля вне самого index.php. На примере моего портала до вызова модуля у меня идет подключение в базе данных, считывание некоторых глобальных переменных и без них, ни один модуль сам по себе работать не сможет. Так что лучше всего просто запретить вызов модуля напрямую. Вызов модулей в данном случае производится через строку в виде index.php?mod=имя модуля, но тут можно применить и систему ЧПУ. Тогда URL примет вид index.php/имя модуля/

Вот в принципе очень грубая схема реализации модулей. Можно добавить любой модуль, просто положив его в каталог mods/ и придерживаясь общей концепции работы, построить очень сложный сайт. В чем удобства работы? По сути вы отодвигаете от себя основную заботу по натягиванию кода на дизайн. Это делает один раз в index.php. Сам же модуль должен только работать и приносить пользу. Централизация сбора основной информации из базы или конфигурационного файла, глобальные переменные сайта, информация о пользователе и т.д. С другой стороны есть недостатки (хотя при определенном взгляде они не кажутся недостатками), скажем надо четко следить за тем какие имена переменных используются до модуля, чтобы не перезаписать, случайно, их внутри модуля. Один раз у меня такое случилось. После такого случая, я взял для себя за правило называть системные переменные в таком виде $sys_имя переменной. Другой очевидный недостаток это трудность реализации разных вариантов дизайна для разных модулей. Но! Тут есть выход тоже.

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

К примеру, наши простые модули можно модифицировать в таком варианте.

"; echo "А здесь можно посмотреть на модуль номер 2"; include("inc/bottom.php"); ?>

Как делать в данном и конкретном случае решать Вам. Я же просто попытался направить тех, кто начинает писать на php, а может и тех, кто уже пишет, на определенный вариант или стиль программирования.
//www.x-bios.3dgames.ru - Сайт моего портала, но к сожалению он закрыт
//fallenangels.combats.ru - Сайт игрового клана, также полностью построен на модульной системе.

Я попытаюсь тут разъяснить то, как я подхожу к написанию сайтов, где могут применять подключаемые модули. Пример тому известный скрипт PHPNuke. Как бы не ругали его, подход, примененный в нем, к модульному программированию очень удобен. Но из-за корявости общего кода применять такой скрипт на серьезных сайтах, точнее скажем порталах, с большим количеством посетителей, не рекомендуется. Почему? Скрипт работает медленно, очень большая нагрузка на базу данных. Можно еще очень много чего описать, но это уже материал для другой статьи. Если кому интересно, то в интернете полно описаний этого движка. В PHPNuke я убедился сам. Мой основной проект NVIDIA BIOS Collection в начала базировался на PHPNuke, но постоянные проблемы с хостингом заставили меня начать разработку своей система портала с нуля. Из PHPNuke я взять только суть модулей, все остальное же делал сам. И так для начала. Прежде всего, надо продумать систему каталогов, что и где будет лежать. Вот примерный вариант.

/mods/ - каталог для хранения модулей
/img/ - картинки
/include/ - каталог вспомогательных файлов
Это что нам сейчас пока надо. Применять блоки и скины мы пока не будем. В моем портале также были другие каталоги

/blocks/ - Тоже своего рода модули, но не выводящие сами информацию, а возвращающие заполненную переменную.
/js/ - каталог для Java скриптов
/theme/ - каталог выбора тем или, грубо говоря, набор скинов для сайта.
/files/ - файлы для скачивания
ну и другие каталоги.

В корневом каталоге храниться всего один файл index.php и вся работа идет через него. Теперь надо решить как будет выглядеть сам сайт. Для нашего примера подойдет наипростейший вариант дизайна, верх сайта, низ сайта, а в середине наша информация из модулей. Для этого в каталоге include создадим два файла top.php и bottom.php, что соответственно будет верхней частью дизайна и нижней частью дизайна.

Echo "< html> < head> < meta http-equiv="Content-Type" content="text/html; charset=windows-1251"> < title>$PAGE_TITLE< /title> < /head> < body> < table border="0" cellpadding="0" cellspacing="0" style="border-collapse: collapse" bordercolor="#111111" width="100%" id="AutoNumber1"> < tr> < td width="100%" colspan="2" bgcolor="#DDFFFF"> < p align="center">здесь выводится шапка< /td> < /tr> < tr> < td width="17%" align="left" valign="top" bgcolor="#FFDFFF"> < b>Меню сайта< /b>< p> < b>- < /b>< a href="index.php?mod=mod1">Модуль1< /a> < br> - < a href="index.php?mod=mod2">Модуль2< /a>< /td> < td width="83%" align="left" valign="top">";

Предвижу комментарии, где скажут, почему я не вывожу HTML код отдельно, а php отдельно. Я приучил себя к написанию 100% PHP кода, с одной стороны не очень и красиво может выглядеть, но мне так удобнее. Если кто-то хочет писать по-другому, то тут я не советчик. Заметьте переменную $PAGE_TITLE в top.php. В моей реализации вся информация о модулях храниться в базе данных, где помимо имени файла модуля храниться также и его название, которое потом и кладется в $PAGE_TITLE, для вывода его в головок браузера.

Echo "< /td> < /tr> < tr> < td width="100%" align="left" valign="top" colspan="2" bgcolor="#DDFFFF"> < /td> < /tr> < /table> < /body> < /html>";

Также создадим файл конфигурации config.php и положим его в каталог include.

#Модуль по умолчанию $sys_def_mod="mod1";

Вот примерная схема работы index.php

Include("inc/config.php"); if (!isset($mod) || ($mod=="") || (!file_exists ("mods/$mod.php"))) { $mod=$sys_def_mod; #Проверка на существование переменной $mod, и существования такого модуля # если неверное условие то присваиваем ему значением модуля по умолчанию } $PAGE_TITLE="Модуль $mod"; include("inc/top.php"); include("inc/$mod.php"); include("inc/bottom.php");

Теперь создадим два файла mod1.php и mod2.php и положим их в каталог mods.

If (!eregi("index.php", $PHP_SELF)) { die ("Access denied"); } echo "Это модуль номер 1!< br>"; echo "А < a href="index.php?mod=mod2">здесь< /a> можно посмотреть на модуль номер 2";

If (!eregi("index.php", $PHP_SELF)) { die ("Access denied"); } echo "Это модуль номер 2!< br>"; echo "А < a href="index.php?mod=mod1">здесь< /a> можно посмотреть на модуль номер 1";

Поясню немного вот эту строку

If (!eregi("index.php", $PHP_SELF)) { die ("Access denied"); }

В каждый модуль желательно включать такую проверку во избежании вызова файла модуля вне самого index.php. На примере моего портала до вызова модуля у меня идет подключение в базе данных, считывание некоторых глобальных переменных и без них, ни один модуль сам по себе работать не сможет. Так что лучше всего просто запретить вызов модуля напрямую. Вызов модулей в данном случае производится через строку в виде index.php?mod=имя модуля, но тут можно применить и систему ЧПУ. Тогда URL примет вид index.php/имя модуля/

Вот в принципе очень грубая схема реализации модулей. Можно добавить любой модуль, просто положив его в каталог mods/ и придерживаясь общей концепции работы, построить очень сложный сайт. В чем удобства работы? По сути вы отодвигаете от себя основную заботу по натягиванию кода на дизайн. Это делает один раз в index.php. Сам же модуль должен только работать и приносить пользу. Централизация сбора основной информации из базы или конфигурационного файла, глобальные переменные сайта, информация о пользователе и т.д. С другой стороны есть недостатки (хотя при определенном взгляде они не кажутся недостатками), скажем надо четко следить за тем какие имена переменных используются до модуля, чтобы не перезаписать, случайно, их внутри модуля. Один раз у меня такое случилось. После такого случая, я взял для себя за правило называть системные переменные в таком виде $sys_имя переменной. Другой очевидный недостаток это трудность реализации разных вариантов дизайна для разных модулей. Но! Тут есть выход тоже.

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

К примеру, наши простые модули можно модифицировать в таком варианте.

If (!eregi("index.php", $PHP_SELF)) { die ("Access denied"); } $PAGE_TITLE="Это Я, модуль номер 1!!!"; include("inc/top.php"); echo "Это модуль номер 1!< br>"; echo "А < a href="index.php?mod=mod2">здесь< /a> можно посмотреть на модуль номер 2"; include("inc/bottom.php");

Heya guys! Long time no see right? Well I"ve been busy for the , but let"s get this out of the way.

With Greenlight nearly coming to an end, let"s remind ourselves at how the great things it did for us. The only way people had to play mods was to go to some download page and install it manually on steam (great system btw, had it"s own folder on the steamapps). While that might sound easy for the most part, there where people who just didn"t knew you could actually install mods on steam, not to mention the steam pipe update which just broke everything.

And then came greenlight. Altough it was yes a door for many horrible games, controversies and the monthly steam drama fest, it did actually a lot of good. Many indie developers finally had a chance of putting their game onto what is the marketplace for any PC gamer. And mods benefited from that. People that didn"t even knew that mods existed, didn"t know how to install them or just didn"t knew how to fix a broken mod finally had a chance to play more of their favorite games. The influx of people mods got after this was HUGE, many youtubers making let"s plays of mods and a easy way to finally play them. There was even the case of PS: Mel that won a award at the Games Awards 2015.

A lot of mods benefited from it too. Without requiring the base game installed, people didn"t have to worry about any errors since valve helped make the mod being considered an actual game (for steam), allowing things such as workshop implementation and achievements.

So, with the end of greenlight, what this means for us?

Steam Direct is the all new system, which will let you put any game on steam for $100 and Valve"s approval. The $100 fee is nothing after all the work you and your team could have put on your mod, and the fee can be split up anyway. But it isn"t about the fee, the new system will actually mean a better gateway for new games and mods.

With a ton of great mods coming up however, you guys will have to find a new source for new mods. This collection won"t be updated anymore since mods won"t be getting on greenlight anymore. I do have a few websites you guys can check though

As far as I can remember the longest running Portal 1 & 2 community. Not only they have the most talented people, they also have all the people from the community. Not to mention the HUGE database of maps for both games on the series, the best source to download single maps all around. And have a great time too! They"re great people.

http://www.moddb.com/ - not only for the portal fan, moddb for me was the way to go for any mod of valve games. They don"t have any curation, but you can freely explore all the mods in a large list, and with a few filters you already have a huge download list to make use of. Moddb also has a few mods that people didn"t even hear about, which I loved to discover and play them by myself. Did you know portal has a chinese mod that let"s you use a phone? It"s great btw.

Well guys I guess that it. I"ll be seeing ya all around, but don"t think this means anything to the portal community. In fact, this won"t change pretty much anything! People will keep making mods and you guys will keep enjoying them. Just through a better method! See ya around,

EDIT: In case you wanna talk with the people of the thinking with portals forum, also check their discord.

Manual Install Instructions for SMF 1.0 RC1 1.0 RC2 1.0 1.0.1 1.0.2 1.0.3 1.0.4 1.0.5 1.0.6 1.0.7 1.0.8 1.0.9 1.0.10 1.0.11 1.0.12 1.0.13 1.0.14 1.0.15 1.0.16 1.0.17 1.0.18 1.0.19 1.0.20 1.0.21 1.0.22 1.0.23 1.1 Beta 3 Public 1.1 RC1 1.1 RC2 1.1 RC3 1.1 1.1.1 1.1.2 1.1.3 1.1.4 1.1.5 1.1.6 1.1.7 1.1.8 1.1.9 1.1.10 1.1.11 1.1.12 1.1.13 1.1.14 1.1.15 1.1.16 1.1.17 1.1.18 1.1.19 1.1.20 1.1.21 2.0 Beta 3 Public 2.0 Beta 3.1 Public 2.0 Beta 4 2.0 RC1 2.0 RC1-1 2.0 RC1.2 2.0 RC2 2.0 RC3 2.0 RC4 2.0 RC4 Security Patch 2.0 RC5 2.0 2.0.1 2.0.2 2.0.3 2.0.4 2.0.5 2.0.6 2.0.7 2.0.8 2.0.9 2.0.10 2.0.11 2.0.12 2.0.13 2.0.14 2.0.15 2.1 Beta 1 2.1 Beta 2 2.1 Beta 3 2.1 RC1 2.1 RC2

Description:

PortaMx v1.54 with a full featured Category / Article management
and Search Engine Friendly url"s (SEF) option and ECL option for SMF 2

PortaMx have many features like a Category and Articles Management and a option for Search Engine Friendly url"s. We use the SMF Integrations hooks extensive, so we need over 50% less changes on the SMF files. All basic files like the function for the Integration, caching and the SEF module (if enabled) are loaded automatically on SMF startup. All the additional Menus and functions also created with SMF hooks.

Because we continue the PortaMx philosophy to make the portal better and faster, we use extensive caching for all the new features. So it"s recommended, to enable the caching in SMF. Of course works all without caching, but not so fast.

The new Category / Article system is high configurable in all options like access inherit and visualization. Follow setup options we have:

• The first Article is shown and all other Articles in the Category are linked in a sidebar.
• All Articles shown in one page with paginating.
• Inherit the access right from a Category to the Articles in it, so it"s easy to handle the rights (simple give the articles no rights). This suppressed also, that the Article itself can be requested.
• Categories and Articles can be used as static elements on the Front page (Category / Article blocks).
• Both can requested in the same way as a Single page request (cat=category-name, art=article-name).

We have expanded the overview screen (Blocks, Articles and Categories Manager) with new settings elements, they works in a Pop up window. With this it"s easy and fast to change the most important settings, like title, position, access and more. You can update a single Block or all Blocks in the Panel.
Also we expand and redesign the dynamic visibility option, specially the customer actions. These have now logical AND and OR functionality, can handle any request type and also sub actions like action=pm;sa=send. For this we will create a separate documentation.

Many users asked us, to add Search Engine Friendly url"s to the Portal and so we do that in this release. The SEF module that we created is based on SimpleSEF, but completely rewritten. We create easy and "speeking" url"s (without comma) in the format, which is proposed by Google.
Of course we have implemented all the Url"s they used for the Portal like Single pages, Categories and Articles. The SEF module have various settings, but normaly you can use the default settings without any change. Furthermore we also can convert url"s, they created by SimpleSEF, like board_## and topic_##.

Finally we give the Portal his own Right Management.
With this you can give any SMF group the rights to create, edit and delete own Articles, a group to moderate Articles and a group to moderate the Blocks in enabled Panels. At least you can give a SMF group Portal Administrator rights. This group have full access to ALL Portal functions (except update), but NO access to any SMF Administrator functions. All these function are linked in the users Profile menu.

PortaMx Administration Center

PortaMx Language Manager

BIB technology sample - free positioned blocks

BIB technology sample - YUI blocks with caching