Т.е. на масштабирование растровой графики, если оно нужно, тоже надо закладываться? К примеру, с коэффициентом пикселей 2 и масштабированием 200% нужно учетверять картинку по высоте и ширине?
Была бы только платная (FineReader) было бы еще нормально. У нее срок действия тарифа (я об облачном сервисе) есть. И распознает также паршиво, как tesseract.
Я вариантов не нашел.
У меня была ситуация с заражением сайта. В этих полях были ложные данные (якобы файл создан/изменен очень давно, но известно, что его не было еще вчера).
В обычных ситуациях предложенный метод работает. В спорных - нет.
Не хватает здесь данных по конкретной ОС и FTP серверу.
Такое ощущение, что пользователи FTP и ОС здесь совпадают (тогда на время теста нужно выйти всем, кто авторизован на сервере).
Скорее всего, дело не в PHP, а в лицензионных ограничениях на стороне FTP/Windows.
Как пример, с которым сталкивался сам на Windows 8 Pro при доступе по RDP. Авторизован там мог быть только один пользователь (Pro, всего-лишь, позволяла делать это удаленно). При подключении по RDP, авторизация локально (с клавиатуры) закрывалась. Не удивлюсь, если здесь что-то подобное.
_ umr: судя по коду, у Вас в работе шаблон меню компоненты bitrix:menu. Но в нем не может быть так, что "Но депт левел 3 находится на одном уровне с 1 то есть он не вложен в 1." Думаю, в этом проблема. Нужно свести ситуацию к уже известной и хорошо запрограммированной в любом стандартном шаблоне. К примеру, можно перетасовать этот массив (мне приходилось, это возможно).
И куда у Вас делся уровень 2?
Команды пожалуйста жене (если позворляет) и компьютеру.
Мы определенно живем в разных мирах. В моем мире вопрос автора допускает (и определенно имеет) некоторую неопределенность. Я понятия не имею что лежит в определенных папках, некоторых файлах. Вы, имеете.
Я не знаю каких собак съел автор вопроса, прежде чем его задать. Кто-то задает вопрос через минуту после установки чистой системы, IDE, копипаста примера. А кто-то пробует решить проблему неделю сам (и наставит и понастраивает ....).
В моей практике при возникновении проблемы делается лишь предположение о том, что случилось. Какое-то предположение приведет к положительному исходу. И после еще предстоит доказать, что все работает правильно и не развалится при других условиях. А в данной ситуации даже условия неполны. Отсюда предположение, которое человеку помогло (или нет и он зря пометил мое сообщение как ответ).
Зачем в этой ситуации ваши 5 копеек (и даже рупь, т.к. выглядят вполне убедительно) - понятия не имею.
Fortop: да, несомненно буду. Я читал и другие Ваши комментарии. При всем уважении, Вы делаете не то сейчас. Хотите быть всегда правым - Ваше право хотеть. Правы ли Вы - не уверен (у меня нет полной информации). Не прав ли я? Вы уверены на все 100%. Ну, пусть так и будет.
Fortop: тогда тем более все в порядке, не было смысла (никакого) так писать (я о полной некорректности ответа). В конце концов, задающему вопрос виднее.
Во избежание ненужной переписки: На первом скрине мог запросто сработать include_path. Содержимое /usr/share/php неизвестно, что это за lib/rb.php - тоже. Если там ничего, то учитывается уже путь до включающего скрипта. Если и так ничего не найдено, то рабочий каталог. Где он (в app или dist) тоже неизвестно. Фактически, автору вопроса дали два направления работы - проверить что лежит в /usr/share/php и куда указывает document_root.
Реально автора беспокоит вопрос почему не работает на втором скрине ничего. А для этого действительно нужно сделать эти две проверки.
Fortop: в первую очередь, при определенных условиях, учитывается include_path, во вторую - путь до включающего скрипта и только в третью очередь пресловутый рабочий каталог. В общем, все наоборот.
syxoi: все можно. И дамп БД создать можно не в админке. Просто это нужно знать точно как делать. Админка позволяет не заморачиваться на такие "тонкости".
Я не так давно переносил тяжелый сайт между VDS вообще по rsync. В момент Х на исходном сайте отключил публичку, сделал дамп БД и перенес на целевой. Перенос прошел в десятки раз быстрее.
Tom Nolane: чисто технически, смена регистратора и хостера не требуется.
Владелец сайта имеет полное право попросить (да чего там, потребовать) все пароли и от регистратора, и от хостера. К тому же домен другому регистратору вы не переведете без этого. И на новый хостинг запись в DNS не пропишете тоже.
Насчет недовольства клиента - тема стара как мир. Когда-то он принял этот сайт, но прошло время и теперь второй. Пройдет время - будет и третий. И кто знает что он будет говорить о разработчике второго сайта.
Залить сайт в админке Битрикс можно конечно. Даже так, что Битрикс останется (ядро). Для этого достаточно удалить все, кроме bitrix и upload (с .htaccess еще тоже аккуратно надо поработать). В БД все стандартные таблицы начинаются с b_. Можно чисто технически использовать ее же. Параметры подключения к БД лежат в /bitrix/php_interface/dbconn.php
И будет Вам счастье.
Новый сайт на yii2 никак Битрикса не коснется и если на нем нет тех же папок, конфликта не будет. Чисто технически, могут быть конфликты из-за несовместимых настроек PHP (mbstring). Но Битрикс у вас будет просто лежать, так что разницы нет.
Я бы так и сделал (предварительно создав и скачав полный архив сайта на Битрикс, он делается в админке), т.к. лицензия Битрикс стоит денег. Да и мало ли что будет дальше.
Для случая с ISPManager и альтернативной версии PHP есть инструкция.