Ошибки cms drupal и piwigo при обновлении mysql.

Апрель 16, 2021 Время чтения: 3 минуты

Как-то я решил, что мне слишком скучно в последнее время и я решил обновить ubuntu на моем vps с версии 18 до 20.04

Сказано - сделано!

После перезапуска mysql-сервера, проблемы начались на двух из трех сайтов, а именно они использовали эту субд. При попытке зайти на сайт с drupal cms вылезало окошечко:

PDOException: SQLSTATE[42000]: Syntax error or access violation: 1231 Variable 'sql_mode' can't be set to the value of 'NO_AUTO_CREATE_USER'

Так случилось из-за обновленной версии mysql. К счастью - правится это легко.

Открываем файл в редакторе

/var/www/your_website/includes/database/mysql/database.inc

Ищем строку режима работы sql и удаляем из нее NO_AUTO_CREATE_USER, так как именно на это ругается drupal

Было

sql_mode="REAL_AS_FLOAT,PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE,STRICT_TRANS_TABLES,STRICT_ALL_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER"'

Стало

sql_mode="REAL_AS_FLOAT,PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE,STRICT_TRANS_TABLES,STRICT_ALL_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO"'

Все, с Drupal разобрались. Можно переходить к piwigo

 

Тут все тяжелее и легче. Ругань подобного рода.

arning: [mysql error 1064] You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'groups, show_title, id_line, width

Как исправить это, я не нашел, но примерно понял, что проблема скорее всего с  дополнительными плагинами. На это указывал еще и тот факт, что мобильная версия сайта запускалась и прекрасно работала, а для нее плагины типа additional page, header manager не предназначены.

Все что  я сделал, это забрался в админку через версию для телефона и обновил все плагины и саму версию piwigo до 11. Теперь все работает.

Вам ведь не нужно напоминать, что вы все делаете на свой страх и риск, и автор статьи не несет ответственности за возможный причиненный ущерб? ;-) Экспериментируйте, ведь дорогу осилит идущий.

Apache2 выдает 404 в drupal 7

Сентябрь 30, 2020 Время чтения: 3 минуты

Предисловие

Был у меня хостинг в французской компании ovh.com и как-то не заплатил я вовремя за vps и буквально за несколько дней, без предупреждения, они все под чистую удалили без возможности восстановления.

Я написал в саппорт с закономерным вопросом "чоза?!" На что, через 4 дня (невиданно высокая скорость ответа для этих лягушатников) получил примерно следующее: "Вы ля, не платить ля, и мы удалять ля. Теперь вы должны ля, снова через личный ля кабинет, добавлять новый vps ля!"

Разумеется первым делом я решил именно так и поступить! Но вдруг червячок сомнения начал покусывать: а нужен ли мне такой хостер? И козырнув в монитор, сказав "au revoir ля" я начал поиски другого хостера. Нашел дешевле и производительней.

 

Благо резервные копии сайтов у меня сливаются в облако и с этим проблем не было. Но вот после развертывания всего, один из сайтов, построенных на drupal 7, вел себя странно: Главную страницу он загружал нормально, а вот при переходе по любой ссылке apache плевал 404 page not found

Как-то раз я уже сталкивался с этой проблемой, но уже не помнил как решал, а так как я был слишком гордый, чтобы сразу написать подобный пост, пришлось вспоминать все что забыл. А дело-то плевое:

Такое поведение сайта происходит из-за отключенного модуля rewrite

Чтобы включить его нужно набрать в консоли:

sudo a2enmod rewrite

А если на веб-сервере присутствуют виртуальные хосты, то в конфигурационном файле

/etc/apache2/apache2.conf

Нужно поправить запись c AllowOverride none на AllowOverride ALL

<Directory /var/www/>             
Options Indexes FollowSymLinks
AllowOverride All                       
</Directory>                            

После чего, перезапускаем веб-сервер:

sudo systemctl restart apache2

И наслаждаемся.

Вам ведь не нужно напоминать, что вы все делаете на свой страх и риск, и автор статьи не несет ответственности за возможный причиненный ущерб? ;-) Экспериментируйте, ведь дорогу осилит идущий.

 

Обновление ядра drupal

Январь 14, 2016 Время чтения: 2 минуты

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

Первым делом, нужно сделать резервную копию каталога с сайтом, затем скачать новую версию cms отсюда

Залив архив на хостинг, открываем его и удаляем каталог sites

Это именно та директория, в которой хранится ваш сайт и если при копировании данные будут заменены, на новые, то весь сайт будет потерян, а при открытии оного в браузере, вам предложат заново установить cms. Но ведь вы же сделали резервную копию каталога сайта и базы данных, да?

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

Если вы правили какие-нибудь конфигурационные файлы в процессе "причесывания" cms под свои нужды, то их тоже желательно сохранить, ибо будете переделывать.

Далее в админке, переходите на вкладку "модули" и запускаете скрипт update.php

Жмем "continue"

И в зависимости от обстоятельств, получаем список доступных обновлений, или сообщение об отсутствии таковых.

После чего нужно почистить кэш, кнопка для этого находится в: 

Главная » Управление » Конфигурация » Разработка » Производительность

И на этом обновление закончено и можно ждать следующего.

Вам ведь не нужно напоминать, что вы все делаете на свой страх и риск, и автор статьи не несет ответственности за возможный причиненный ущерб? ;-) Экспериментируйте, ведь дорогу осилит идущий.

Устанавливаем баннер на piwigo

Май 16, 2015 Время чтения: 2 минуты

В какой-то момент мне вдруг пришла мысль, что неплохо бы установить шапку на свою галерею, работающую на движке piwigo.

Раньше я подобного не делал, и по сути был готов к многочасовому гуглению, но мне повезло, и мне посоветовали плагин header manager. Конечно же не обошлось без бубна, а так как найти подобных хинтов в интернете не получилось, то пишу на всякий случай небольшое пособие, вдруг кому-то понадобится.

Первым делом нужно установить плагин, это легко и просто: в админке своей галереи, в пункте «плагины\\управление» идете на вкладку «другие плагины» и ищете header manager и устанавливаете его, как и любой другой плагин. У меня он уже был установлен и при попытке залить баннер, случилась первая ошибка:

«Warning: getimagesize: failed to open stream: No such file or directory in»

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

«[Image] unsupported file extension»

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

2014/02/11 14:46:41 [error] 75202#0: *32276 FastCGI sent in stderr: "PHP message: PHP Warning: move_uploaded_file(./local/banners/20140211-52f9ff91ddb20.PNG): failed to open stream: Permission denied in /usr/home/user/www/klpnet.ru/plugins/header_manager/admin/add.php on line 91

Это означает извечную проблему с правами в unix системах. Полез я глядеть файл add.php хотя зачем?! Не вполне очевидно для меня, но по сути следует, что права нужно изменять на каталог

/local/banners/

Делаем

Chmod 777 banners

И вуаля! Все заработало!

Вам ведь не нужно напоминать, что вы все делаете на свой страх и риск, и автор статьи не несет ответственности за возможный причиненный ущерб? ;-) Экспериментируйте, ведь дорогу осилит идущий.