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

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

«Проблема» решается чтением документации 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/

Я плюсанул, не переживай.

Глянь на дату последнего обновления.

$(doсument).on('ready', function() {
	miniShop2.Message = {
		success: function() {},
		error: function() {},
		info: function() {},
	};
});

Я не имел в виду, что нужно прям свой файл загрузить после, хотя и так можно. Нужно просто перезаписать часть скрипта miniShop2 перед его первым использованием.

Вот и кого слушать?


Вывел и имя, и email.

Копать в авторизацию на фронтенде, ты там видимо не имеешь прав менеджера.