- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Переиграть и победить: как анализировать конкурентов для продвижения сайта
С помощью Ahrefs
Александр Шестаков
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
да, плаг при определённых условиях генерил хедер. И получается - он конфликтовал с уже сгенерённым ВП хедером. Ну т.е. он не должен был его генерить (как я понимаю).
Там скорее не так.. "хедеры" не "конфликтуют"..
либо плагин что-то выводил в браузер (до отправки заголовков движком), либо отправлял заголовки уже после вывода.
Найти место генерации хедера проблем нет (и без логов апача). А вот разобраться как его подружить с ВП..
Чуть выше написал костыльное решение.. можно буферизацию вывода использовать.. скорее всего "прокатит".
Или в .htaccess (тот же костыль, вид сбоку)
---------- Post added 09-03-2013 at 23:54 ----------
Один и тот же плаг на моём локальном серваке работал без ошибок, а на хостинге пошли ошибки.
Тут, ИМХО, проблема чуть глубже.. Если код не оттестирован и "в некоторых ситуациях" выдаёт ошибки пользователю, то сложно гарантировать, что он "в других некоторых ситуациях" не сделает чего-нибудь более критичного (инъекция, доступ к базе/возможность входа/возможность загрузить вредоносный файл)..
Часто репутация "дырявой" CMS связана с использованием дырявых плагинов/модулей/компонентов, написанных сторонними разработчиками...
Генерируемое ВП.
Так ведь изначально-то эта ошибка генерируется PHP.
Если WP коверкает стандартные сообщения об ошибках и удаляет из них информацию, необходимую для анализа и отладки, это уже проблема WP :)
Может быть, если включить дебаг, то он напишет подробности.
Может быть, если включить дебаг, то он напишет подробности.
Или заглянуть в лог ошибок...
Так ведь изначально-то эта ошибка генерируется PHP.
Хм.. возможно. Я как-то не подумал об этом ;)
У ВП ж, как и многих других движков есть свои методы проверки различных данных и соответственно свои сообщения об ошибках. Т.е. совершенно не обязательно они должны попадать в логи сервера.
А эта ошибка как раз похожа на одну их таких (раз не пхп-ное уведомление приходит).
Такая вот у меня логика была ;).
Ок-ок. Как-нить запощу сюда проблемный плаг (надо просто погуглить какой такое выдаёт ;) ).
Часто репутация "дырявой" CMS связана с использованием дырявых плагинов/модулей/компонентов, написанных сторонними разработчиками...
100% :)
В отношении ВП - для того, что бы плаг попал в репозитарий (откуда я их и беру) его предварительно тестирует множество тестеров. Однако при его обновлении уже нет таких обязательных тестов.
Проблема была решена полным бэкапом, возвращением старых файлов и старой бд. Правда после обновления вордпресс и двух плагинов я деактивировал плагин Х и затем снова активировал - опять ту же ошибку выдало. Обновление плагина Х опять ту же ошибку выдаёт. Но странное дело -плагин нормально функционирует и на блоге никаких надписей не выводит. Предыдущие плагины с такой же ошибкой портили мне весь дизайн сайта сообщениями об ошибках и элементарно не работали.
Вообщем, я решил что и так сойдёт.