• Есть ли аналог функции dbDelta из Wordpress в Drupal 7?

    kalabro
    @kalabro
    Изменения схемы таблиц указываются явно в хуках-обновлениях.
    Например, чтобы увеличить размер поля типа varchar нужно сделать нечто такое (источник):

    /**
     * Enlarge URL field size for popular content database table.
     */
    function yandex_metrics_reports_update_7202() {
      db_drop_unique_key('yandex_metrics_reports_popular_content', 'url');
    
      db_change_field('yandex_metrics_reports_popular_content', 'url', 'url', array(
          'description' => 'The url obtained from Yandex.Metrika.',
          'type' => 'varchar',
          'length' => 2048,
          'not null' => TRUE,
          'default' => ''
        ),
        array(
          'indexes' => array('url' => array(array('url', 255))),
        )
      );
    }

    Далее нужно запустить процесс обновлений, перейдя по ссылке /update.php.

    Здесь разработчик сам работает с базой, используя функции db_ (например, db_rename_table, db_change_field, db_field_set_default и т.д.) Друпал за него это делать не будет, чтобы ненароком не повредить данные :)
    Есть модули, которые показывают разницу между схемой в модуле и реальным положением вещей в базе: https://www.drupal.org/project/schema, но изменения вносятся автором модуля.
    Ответ написан
    1 комментарий
  • Какие существуют способы защиты стилей CSS?

    opium
    @opium
    Просто люблю качественно работать
    мне кажется мания величия затмила ваш мозг глупейшими проблемами, вместо того чтобы код красиво оформить и выкладывать на гитхаб и делиться им, вы решили его зачем то прятать, просто задумайтесь, что хорошего вы сделали в жизни и почему не выкладываете его на гитхаб?
    Ответ написан
    11 комментариев
  • Связка Nginx+Apache. Странное поведение virtual hosts - почему?

    nowm
    @nowm
    Я сначала немного «теории» опишу, а в конце скажу, что в ваших конфигах нужно поправить.

    Вообще, у вас Apache не должен принимать никаких запросов от сторонних серверов. Связка Apache + Nginx делается потому, что Nginx очень хорошо отдаёт статичный контент, а Apache выигрывает в работе с PHP. К тому же, Apache даёт возможность использовать файлы .htaccess, которые позволяют очень гибко конфигурировать работу на уровне директорий одного сервера.

    Так вот. Суть связки Apache + Nginx в том, что Apache обрабатывается входящие запросы только от одного сервера. Обычно они оба ставятся на одной машине, и в этом случае Apache должен принимать запросы только от 127.0.0.1. Он не должен заботиться о том, чтобы обрабатывать имена dev1.site, dev2.site и так далее. Эта задача лежит на Nginx, который будет перенаправлять внешние запросы соответствующим образом.

    Для этого Apache конфигурируется таким образом, чтобы каждый его виртуальный хост слушал свой порт. Например, я строю всю систему таким образом, чтобы у меня было два сервера: task.site и dev.site. Для этого я делаю так:

    /etc/apache2/ports.com:
    NameVirtualHost 127.0.0.1:8080
    NameVirtualHost 127.0.0.1:8090
    Listen 127.0.0.1:8080
    Listen 127.0.0.1:8090


    Это значит, что у меня будет два инстанса, один из которых будет обслуживать имя dev.site, а другой — task.site (при этом, сам Apache как бы будет не в курсе, какой он домен обслуживает. Он знает только что запрос на порт 8080 нужно так обработать, а на 8090 — ещё как-то). Всё, что теперь от апача понадобится — сделать виртуальные хосты, чтобы определить папки, из которых будут вызываться скрипты для каждого из сайтов.

    /etc/apache2/sites-enabled/default.conf:
    <VirtualHost 127.0.0.1:8090>
    	. . .
    	DocumentRoot /usr/share/redmine/public
    	. . .
    </VirtualHost>
    <VirtualHost 127.0.0.1:8080>
    	. . .
    	DocumentRoot /var/www/dev.site
    	. . .
    </VirtualHost>


    Всё. Если запрос будет на 127.0.0.1:8080, то будут выполняться скрипты из папки /var/www/dev.site. Если на 127.0.0.1:8090, то — /usr/share/redmine/public. Сам Apache вообще не в курсе, какие он домены обслуживает, так как снаружи его не видно.

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

    /etc/nginx/sites-available/default.conf:
    server {
    	listen 80;
    	server_name dev.site;
    	server_name_in_redirect off;
    
    	location / {
    		proxy_pass http://127.0.0.1:8080/;
    		proxy_redirect off;
    		proxy_set_header Host $host;
    		proxy_set_header X-Real-IP $remote_addr;
    		proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    		client_max_body_size 10m;
    		proxy_connect_timeout 90;
    	}
    }
    
    server {
    	listen 80;
    	server_name task.site;
    	server_name_in_redirect off;
    	
    	location / {
    		proxy_pass http://127.0.0.1:8090/;
    		proxy_redirect off;
    		proxy_set_header Host $host;
    		proxy_set_header X-Real-IP $remote_addr;
    		proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    		client_max_body_size 10m;
    		proxy_connect_timeout 90;
    	}
    }


    Как видно из листинга, он для dev.site делает proxy_pass http://127.0.0.1:8080/, а для task.siteproxy_pass http://127.0.0.1:8090/.

    Теперь о том, что нужно поправить в ваших конфигах. В апаче нужно все сервера раскидать по отдельным портам. Сначала нужно прописать NameVirtualHost и Listen для каждого из них. При этом, обязательно нужно указывать не *:8080 или *:8081, *:8082, а конкретно 127.0.0.1:8080, 127.0.0.1:8081 и т.п., потому что «*» позволяет делать прямые запросы с любой машины, а «127.0.0.1» разрешает принимать соединения только с localhost.

    То же самое — в блоках VirtualHost. Вместо <VirtualHost *:8080> нужно писать <VirtualHost 127.0.0.1:8080>

    Из блока VirtualHost нужно выкинуть ServerName и ServerAlias, так как всё это будет обрабатываться на уровне Nginx.

    В итоге вы получите такую ситуацию, что напрямую у вас sub.myhost.ru:8080 открываться не будет, так как Apache принимает запросы только от localhost. Он будет открываться только по запросу от Nginx, который будет определять какой сервер куда проксировать.

    В вашем конфиге Nginx вместо server_name *.myhost.ru; нужно писать полное имя хоста. И для каждого хоста нужно создать отдельный блок server {}.

    В конфигах Nginx ещё не забудьте приписать обработку статики (хотя у вас она и так прописана). Я из листинга этот момент выкинул, но его вообще нужно добавить, потому что одна из прелестей Nginx — как раз обработка статики. В каждый блок server {} можно добавить что-нибудь вроде:

    location ~* ^.+\.(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|js|pdf)$ {
    	root /var/www/dev.site;
    }


    И далее, если вы хотите добавить подсервер: создаёте виртуальный хост апача на свободном порту, а в Nginx добавляете для него блок server {}.

    В данный момент у вас просто небольшая каша получилась в конфигах.
    Ответ написан
    8 комментариев
  • Быстрый разворот копий веб-серверов — это реально?

    Anonym
    @Anonym
    Программирую немного )
    Клонируйте виртуалку да и всё.
    Ответ написан
    Комментировать
  • Быстрый разворот копий веб-серверов — это реально?

    VasiliyIsaichkin
    @VasiliyIsaichkin
    Web front/back-end (JS-full stack) app developer
    Абсолютно реально и так многие делают. У меня в свое время такой "все-могун" скрипт под 1 мб весил :) (8 ролей, всякая вирутализация, и прочее и прочее - сложнейшая система из 12 серверов разворачивалась запуском скрипта)
    Ответ написан
    Комментировать
  • Как правильно организовать деплой приложения?

    Мой стек php:
    — для тестов: локально Behat;
    — для деплоя capifony;
    — для модульности composer.
    Ответ написан
    Комментировать