Товарищи, вопрос крайне актуален. Создается впечатление, что заинтересованные пользователи не могут отправить свои сообщения. Думаю, данная проблема проявилась не только у нас. Так же установлен плагин безопасности. Может ли он влиять на ситуацию? Сам я думаю, что он ни при чем.
Может ли как-то влиять на ситуацию то, что я исключил JS-файл плагина из обработки плагином Fast Velocity Minify? (Были глюки с AJAX, формы отправлялись с перезагрузкой страницы, поэтому я так настроил).
Если воспринять как причину поиск по подстроке (в черном списке), то могу сказать следующее. Вчера я провел опыт. Ввел произвольные пользовательские данные, как обычно получил ответ сервера, что они расценены как SPAM. Затем стал соотносить части использованных слов с теми строками, что уже есть в черном списке. Получил много совпадений. Я уж не говорю о поиске по подстроке из двух символов. Но ведь это бред. С такой фильтрацией почти все может быть помечено как SPAM... Я все же добился отправки, но далеко не сразу.
Складывается ощущение, что либо я что-то упустил, либо проблема реально есть, но ответ на нее никто не знает. Причем, разработчик плагина на странице поддержки мне так пока и не ответил. А я надеялся получить инфо из первых рук. Подожду еще немного. Может, кто-то что-то скажет )
UPD Вот, что нашел по поводу "ldconfig": "ldconfig creates a necessary link and cache to the shared libraries in ImageMagick." Возможно, просто нужно было указать: вместо sudo ldconfig /usr/local/lib => sudo ldconfig /usr/lib64/php/modules/...
Спасибо за пояснение. А как добавить в таком случае поддержку для webp в GD, когда все уже работает и у меня просто есть *.ini файлы для модулей и главный php.ini?
А потом в анализе покрытия кода увидите, что бОльшая часть кода на CSS не задействована. Не все CSS нужно в один файл объединять. И почему бы не сделать опцию в настройках плагина, какие файлы объединять, а какие - нет и какие подключать в head, а какие в footer.
Дмитрий, спасибо. Ваш ответ помог. В итоге название пакета было в моем случае "php71w-opcache" (v. 7.1.33) для PHP v. 7.1.33. То есть в репозитории "webtatic" не было пакета "php71w-xcache". В итоге установил Zend OPcache.
Про три главные задачи - хороший подход. Задачи, правда, могут быть совсем разными по сложности и при этом все ключевые. И для себя и для внутреннего заказчика мне сложно бывает их оценивать по времени. Одно дело - то, что уже встречалось на практике ранее. Но бывают реально труднооцениваемые таски. А бизнес в лице PM хочет знать ответ на вопрос: "Когда?" Это сложная проблема вообще.
По хаотичности. У меня спонтанность присутствует и борется с желанием упорядочивать процессы )
Гениальная шутка )) Изначально был образ легкости, связанный с тематикой ванили, типо нечто супер-легкое использовании и упрощающее, то есть типо фреймворка. Действительно, остроумно.
Может ли как-то влиять на ситуацию то, что я исключил JS-файл плагина из обработки плагином Fast Velocity Minify? (Были глюки с AJAX, формы отправлялись с перезагрузкой страницы, поэтому я так настроил).
Если воспринять как причину поиск по подстроке (в черном списке), то могу сказать следующее. Вчера я провел опыт. Ввел произвольные пользовательские данные, как обычно получил ответ сервера, что они расценены как SPAM. Затем стал соотносить части использованных слов с теми строками, что уже есть в черном списке. Получил много совпадений. Я уж не говорю о поиске по подстроке из двух символов. Но ведь это бред. С такой фильтрацией почти все может быть помечено как SPAM... Я все же добился отправки, но далеко не сразу.
Складывается ощущение, что либо я что-то упустил, либо проблема реально есть, но ответ на нее никто не знает. Причем, разработчик плагина на странице поддержки мне так пока и не ответил. А я надеялся получить инфо из первых рук. Подожду еще немного. Может, кто-то что-то скажет )