Евгений Вольф

Вообще суть такая : я перекинул сайт с одного хостинга на другой. Вылезло куча ошибок. Некоторые из них я понял - типо поставьте новую версию mysql (изменил файл config.php поставил mysqli , всё отлично, ошибки исчезли).

Решение "в лоб" - на новом хостинге - поставьте версию PHP поменьше, предположительно 5.3, и все ошибки пропадут с большей вероятностью.

Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /home/users/3/375297078078/domains/biceps.napervoy.ru/vqmod/vqmod.php on line 247

С вероятностью 99% - из-за новой версии ПХП, модификатор "е" в регулярках устарел. Удалить его оттуда совсем и/или переписать регулярку соотв. образом

Parse error: syntax error, unexpected 'elseif' (T_ELSEIF), expecting function (T_FUNCTION) in /home/users/3/375297078078/domains/biceps.napervoy.ru/system/database/mysqli.php on line 54

Тут нужно строку с кодом смотреть, что-то на вскидку ничего в голову не приходит.

P.S. Наиболее простое решение проблем(ы) - я озвучил в первом абзаце.

SELECT t.*, @rownum := @rownum + 1 AS rank FROM help_topic t, (SELECT @rownum := 0) r

Источник

P.S. Проверил, работает.

Клац

JS и jquery

Вообще, JS и JQuery, это изначально всё-таки клиентская часть. И хоть они и могут использоваться на сервере, это скорее побочный эффект, чем изначальная задумка. Особенно это касается JQuery.

Из личного опыта, могу посоветовать посмотреть на CodeIgniter, как на первый PHP-фреймворк, среди прочих его достоинств - у него есть документация на русском. Так же, можете посмотреть в моём профиле самые популярные ответы (написанные мной), там есть пару абзацев, относительно выбора PHP-фреймворка.

Ну и, для начала Вам было бы неплохо ознакомиться хотя бы с самыми популярными вариациями языков программирования и выбрать тот, который Вам нравиться больше. В частности рекомендую обратить внимание на PHP, Ruby, Python (и другими, по вкусу), на всех них можно делать "серверную часть".

Допустим, организация ссылок на моем сайте, это вызов документа через явное указание _id (в строке адреса), но мне не хотелось бы что бы человек, всего лишь посмотрев на запрос, мог узнать и получить доступ к документам из этого диапазона _id (авторизация не учитывается).

А не лучше ли тогда, для этих целей использовать не ID, а какое-то отличное от ID значение, генерируемое иным образом, с установкой индекса на оное (для производительности аналогичной той, что будет при использовании ID).

Первое что приходит на ум это назначить свой _id рендомом.

Я не великий спец по монге, но по моему, идея довольно хреновая, в общей сложности.

Второе это делать хэш на _id, тогда смысл _id пропадает, а его мне хотелось бы оставить для связей т.к в нем насколько мне понимается шифруется служебная информация, которая нужна при распределении бд (на перспективу).

Я бы всё-таки оставил ID в покое и не пытался бы сделать "из палки пистолет". Добавьте новое поле в качестве URL'а документа и записывайте туда хэшированный ID, не думаю, что увеличение объёма документа на 20-40 байт данных, может привести к тотальному краху системы (это как минимум, было бы странно). Ну или, если очень хочется и... и того и другого, используйте механизм "обратимого шифрования", т.е. хэширование - это по сути своей "односторонее шифрование" (если выражаться по простому), хэш нельзя превратить обратно в данные. Используйте обратимое шифрование, например такое. Идею с обратимым шифрованием можно развить и придумать какие-то дополнительные ключи или соль, если хочется прям "совсем страшно зашифроваться"...

P.S. Библиотека для шифрования в примере, - первая что попалась в поиске. Судя по тегам, Вы используете Node.JS, уверен для нее подобных библиотек и алгоритмов должно быть в избытке.

которая даже ssl сертификат установить не в состоянии

тоже пользуюсь их услугами, в качестве "мусорки промежуточного звена". Сертификаты и свои собственные и их "родные" ставил сам, через панель управления, проблем вообще нуль. Более того, поддержка у них одна из лучших, что мне приходилось встречать у компаний подобного плана. Но, это всё субъективно конечно.

При выборе хостера, главное, не наткнуться на на какой-нибудь хостинг уровня "сервер на балконе". То есть, выбирайте из крупных компаний, которые давно работают на рынке подобных услуг, тогда вероятность проблем будет гораздо ниже. Например, компании: majordomo, reg.ru, R01, nic.ru, agava.ru, hc.ru и так далее. Многие из них, стояли чуть ли не у истоков по предоставлению подобных услуг.

Для себя же лично, мы решили проблему так: взяли в аренду (а потом просто купили) несколько серверов, и размещаем всё что необходимо там. Очень удобно, и сервер под боком и "свой" и никто не мешает и т.д., до этого пользовались VPS, пока не столкнулись с проблемой того, что некоторые VPS-хостеры умудряются перепродавать 1 сервер по 300 раз, и вместо обещанных SSD-скоростей, дисковая подсистема падала настолько, что даже простое копирование небольшого файла занимало от нескольких минут до "отказ дисковой подсистемы". И задача "срочно пернести куда-то пару сотен VPS'ок", не приносит массу удовольствия :) Но если у Вас мало сайтов/проектов, рекомендую попробовать VPS, например от компании IHC, у них вроде бы всё стабильно, и Вы сможете сами ставить на сервер всё что угодно, и сертификаты и любую версию ПХП и так далее.

Андрей: ну... если верить документации, то там сказано следующее:

font Может принимать значения 1, 2, 3, 4, 5 для встроенных шрифтов в кодировке latin2

Я думаю, можно не объяснять, чем нам это грозит? :))

С учётом

если никаких шрифтов не привязываю?

текст нужно не "кодировать" (изменять ему кодировку), а скорее делать транслитерацию, т.к. кодировка latin2, как мне думается, букв русского алфавита в себе не содержит.

Либо, другой вариант, опять таки, из документации

любому из ваших собственных идентификаторов шрифтов, зарегистрированных с помощью imageloadfont()

- это загружать шрифт, который уже содержит нужные символы соотв.

Или, пользоваться функцией imagettftext...

Так?

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

Как Вы понимаете, сказать с большей вероятностью сложно, но мне картина видится, в таком порядке:
1. У Вас есть сайт на ВП
2. Админка ВП или её признаки, доступны по стандартным адресам
3. Заходит бот, в поисках свежего ВП для взлома (с целью рассылки спама), и пытается брутфорсить Вашу админку, или ещё что-то в таком духе делать
3.1 Возможно ему приглянулась админка не ВП, а какого другого сайта... без подробных логов доступа угадать - как пальцем в... небо!
4. Бот несколько часов генерирует паразитные запросы
5. Каждый такой запрос, создаёт новый файл сессии
6. По умолчанию, файл сессии ПХП хранится 24 часа
7. Файлов сессий стало слишком много

Это наверное, самый вероятный вариант из всех, что мне удалось придумать не имея доступа к серверу и практически никакой информации о происходящем внутри оного...

Возможные полезные действия с Вашей стороны:
а) Можно настроить время жизни сессий в ПХП
б) Не хранить админки в свободном доступе
в) Выбрать и установить какой-то механизм защиты от ботов. Не сложно догадаться, что пользователь не мог запрашивать 500 страниц в минуту...

Можно, таких сервисов как грязи, например вот или вот... и ещё с дюжину как онлайн сервисов, так и офлайн софта найти можно.

Ну и ещё тут можно почитать...