Оптимус Пьян

обрезать все запятные, точки, дефисы (тире) и т.д.

$str = preg_replace('/[^a-zA-Zа-яА-Я ]/i', '', $str);

Начинающему PHP разработчику фреймворки не нужны. Пишите на чистом PHP. Не стоит браться за работу, если чувствуете, что она Вам не под силам и это Вам ещё рано.

не рекомендовал бы frame для крупного проекта. вопрос производительности возникнет - ковырятся придется долго. а так сами сможете сделать все под свои нужды чтобы быстро и гибко, потому что сами писали - проверено неоднократно!

Например таймер до конца
допустим до конца чего либо осталось 180 секунд
Демка

(function($){
    // Количество секунд в каждом временном отрезке
    var days	= 24*60*60,
    hours	= 60*60,
    minutes	= 60;
    
    $.fn.timer = function(callback){
        callback = callback ? callback : function(){}
        return new $.ctimer(this, callback);
    }
    $.ctimer = function(element, callback) {
        callback = callback || function(){}
        var secs = parseInt(element.html());
        function tick(){
            // Осталось дней
            var sec = secs;
            var d = Math.floor(sec / days);
            sec -= d*days;
			
            // Осталось часов
            var h = Math.floor(sec / hours);
            sec -= h*hours;
			
            // Осталось минут
            var m = Math.floor(sec / minutes);
            sec -= m*minutes;
			
            // Осталось секунд
            var s = sec;
            h = (h+"").length<2 ? "0"+h : h;
            m = (m+"").length<2 ? "0"+m : m;
            s = (s+"").length<2 ? "0"+s : s;
            if(secs==0){
                element.html(null);
                callback();
                return false;
            }
            secs--;
            element.html(d+" дн. "+h+":"+m+":"+s);
            setTimeout(tick, 1000);
        }
        tick();
    }
})(jQuery);

Не используйте пароль, аутентифицируйтесь по ключу (winscp.net/eng/docs/public_key)

Как-то так

$ch = curl_init('http://site.com/picture.jpg');
curl_setopt(CURLOPT_RETURNTRANSFER, true);
$pic = curl_exec($ch);
curl_close($ch);
file_put_contents('pic.jpg', $pic);

Там же написано: Could not installed memcache

Спросите на otvet.mail.ru .

Что мешает добавить else между двумя корневыми if?
А вообще, для множества однотипных сравнений лучше использовать конструкцию switch.

Я решил взяться за это дело нормально и подарить миру нормальную cms.

Я решил взяться за это дело нормально и подарить миру нормальную cms.

Удачи. Получится как обычно.

Не рассматривали схему, которую выбрали всякие gitlab, магенты и и т.д.? open-source + энтерпрайз редакции + суппорт.

Все очень просто. Вот вам приблизительное значение таймингов доступа к данным:


То есть запросив данные в сети мы тупо ждем. Долго ждем и ничего не делаем.

В случае с curl (он же HTTP) мы можем соорудить очередь запросов и послать их одним махом и ждать пока завершится загрузка всех документов в очереди для обработки результатов. Если мы хотим забрать 10 документов, то без multi curl у нас ушло бы времени "среднее время получения документа" * 10. И это примерно. В случае же с мультикурлом мы получаем время обработки 10 запросов как время выполнения самого долгого запроса. Если представить что время запросов всегда одинаковое, получаем выйгрыш примерно в 10 раз.

С сокетами веселее. Они бывают блокируемые (по умолчанию) и неблокируемые (выставляется опцией O_NONBLOCK). Для начала давайте определимся что такое чтение данных из сокетов и как нам это дело предоставляет операционная система. Упрощенно, когда мы создаем сокет, мы просто просим операционную систему предоставить оный. У каждого сокета есть буфер чтения и буфер записи. Если буфер записи полный - ОС начинает отправку данных пока буфер не опустеет (буфер записи нужен для организации проверки дошли ли пакеты и переотправки в случае чего, так же этот буфер замешан в выборе операционкой размеров пакетов и т.д. Это не особо важно в контексте вопроса). Когда данные приходят в сокет, сначала они помещаются в буфер чтения. Там они лежат пока их не попросят вернуть из кода. Так мы можем быть уверены в том, что данные не пропадут.

Так вот... возьмем блокирующие сокеты и попробуем запросить 1024 байт данных из оного. Причем клиент в данный момент ничего не отправляет, буфер чтения пустой. И так допустим минут 10. Как только мы сделали запрос за данными, и оказалось что буфер чтения пустой, процесс выполнения блокируется пока не появятся данные.

А теперь представим что проверять периодически наличие данных нам надо не в одном сокете а в десятке. Представим так же что 9 клиентов подключенных по нашим сокетам хорошие и присылают данные вовремя, а один не хороший и любит тупить по пол часа. Если бы мы пользовались блокирующими сокетами, то мы можем обрабатывать только одного клиента за раз. Причем если у него вдруг данных не оказалось - нам придется ждать, хотя в других сокетах уже вполне могли появиться данные какие для обработки. И если в случае с "хорошими" клиентами мы можем тратить на оных по пол секунды - секундочке, то наткнувшись на плохого клиента наш сервер замирает за те самые пол часа о которых мы договаривались. Сервер тупо ждет "плохого" клиента а хорошие в итоге не могут достучаться до сервера. Новых соединений мы так же не установим... короче все мертво.

И тут на помощ к нам приходит опция O_NONBLOCK. В этом случае если у сокета пустой буфер чтения он сразу вернет выполнение не вернув нам ни капли данных не дожидаясь медлительных клиентов-тугодумов. В случае если буфер не пустой - все будет так же как и в случае с блокирующими сокетами - тупо вернет содержимое буфера и вернет управление. Так что мы можем в бесконечном цикле просто проверять по очереди все сокеты. В этом случае делей получения данных будет сведен к минимуму.

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

Еще есть такая чудная штука, которую предоставляет операционная система как select или epol (в контексте php socket_select и stream_select). Данные функции позволяют нам скармливать массивы сокетов, за которыми вы следите (не сокетов, а их дескрипторов но не суть, и не один массив а три, массив дескрипторов что бы следить появились ли данные на чтение, записал ли сокет все и освободился ли буфер записи и третий отслеживает сокеты в которых произошли какие-то ошибки, например отвалилось соединение). Так же этой функции можно задавать таймаут, что очень удобно если мы сначала собираем данные с нескольких клиентов и если от них небыло вестей пару секунд, значит мы забрали все и можно начинать обработку.

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

Но все что выше имеет смысл только с TCP/TLS, если бы у нас были UDP сокеты, то было бы еще веселее. Там нету никаких буферов. Не принял данные - потерял данные. Нету соединений. Нету блокировок. Есть только пакеты. Поэтому этот протокол используют (или используют как основу) для реализации реалтайм систем. Задержек нету, а если какой пает не дошел, велика вероятность что он уже не актуален. Правда если сеть не надежная и потери пакетов велики, то начинается боль и слезы и обычно все же для таких случаев дублируют все на TCP.

Метод конструктор вызывается при инициализации объекта. В контексте PHP его главная задача - инициализировать все свойства значениями, что бы добиться какого-то начального состояния объекта. Так же туда следует передавать все зависимые классы. И крайне не рекомендуется в конструкторе делать что-то сложное, например, как пишет @hlogeon, кого-то нотифаить о своем присутствии, или с конфигами работать. Это все должно быть по хорошему сделано до инициализации. Если у вас в конструкторе код лезет в файлы/базу то это уже сигнал о плохом дизайне.

class Bar {
    public function doSomething() {}
}
class Foo{
    private $bar;
    private $someConfig;
    private $createdAt;
    public function __construct(Bar $bar, $someConfig) {
         $this->bar = $bar;
         $this->someConfig = $someConfig;
         $this->createdAt = new \DateTime();
    } 
}

// загружаем конфиг каким-то образом
// мы не должны заставлять Foo что-то делать еще, что не относится к его задаче
// например он не должен знать как создается класс Bar и что ему нужно
// он не должен ничего знать о том где хранятся конфиги и т.д. 
// Для этого можно отдельный класс сделать, который будет знать где брать конфиги
// но не будет знать как эти конфиги используются.
$config = $configurator->getConfig('foo');
$bar = new Bar();
$foo = new Foo($bar, $config);

Для официального трудоустройства - норм. Вообще почитайте там трудовой кодекс и погуглите.

p.s. по ссылкам наверняка какой развод или для голодных студентов/школьников чего.

CMS - это уже законченный продукт, и на нем будет сложно сделать что-то, кроме того, для чего она разрабатывалась, т.к вы ограниченные ее функционалом и задачами и т.д, вообщем всем, тем для каких целей она создавалась.

Фреймворк - это нечто совершенно другое, это строительный материал, как пластилин и Вы вольны его использовать, как Вам вздумается.
Т.е фрейморк просто набор функций, грубо говоря ядро вашего будущего проекта, обычно включает в себе: кеширование, ORM, шаблонизатор, MVC, di и т.д, на разработку, которых Вам не придется тратить время, и Вы сможете спокойно сконцентрироваться на разработке уже свое продукта, а не его ядра.