evomed, дыры в офисных форматах обычно в скриптах.
PhpOffice их не исполняет, насколько я знаю.
Вот если бы вы headless libreoffice запускали для конвертации, например - тогда риск есть.
Василий Банников, не внутри, а поверх. Внутри может быть чертова туча пересчетов координат и трансформаций, туда влезать - себе дороже. Испорченный в одном месте контекст перекосит весь дальнейший вывод.
А вот завернуть документ как векторную картинку и добавить поверх нее другие элементы - это библиотеки могут.
У ТС проблема не столько с PDF, сколько с конкретной постановкой задачи, имхо.
Не может что прям все идеально работает, а завтра не включится.
Вздор.
В офисе раз - и сдохла мать 2-годичной свежести, еще на гарантии.
Дома раз - и погорел проц у матери на машинке, там еще Core2Duo, можешь прикинуть, сколько он проработал.
Заменил, кстати, на PentiumD, уж что нашлось - и все прочее железо того же возраста (кроме SSD, конечно) таки продолжает работать.
Виктор Таран, фокус в том, что мой тестовый-целевой сервер - за NAT'ом, на него вот так, как у вас, дамп просто не зальешь. В моем сценарии сервера независимы, и требуется доступ только целевого к боевому.
Плюс такого ограничения в том, что при любом зловреде на боевом он не сможет испортить тестовый.
Но у меня сценарий бэкапа, у вас же - разовая акция копирования. Разные юз-кейсы.
Впрочем, если есть шанс, что боевой заражен, и надо срочно спасти с него сайт, отсутствие доступа с него на целевой сервер тоже будет плюсом, а возможно - и требованием.
Виктор Таран, у меня дамп делается и архивируется на боевом сервере за полчаса до синхронизации, копируется вместе с файлами и разворачивается через час после ее начала. Оперативность-то не требуется, так получается проще и надежнее.
rsync с -z сжимает контент на лету и перебрасывает не файликами, а блоками.
FTP уже лет десять не пользуюсь, сравнить не берусь. Просто копирование по SSH, разумеется, будет тормозить и на куче мелких файлов, и просто на папках, содержащих больше тысячи файлов. Впрочем, на последних будет тормозить сама ФС, тут никакие ухищрения не помогут.
P.S. Этой командой каждую ночь синхронизируется сайт на Битриксе на 200К+ файлов только в основной папке. Время, признаюсь, не засекал, в час точно укладывается (вместе с файлами подтягивается дамп на 3 Гб, через час он разворачивается). Но это, конечно, не копирование с нуля, оно будет сильно дольше, тем более, что в офисе интернет на 20 мегабит, и это провинция, а сервер в Питере.
Вопрос не сформулирован. Откуда возьмутся "буковки", "которыми надо заполнять".
Если у ТС есть форма, результаты которой нужно внести в этот шаблон - то никакие pdf-формы и тем более png не имеют к задаче никакого отношения, нужно просто создать pdf из этого шаблона с наложенными на него сверху в нужных местах текстами. В пыхе это делает, например, mPDF, в питоне тоже должны быть аналоги, собирающие pdf из шаблона и верстки поверх него.
Актуальная стабильная версия - 128, вообще-то. Во всяком случае, у меня в Минте.
Может быть, одна из ваших установлена админом в Program Files, а другая - пользователем в его папки?
Виктор Таран, сотни гигов сайта - это все-таки явно не скрипты и дизайн, а загруженные материалы, которые можно подтягивать более постепенно. База и ее дамп - да, особенно если со старого хостинга съезжаешь именно из-за заканчивающегося места. Может быть засадой. Но конкретно эту проблему и решать имеет смысл не консолью, а репликацией, полагаю. Впрочем, сам такой практикой похвастаться не могу.
Пресетами все разнообразие не покроешь, но вариант, что у сайта несколько папок, стоит рассматривать. Хотя если просто в текущем интерфейсе добавить множественное поле - может возникнуть путаница с местом назначения.
Честно говоря, трудно представить ситуацию, когда требуется вот такая "войсковая операция", как переброс сайта с сервера на сервер - и при этом какая-то проблема с наличием rsync. Правда, с редосами дела не имел, каюсь ;)
Битрикс у меня долгие годы каждую ночь синхронизируется с сервером разработки mysqldump + rsync по крону без каких-либо особенностей, просто вся папка. А его перенос на новый сервер - это не проблема с файлами и базой, а проблема с настройками, он капризный, в его базе знаний лежит специальный скрипт проверки того, что по умолчанию его не устраивает.
С исключением из него каких-то каталогов не парюсь, но вот насчет пути копирования - он у меня лежит в пользовательском каталоге + public_html, а рядом лежат нужные ему vendors и storage, из публичного каталога вынесенные. По вашему скрипту получится, что мне для копирования сайта придется указывать пользовательскую папку и исключать из нее все остальное, да еще не забыть файлы-папки с точкой, которые могут быть скрыты в конкретном ФМ.
Антон Антон, не только рабочая, но и весьма распространенная среди зарабатывающих на туристах, не знающих никаких языков (россияне в турляндиях, например).
Dmitry Roo, а вы - про формальную логику?
"Никому не нужны" я опроверг. Спорить ради срача - увольте.
Мне еще завтра разбираться, что за херню придумал Озон с логистикой, надо копить силы и нервы.
Dmitry Roo, например, я сегодня занимался одним из наших служебных сайтов, который позволяет полутора менеджерам управляться с тремя магазинами на маркетплейсах. Тысяча карточек, десяток тысяч заказов в месяц, ведение склада, аналитика и прочие плюшки автоматизации и обработки накапливаемых данных. Никаких команд к работе не привлекалось, все в одно лицо.
И сегодня же внес правки в корпоративный сайт, пятнадцать лет назад заказанный студии, но с тех пор поддерживаемый мной же в том же сугубом одиночестве.
Достаточно примеров?
Niksak, безопасность того, что годами работает на реальных сайтах, обычно подтянута. В отличие от велосипедов.
Про производительность для пет-проекта, который пишется с таким багажом знаний, лучше забыть сразу.
Любой сверхбыстрый движок тут разве что слегка замаскирует ляпы программиста.
Тут нет никакого смысла хвататься за то, что призвано обеспечить производительность хайлоада, стоит использовать самый базовый стек. Вот когда и если на нем, вопреки статистике, будет создано хоть что-нибудь рабочее - тогда... ну, первым делом - переписать на том же базовом стеке то, что получилось очевидно безобразным и нерабочим. А вот где-то пятым-девятым уже пойдут оптимизации небазовыми решениями.
PhpOffice их не исполняет, насколько я знаю.
Вот если бы вы headless libreoffice запускали для конвертации, например - тогда риск есть.