Модульное программирование на PHP или как написать маленький портал. Модульное программирование на PHP или как написать маленький портал Прибор portal php mod
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.
Я попытаюсь тут разъяснить то, как я подхожу к написанию сайтов, где могут применять подключаемые модули. Пример тому известный скрипт 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");
Не сильно ошибусь, если скажу, что каждый сисадмин настраивал веб-сервер. Это мог быть IIS или Apache - в общем не важно. Развертывание всего этого добра на Windows или Linux довольно шаблонная задача, не вызывающая трудностей. А если даже таковые возникают, то способы решения не трудно найти в интернете.
Сегодня я хочу рассказать об одном частном случае, который случается в корпоративной сети, где все компьютеры и пользователи входят в домен Active Directory. Мы будем делать корпоративный web портал на каком-нибудь простеньком движке типа joomla. На портале будут размещаться различные новости, опросы, формы обратной связи, форумы и пр. Одна из основных фишек такого портала заключается в том, что все пользователи должны автоматически аутентифицироваться при входе на портал, а не регистрироваться/логиниться в ручную. Таким образом, любые действия на портале будут автоматически осуществляться от имени этого доменного пользователя. Эта функция как раз и называется SSO (Single Sing On) Подробнее см в wiki .
SSO будет работать если:
- Движок портала (в нашем случае Joomla) умеет аутентифицировать пользователей по LDAP
- Веб-сервер передает обработчику PHP имя пользователя, который открыл портал
- Пользователь должен аутентифицироваться на уровне веб-сервера, однако, веб-сервер должен где-то проверять валидность пользователя, отсюда вытекает следующий пункт
- Операционная система интегрирована в Active Directory
Ровно на этом месте встает вопрос, на каком web-сервере делать портал? Какую ОС взять за основу: Linux или Windows?
Рассмотрим варианты:
- ОС Windows, веб-сервер IIS. На первый взгляд кажется самым очевидным вариантом. Интеграция с AD на уровне операционки уже есть. php и MySQL поставить труда не составит. Однако, IIS будет нормально работать только на Windows Server, который стоит приличных денег. Если же взять какой-нибудь Windows 7, то IIS в нем имеет серьезное ограничение по количеству одновременных сессий и по факту связка Windows 7 + IIS не годится.
- ОС Linux, веб-сервер Apache. Основные преимущества - бесплатность и скорость работы. Основная трудность - вогнать Linux машину в домен Active Directory и правильно настроить Apache.
- ОС Windows 7, веб-сервер Apache. Относительно не дорого, подойдет тем, кто с Linux «на вы», интеграция с AD уже есть, потребуется небольшая настройка веб-сервера под наши задачи.
К своему удивлению, по п.2 и п.3 я не нашел в интернете полного мануала как сделать всё «от и до». В этом обзоре я остановлюсь на 3м варианте и попробую рассказать как это делается. И так, поехали…
Нам понадобится комп или виртуалка с любой виндой: XP, 7, 8 - подойдет что угодно. Этот комп должен входить в состав домена Active Directory.
Следующим шагом нам нужно установить Apache, PHP, MySQL на наш комп. Устанавливать эти компоненты можно по отдельности, скачивая windows-сборки этих программ, но я бы рекомендовал скачать один сборник WAMP (Windows Apache MySQL PHP). На момент написания обзора актуальная версия WAMP 2.5. Все компоненты установятся в несколько кликов. Т.к. это сборник компилируется разработчиками компиляторами MS, то предварительно на вашем компе должен быть установлен пакет Microsoft Visual C++ 2012 Redistributable Package той же разрядности что и WAMP. Если WAMP вы скачали 32-битный, а операционка у вас 64-бита, то VC2012 надо ставить обеих разрядностей. В целом, под наши задачи 64 бита это баловство и я бы рекомендовал взять 32 битную ОС и 32 битный WAMP.
Очень рекомендую установить на комп какой-нибудь нормальный текстовый редактор для правки конфигурационных файлов WAMP сервера. Например, bred . Встроенный Блокнот Windows не распознает переносы строк с Linux-like текстовых файлов.
WAMP обычно устанавливается в каталог C:wamp. В процессе установки нас попросят указать браузер по умолчанию. Я так и не понял какой именно браузер они спрашивают: файловый или интернет, я указал iexplore по адресу С:Program FilesInternet Exploreriexplore.exe. После установки в трее появится иконка в виде буквы W. Цвет значка обозначает статус работы: зеленый - все работает, оранжевый - запускается или останавливается, красный - не работает.
Клик левой кнопки мыши по значку открывает основное меню WAMPа.
По умолчанию, свежеустановленный веб-сервер будет открываться только с того компьютера, где он установлен по адресу http://localhost (верхний пункт меню) Если туда зайти, то мы увидим стартовую страницу, где будет расписано какие расширения установлены, можно быстренько глянуть phpinfo и пр:
Т.к. проект WAMP постоянно развивается, но не лишним будет песоздать все относительные ссылки, путь которых от версии к версии меняется. Делает это одним кликом, нужно просто кликнуть мышой по номеру версии в меню ApacheVersionx.x.x, где x.x.x это версия Апача:
Если этого не сделать, то некоторые нужные нам PHP-модули могут не загружаться, о чем будет много записей в логах:
Затем, нам нужно прикрутить к Apache модуль sspi той же разрядности, что и WAMP. .
В архиве вы найдете 2 папки, их нужно скопировать с заменой в каталог C:wampbinapacheapachex.x.x
После этого с помощью текстового редактора открываем конфиг апача из каталога c:wampbinapacheapachex.x.x confhttpd.conf
Примерно в начале конфига будет раздел, где прописаны все загружаемые модули. Дописываем туда модуль sspi (LoadModule authnz_sspi_module modules/mod_authnz_sspi.so) и проверяем, что модули authn_core_module и authz_core_module не закомментированы символом #:
Я попытаюсь тут разъяснить то, как я подхожу к написанию сайтов, где могут применять подключаемые модули. Пример тому известный скрипт PHPNuke. Как бы не ругали его, подход, примененный в нем, к модульному программированию очень удобен. Но из-за корявости общего кода применять такой скрипт на серьезных сайтах, точнее скажем порталах, с большим количеством посетителей, не рекомендуется. Почему? Скрипт работает медленно, очень большая нагрузка на базу данных. Можно еще очень много чего описать, но это уже материал для другой статьи. Если кому интересно, то в интернете полно описаний этого движка. В <неудобоваримости> PHPNuke я убедился сам. Мой основной проект NVIDIA BIOS Collection в начала базировался на PHPNuke, но постоянные проблемы с хостингом заставили меня начать разработку своей система портала с нуля. Из PHPNuke я взять только суть модулей, все остальное же делал сам. И так для начала. Прежде всего, надо продумать систему каталогов, что и где будет лежать. Вот примерный вариант.
* /mods/ — каталог для хранения модулей
* /img/ — картинки
* /include/ — каталог вспомогательных файлов
Это что нам сейчас пока надо. Применять блоки и скины мы пока не будем. В моем портале также были другие каталоги
* /blocks/ — Тоже своего рода модули, но не выводящие сами информацию, а возвращающие заполненную переменную.
* /js/ — каталог для Java скриптов
* /theme/ — каталог выбора тем или, грубо говоря, набор скинов для сайта.
* /files/ — файлы для скачивания
ну и другие каталоги.
В корневом каталоге храниться всего один файл index.php и вся работа идет через него. Теперь надо решить как будет выглядеть сам сайт. Для нашего примера подойдет наипростейший вариант дизайна, верх сайта, низ сайта, а в середине наша информация из модулей. Для этого в каталоге include создадим два файла top.php и bottom.php, что соответственно будет верхней частью дизайна и нижней частью дизайна.
|
здесь выводится шапка |
|
|
Меню сайта
- Модуль1
|
";
?>
Предвижу комментарии, где скажут, почему я не вывожу HTML код отдельно, а php отдельно. Я приучил себя к написанию 100% PHP кода, с одной стороны не очень и красиво может выглядеть, но мне так удобнее. Если кто-то хочет писать по-другому, то тут я не советчик. Заметьте переменную $PAGE_TITLE в top.php. В моей реализации вся информация о модулях храниться в базе данных, где помимо имени файла модуля храниться также и его название, которое потом и кладется в $PAGE_TITLE, для вывода его в головок браузера. |
Также создадим файл конфигурации config.php и положим его в каталог include.
Вот примерная схема работы index.php
Теперь создадим два файла mod1.php и mod2.php и положим их в каталог mods.
"; 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_имя переменной. Другой очевидный недостаток это трудность реализации разных вариантов дизайна для разных модулей. Но! Тут есть выход тоже.
Я попытаюсь тут разъяснить то, как я подхожу к написанию сайтов, где могут применять подключаемые модули. Пример тому известный скрипт PHPNuke. Как бы не ругали его, подход, примененный в нем, к модульному программированию очень удобен. Но из-за корявости общего кода применять такой скрипт на серьезных сайтах, точнее скажем порталах, с большим количеством посетителей, не рекомендуется. Почему? Скрипт работает медленно, очень большая нагрузка на базу данных. Можно еще очень много чего описать, но это уже материал для другой статьи. Если кому интересно, то в интернете полно описаний этого движка. В «неудобоваримости» PHPNuke я убедился сам. Мой основной проект NVIDIA BIOS Collection в начала базировался на PHPNuke, но постоянные проблемы с хостингом заставили меня начать разработку своей система портала с нуля. Из PHPNuke я взять только суть модулей, все остальное же делал сам. И так для начала. Прежде всего, надо продумать систему каталогов, что и где будет лежать. Вот примерный вариант.
//mods/ - каталог для хранения модулей
/img/ - картинки
/include/ - каталог вспомогательных файлов
это что нам сейчас пока надо. Применять блоки и скины мы пока не будем. В моем портале также были другие каталоги
/blocks/ - Тоже своего рода модули, но не выводящие сами информацию, а возвращающие заполненную переменную.
/js/ - каталог для Java скриптов
/theme/ - каталог выбора тем или, грубо говоря, набор скинов для сайта.
/files/ - файлы для скачивания
ну и другие каталоги.
В корневом каталоге храниться всего один файл index.php и вся работа идет через него. Теперь надо решить как будет выглядеть сам сайт. Для нашего примера подойдет наипростейший вариант дизайна, верх сайта, низ сайта, а в середине наша информация из модулей. Для этого в каталоге include создадим два файла top.php и bottom.php, что соответственно будет верхней частью дизайна и нижней частью дизайна.
top.php|
здесь выводится шапка |
|
| Меню сайта
- Модуль1 |
";
?>
Предвижу комментарии, где скажут, почему я не вывожу HTML код отдельно, а php отдельно. Я приучил себя к написанию 100% PHP кода, с одной стороны не очень и красиво может выглядеть, но мне так удобнее. Если кто-то хочет писать по-другому, то тут я не советчик. Заметьте переменную $PAGE_TITLE в top.php. В моей реализации вся информация о модулях храниться в базе данных, где помимо имени файла модуля храниться также и его название, которое потом и кладется в $PAGE_TITLE, для вывода его в головок браузера. bottom.php |