Помощь Проблема в CherryFramework. Обнуление css

[wwizard]

Проблема на домене Для просмотра ссылки Войди или Зарегистрируйся
C основной папки сайта: 0:/мой сайт/wp-content/themes/theme45175/
файл: main-style.css - вдруг обнулился, и любая его перезапись на нормальный - тутже приводит к онулению его самого обратно

и с папки: 0:/мой сайт/wp-content/themes/theme45175/bootstrap/css/
файл: bootstrap.css - тоже самое - перезапись новым, через мгновение он пустой

Постоянно обнуляются. Начало происходить сегодня. Работ никаких по сайту не проводилось. Куда копать что делать? Шаблон на CherryFramework

 

[etok]

Как известно чудес не бывает.

Прежде всего убедись что правильно права прописаны: для файлов 644, для директорий 755.

ls -la /path/to/site

Обрати внимание на права для директорий открытых для записи - загрузка медиа (/wp-content/uploads) и кэш (/wp-content/cache)
Посмотри потому, что у тебя может быть даже полностью открыто 0777

ls -la /path/to/site/wp-content/uploads
ls -la /path/to/site/wp-content/cache

Запомни права (цифирки XXX)

Далее установи стандартные для всех директорий и файлов

Файлы: find /path/to/site -type f -exec chmod 644 {} \;
Папки: find /path/to/site -type d -exec chmod 755 {} \;

И верни те что были у директорий открытых для записи

chmod XXX /path/to/site/wp-content/uploads
chmod XXX /path/to/site/wp-content/cache

Надеюсь это быстренько решит твою проблему. Дальнейшие манипуляции "на пальцах" сложно объяснить. Общее правило такое: владельцем файлов и папок должен быть кто угодно кроме вэб сервера. Т.к. доступ извне (через браузер - без паролей и сертификатов как при FTP и SSH) - это именно вэб сервер. Владелец и группа меняются командоц chown usrName.groupName -R /path/to/site/target/dir

ЗЫ: Вот что разработчики рекомендуют по правам:
Для просмотра ссылки Войди или Зарегистрируйся

• All files should be owned by the actual user's account, not the user account used for the httpd process. Все файлы должны принадлежать пользоваталю ОС (/home/userName), а не пользователю под которым работет вэб сервер
  
• Group ownership is irrelevant, unless there's specific group requirements for the web-server process permissions checking. This is not usually the case. Группа не важна, разве что доступ веб.сервера настроен через нее.
  
• All directories should be 755 or 750. Все директории должны быть 755 или 750.
• All files should be 644 or 640. Exception: wp-config.php should be 440 or 400 to prevent other users on the server from reading it. Все файлы должны быть 644 или 640, за исключением wp-config.php - 440 или 400 чтобы другие ОС пользователи не могли их читать (относится к шаред-хостингам, прежде всего).
  
• No directories should ever be given 777, even upload directories. Since the php process is running as the owner of the files, it gets the owners permissions and can write to even a 755 directory. Ни одна из директори должна иметь права 777, даже /wp-content/upload - 755 достаточно.
  
  
  

 

[wwizard]

Как известно чудес не бывает.

не получилось. Все равно - все по старому

 

[etok]

1. останови процессы:

Apache2: sudo service httpd stop
Nginx: sudo service nginx stop
PHP-FPM: sudo service php-fpm stop​

Проверить статус: sudo service php-fpm status | sudo service nginx status | sudo service httpd status

2. Отредактируй проблемные файлы

0:/мой сайт/wp-content/themes/theme45175/bootstrap/css/bootstrap.css
0:/мой сайт/wp-content/themes/theme45175/bootstrap/css/main-style.css

3. Подожди что будет. Если нет какого-нибудь "левого" процесса и перезапись шла через веб.сервер, то, естесственно, с файлами ничего не произойдет (99% вероятность). Но ты убедишься что это именно веб.сервер и никаких рут.китов искть не надо.

4. Теперь посмотри где логи сайта и очисть их. Логи прописываются в настройках виртуального хоста. У Апача и Nginx по разному, но все танцуется от главных конфигов: /etc/nginx/nginx.conf и /etc/httpd/conf/httpd.conf
:> /path/to/logs/my-site_access.log

5. Далее запусти процессы: sudo service php-fpm start| sudo service nginx start | sudo service httpd start

6. Как только файлы перезапишутся останови процессы: sudo service php-fpm stop| sudo service nginx stop | sudo service httpd stop

7. Смотри что записал сервер в логах доступа хоста. Например: tail -n 20 /path/to/logs/my-site_access.log

Собственно в логах виртуального хоста (сайта), самого веб.сервера или php-fpm (если есть) нужно искать разгадку.

Другой вариант - убрать права на запись файла (но это банально и причина не будет найдена, а тупо заблокирована)

 

[wwizard]

Вот например я тут изменил: Для просмотра ссылки Войди или Зарегистрируйся
И записав куда надо файл
тут же получил, после обновл страницы
Для просмотра ссылки Войди или Зарегистрируйся

 

[etok]

1. Елси у тебя шаредных хостинг, то звони в тех.поддержку
2. Если ВДС - то по SSH нужно, как писал. А ты, наверное, даже процессы не остановил и то, что трет твои файлы попрежнему работает. И что ты хочешь тогда?

 

[wwizard]

1. Елси у тебя шаредных хостинг, то звони в тех.поддержку
2. Если ВДС - то по SSH нужно, как писал. А ты, наверное, даже процессы не остановил и то, что трет твои файлы попрежнему работает. И что ты хочешь тогда?

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

 

[etok]

Ага, значит есть куда звонить - продолжай капать на мозг. Ты "тупой" клиент у которого проблема и ты им платишь. Попутно посмотри по сторонам, наверняка есть другие хостеры с беплатным 2-недельным тест-драйвом.

Другая идея состоит в том, что возможно безобразие идет через скрипты сайта. И раз уж отрубить вэб.сервер и посмотреть логи затруднительно, можно попробовать вписать в первую строчку файла wp-config.php следующее: die('Извините, на сайте производятся тех.работы.'); После такого сайт работать перестанет и можно попробовать восстановить файлы и посмотреть что будет. Если ничего, то вероятно заражены скрипты сайта. Скачай его на локальный комп и натрави Каспер (как вариант). Удачи. Мне псинку выгулять надо...

ЗЫ: и попроси хостера проверить твои файлы антивирем, у них обычно есть.

 

[wwizard]

Ага, значит есть куда звонить - продолжай капать на мозг. Ты "тупой" клиент у которого проблема и ты им платишь. Попутно посмотри по сторонам, наверняка есть другие хостеры с беплатным 2-недельным тест-драйвом.

Другая идея состоит в том, что возможно безобразие идет через скрипты сайта. И раз уж отрубить вэб.сервер и посмотреть логи затруднительно, можно попробовать вписать в первую строчку файла wp-config.php следующее: die('Извините, на сайте производятся тех.работы.'); После такого сайт работать перестанет и можно попробовать восстановить файлы и посмотреть что будет. Если ничего, то вероятно заражены скрипты сайта. Скачай его на локальный комп и натрави Каспер (как вариант). Удачи. Мне псинку выгулять надо...

ЗЫ: и попроси хостера проверить твои файлы антивирем, у них обычно есть.

Спасибо, хорошему человеку на Воркзилле - помогли - бо весь мозг седня проелся