forbidden 403 apache 2

Если после установки и настройки LAMP в Ubuntu like системе, при заливке сайта на отдельный каталог не /var/www получаете ошибку


Forbidden 403

apache 2.2 etc то,

ctrl+alt+t

sudo gedit /etc/apache2/apache2.conf 

+ add 

<Directory /home/your_user/> 

 Options Indexes FollowSymLinks 

 AllowOverride None 

 Require all granted

</Directory> 

+ sudo service apache2 restart

Мне помогло)

если не запускается phpmyadmin после установки

Переустановил linux (на опыте узнал что terminal quake и видеокарта GeForce 820 однако ж, не совместимы - система морозилась каждые 5 мин)
дошла очередь до LAMP - локального сервера для веб-опытов.
Все стандартно, установил php, apache2 etc.
установил phpmyadmin. Но после перехода на localhost/phpmyadmin получил ошибку

 404 "Not Found"...

Перезагрузил apache, толку нет.
Тогда помогла волшебная таблетка команда

sudo dpkg-reconfigure -plow phpmyadmin

В особо крайних случаях помогает

sudo ln -s /etc/phpmyadmin/apache.conf /etc/apache2/conf.d/phpmyadmin.conf
sudo /etc/init.d/apache2 reload

 Всем добра!

Laravel 5, и select box, integer в массиве наоборот

Продолжается битва с laravel 5, хроника событий. Кстати, уже вышла 5.1 Но я все еще на 5.0))

Странная штука, в Laravel 5
Есть форма, с выпадающим селектом, для выбора цифровых данных, например чисел от 5 до 50.
Добавил в view, фасад формы

<div class="value">
{!! Form::label('value', 'Числа:') !!}
{!! Form::select('value', [5,10,15,20,30,50], ['class' => 'form-control']) !!}
</div>

Выводил: 5,10,15,20,30,50
Но в контроллер после отправки формы - попадает value:0

Попробовал так:
<div class="value">
{!! Form::label('value', 'Числа:') !!}
{!! Form::select('value', ['пять'=>5,'десять'=>10], ['class' => 'form-control']) !!}
</div>
Все равно -  попадает value:0

Долго соображал в чем дело)

Оказывается все просто - данные в передаваемом массиве, шли наоборот,
нужно писать вот так:

<div class="value">
{!! Form::label('value', 'Числа:') !!}
{!! Form::select('value', [5=>'пять',10=>'десять'], ['class' => 'form-control']) !!}
</div>

Нашел классные видеоуроки по PHP фреймворку Laravel

Хай

Вот и докатился до фреймворков, или эволюционировал...
после Kohana, которая все меньше поддерживается php сообществом, решил досконально изучить популярный Laravel.

Впечатления, по ходу изучения. Но уже нравится, поддерживает из коробки авторизацию, валидацию, ORM, и JSON.

Для обучения решил смотреть видео, и наткнулся на уроки Son Sothea. 14 уроков, на английском, но для нас это не проблема) наоборот, польза. Язык приятный, и легкий, видео с шутками, не индусский, слушается легко.

ссылка на третий урок, а дальше по ходу дела, найдете.

Посмотрим, дальше, буду добавлять по ходу дела, видео, и авторов туториалов по Laravel

Удобный класс для работы с БД MySqli от Joshcam

Прива, народ)
Перепробовав несколько классов для работы с базой данных MySqli, остановился на этом PHP-MySQLi-Database-Class

До этого использовал SimpleDb - он хороший, но очень простой, если делать сайт-визитку, ок. Примеры на хабре, тыц. Но когда требования возрастают... потребовался калибр покрупнее) И мой выбор пал на PHP-MySQLi-Database-Class.

И вот почему - удобно) и подробно расписано что и как использовать. Теперь меньше уходит времени на рутину) уже форкнул к себе, на всякий пожарный.
Кому интересно - ссылка на Github оригинал
Надеюсь пригодится, если требуется класс для работы с MySQLi + PHP.

От нас большая благодарность чуваку Joshcam за труд. Действительно полезный инструмент.

cms 100500+100500+ модулей. Пора что-то менять

Посетила меня мысль, о разработке собственной open-source cms. Их тысячи, но большинство, не следуют пути дзен... все эти модули, компоненты, плагины, возникает сложносочетаемое приложение. Некоторые гордо называют это конструктором.

Как же разрабатывают cms?
Пишут админпанель, функции, главная страница, хуки, и добавляют возможность добавления модулей.
То есть к основному блоку - скелету, каркасу, добавляют возможность добавлять другие блоки, к ним третьи...

Все ок, пока не происходит обновление Главного блока, костяка cms. Знаете что следует? Ваши модули не работают, обновляйте их, а если не обновляется, не совместима, ищите другие модули, компоненты, пишите сами.

Работает сайт, год-два, полет нормальный. Затем находят баг, и Вы в обязательном порядке обновляетесь - потому что, безопасность сайта штука серьезная. И в большинстве случаев, танцуете с бубном)

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

Обновление cms должно происходить вместе с обновлением всех существующих модулей. Да и вообще, модули нужны ли?
Представим себе cms без лишних 100500+ модулей.
Все из коробки, установил - работает, один мануал для всей cms, очень удобно.

Как я себе это представляю:
Нужно создать три направления одной cms: 1. Магазины, 2. Портал 3. Блог.

Тем самым, мы избегаем постоянного обновления, при изменениях. Так как вероятность багов будет снижена, количеством кода. Ведь для каждого направления требуется меньше кода, чем для одного костяка. Сам не понял, что напечатал). Привожу example.

Пример:

SuperPuperCMS-shop
Один костяк, с 10 модулями. (модуль возможности оплаты, совместимости с cvs, отзывы и тп, так как не всем магазинам требуется сразу устанавливать оплату, бухгалтерию.) Не более 10 модулей в итоге.

SuperPuperCMS-portal
Один костяк, с 7 модулями. (Возможность форума например, тоже не всем порталам сразу нужна ) Не более 7 модулей в общем.

SuperPuperCMS-blog
Один костяк, с 3 модулями. (тут незнаю, блогам вообще нужны модули?) Не более 3, на всякий случай.


Возможность фотогалереи, page navigation, и других обязательных функций для любой хорошей cms вшито в общий скелет cms. Модули же, являются дополнительными необязательными возможностями, которые устанавливаются по желанию.

Да это увеличит исходный код, так сказать  "москитом" cms не будет, но это будет лишь вначале.
По мере развития проекта, в коде не будет костылей, для совместимости с предыдущими версиями, модулями сторонних разработчиков, и это не позволит исходникам разрастаться больше чем нужно для работы

Мы разработчики модулей, плагинов, компонентов - распыляемся подтачивая модули, для заказчиков, что бы добавить функции, которые затем потребуются кому то еще. Этих модулей, компонентов и плагинов, сотни тысяч! Это код, который требуется обновлять, но много ли Вы знаете разработчиков, которые обновляют модули, с каждым багфиксом cms? сотни в лучшем случае.

Это приводит к снижению безопасности, совсем недавно я обнаружил пару лазеек и зашел в админку крупного сайта с собственными блогами, потому что админ своевременно не обновил wordpress и соответственно осталась возможность навредить этому сайту-порталу. Естесственно, я написал админу, о ситуации на email, со скриншотами. Но пока не увидел результата.

После безопасности, на втором месте, удобство. Знакомый код, легче для понимания, и поиска ошибок. Меньше медитации, больше свободного времени на действительно важные дела, например научиться делать сальто) и удивлять девушек на пляже).

Действительно важные дела

Мысль сия, пришла мне в голову только сегодня, окончательно еще не созрела, поэтому пока показать ничего не могу. Вначале думаю о языке для разработки: php, python, ruby?... а может Go). Я понимаю, что одному мне это не потянуть.

UPD: Месяц назад набрел на Kohana (О, уже месяц не заглядывал в блог!), присматривался уже давно, но в этот раз решил, взяться и переделать уже проект который я писал под Asp.net.
И понял, вот оно! Единый код, открытый, легкий для освоения, и гибкий, без лишних модулей. Так что, за фреймворками будущее!

Если столкнулись с php ошибкой open_basedir

require_once() [function.require-once]: open_basedir restriction in effect

---

Вот что съело целый час моего времени, которое я мог потратить на разработку своего приложения DojoDojo. Возникает она, из-за настроек php.ini, а именно пункт open_basedir, в котором прописаны пути.

• open_basedir ограничивает список файлов, к которым может обращаться PHP, указанным деревом директорий.
• open_basedir может применяться независимо от того, используется защищенный режим или нет.

 На хабре уже обсуждалось, что из-за настроек open_basedir, файлы могут не загружаться на сервер.
Настройки php.ini можете просмотреть запустив phpinfo(), или создав файл info.php на сервере и вставив туда код

<?php
phpinfo(); 
?>

---

Он выведет, всю информацию, и в пункте open_basedir можно увидеть пути, которые открыты для использования скриптами. Значит если возникает эта ошибка, скорее всего Вашему скрипту доступ к каталогу, к которому доступ ему запрещает php.ini. Нужно дополнить, в значение open_basedir, путь до каталога скрипта.

Итак, ошибка ясна, что дальше? Рытье в гугле дало следующее.
Дальше есть три способа решить этот вопрос.
1. Изменить php.ini, добавив туда нужный каталог со скриптом, (просто вставив после двоеточия). Этот способ, я отношу к маловероятным, так как хостинг редко дает возможность изменять этот файл. Можете написать в техподдержку хостинга, возможно они решат эту проблему.
2. Добавить .haccess (если нет), прописав туда значение "php_value open_basedir Путь". Тоже не всегда помогает. Мне не помог. Но вдруг поможет Вам.
3. Создав свой php.ini файл, в корневой папке.
Если Php запущен как fast-cgi. А это обычно php 5.3*.
Добавляем в .htaccess

AddHandler php5-fastcgi .php
Action php5-fastcgi /cgi-bin/php5.fcgi

---

В этой же папке создаем папку cgi-bin (она уже там может быть), переходим в нее и создаем в ней файл php5.fcgi .
То есть выходит создан файл по адресу public_html/cgi-bin/php5.fcgi. Содержимое данного файла:

#!/bin/sh
exec /usr/local/cpanel/cgi-sys/php5 -c /home/ВАШ ЛОГИН ОТ СИПАНЕЛИ/public_html/cgi-bin/php.ini 

---

Сохраняем и ставим права на этот файл 755.

После чего, создаем файл php.ini там же, в папке cgi-bin и прописываем туда необходимые php директивы через равно. Например:

register_globals = on
magic_quotes_gpc = on

open_basedir = /home:/tmp

---

Сохраняем, и все начинает работать.

Да, способы, так себе, но пока не нашел ничего лучше.