Василий Наумкин

То он будет повёрнут как надо при генерации превью опцией ar = 1.

Нравится вопросы задавать, взять и попробовать не так интересно?

Да, оригинал на то и оригинал, что никакую обработку не проходит, а просто загружается на сервер.

Сделай еще одно превью большого размера и выводи его вместо оригинала.

На всех серверах обновил PhpMyAdmin до последней версии, перевёл его на PHP 7.0 и принудительный https.

Немного увеличил лимиты на загрузку и время работы, но гарантий что этого хватит — никаких. Работа с большими базами должна проводиться через консоль, там ограничений по времени нет.

Кстати в какой раздел Вы бы разместили подобную тематику? (из доступных)

В Twitter, или в Вконтакте.

Если я буду писать про всё наболевшее в раздел «для разработчиков», из него получится мой личный блог. Можно посмотреть, какие сейчас там заметки — вот такие и нужно туда размещать.

Но для небольших сайтов это было бы спасением.

Наша работа предоставлять хороший сервис, а не спасать забывчивых людей.

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

После отключения сайта мы ждём месяц перед удалением всех резервных копий. А нужно, видимо, не меньше полугода ждать, да?

На данный момент, на минуточку, у нас в БД 9307 удалённых сайтов за всё время работы. И где мы должны хранить от них последние бэкапы и на какие средства?

Может кто-нибудь всё-таки решил проблему с переворачивающимися вертикальными фото?

«Проблема» решается чтением документации phpThumb и добавлением параметр ar = 1 в настройки источника файлов.

ar — это Auto Rotate

Может еще лучше вручную копировать на флешку и привозить домой? Я просто боюсь, что некоторые сайты на 5-10 гигабайт через почту не отправятся.

На мой взгляд, если человек не в курсе, что его сайт не работает пару недель — он ему и не нужен.

Импортируемую базу можно заархивировать в zip, но проблема не в этом.

Проблема в том, что при импорте\экспорте через PhpMyAdmin все операции выполняются через PHP, у которого есть лимит на время работы скриптов — 30 секунд. Больше я сделать не могу, иначе добрые люди начнут грузить гигабайтные дампы и подвешивать работу всего сервера.

Так что, если PhpMyAdmin не справляется, добро пожаловать в консоль — ничего там сложного нет. Ну и обрати внимание, что дампить и восстанавливать можно не только всю базу целиком, но и отдельные таблицы.

Попробую еще на досуге обновить PMA и перевести его на PHP7 — может быстрее будет импортировать и уложится в лимит.

К чему эти минусы? от них приходит понимание кода, или в чем штука?

Люди выражают своё мнение. Можем убрать минусы, они будут ругать тебя в комментах — так будет лучше?
Что минусы, что ругань ни на что толком не влияют, можно просто не обращать внимания.

А требовать к себе особо отношения на основании того, что ты ничего не знаешь — явно не путь к успеху. Почитай лучше небольшую книжку по CSS, я сам по ней учился.

Да, конечно.

Более того, Fenom работает быстрее даже учитывая все оптимизации по вызову модификаторов в pdoTools. Для проверки я доработал старый тест:

<?php
define('MODX_API_MODE', true);
require 'index.php';

$pdo = $modx->getService('pdoTools');
$tpl = '@INLINE <p>[[+val1:jevix]] - [[+val2:jevix]] - [[+val3:jevix]]</p>';
//$tpl = '@INLINE <p>{$val1 | jevix} - {$val2 | jevix} - {$val3 | jevix}</p>';

$output = '';
for ($i = 0; $i <= 1000; $i ++) {
    $array = array(
        'val1' => 'Lorem Ipsum is simply dummy text of the printing and typesetting industry.', 
        'val2' => 'Lorem Ipsum has been the industry`s standard dummy text ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book.',
        'val3' => 'It has survived not only five centuries, but also the leap into electronic typesetting, remaining essentially unchanged.'
    );
    $output .= $pdo->getChunk($tpl, $array);
}

echo '<pre>'; print_r($pdo->getTime()); echo '</pre>';

В чанках вызывается типограф Jevix, по 3 раза * 1000 прогонов чанка.

При обычном вызове, обрабатываемом pdoParser:

0.0003281: Created inline "modChunk" with name "bbdcd0fbc032e01d5a33c9913b2191c5"
4.6010261: Total time
2 097 152: Memory usage

Вызов через Fenom:

0.0002620: Created inline "modChunk" with name "6a8737a398ea1d3a6fa0286bba190054"
0.0039191: Compiled Fenom chunk with name "modchunk/6a8737a398ea1d3a6fa0286bba190054"
0.0020549: Loaded "modSnippet" with name "jevix"
3.4489100: Total time
10 485 760: Memory usage

Один и тот же код, один и тот же модификатор — а разница больше секунды.

Есть такая проблема, что везде одни старые мануалы, и новички начинают с неактуальных вещей.

Мой совет — осваивай pdoTools, он позволяет делать очень много вещей (выводить меню, ресурсы, карту сайта, шаблонизатор и т.д.), а там и остальными разберёшься.

Если я вижу использование сниппета IF — сразу делаю так


Уже давным-давно в Revolution есть нормальный шаблонизатор, решающий такие вопросы быстро и безболезненно. Но нет, мы будем вызывать корявые сниппеты.

MODX же не позволяет вызывать чистый PHP в шаблонах и чанках, так что для вызова любого кода нужен сниппет.

И это правильно, на мой взгляд.

Там немного больше одной строки и функционала.

А логи сервера читать уже совсем немодно?

Это от отменённой версии 2.3.

Ни в miniShop2.2, ни в 2.4 этого поля нет.

Нет, не предусмотрена.

Это решать только администрации сайта.

Непонятно только осталось зачем index=«index»

Это для генерации модели. А из модели создаются таблицы при установке дополнения. Ну и такое обозначение, вроде как, устарело — для индексов там отдельные блоки сейчас.

index="fk" я ни разу не использовал. По идее, это для таблиц InnoDB, которые в MODX по умолчанию тоже пока не используются.

А, я не внимателен.

У таблицы нет primary key, зачем он нужен здесь?

Вот для того и нужен, чтобы было понятно какую именно строку удалить при наличии дубликатов. В твоём случае лучше использовать xPDOSimpleObject.

Ну или можно сделать xPDOObject с первичным ключом, который будет уникален. Например, product_id, option_id и value, но такой ключ будет дольше и медленнее чем простой id.

modx.pro/development/1177-primary-key-xpdoobject/