Clean

Clean

С нами с 15 января 2013; Место в рейтинге пользователей: #86
Clean
02 октября 2016, 17:15
+2
Вроде ничего не забыл. Пробуйте.
забыл только запушить в магазин дополнение :)
Clean
10 сентября 2016, 23:37
0
соглашусь — так лучше на порядок и штатными методами.
Clean
10 сентября 2016, 23:14
0
Нужно сначала определиться где выполняется скрипт — как я понял в стороннем PHP файле.
Вам нужно в скрипте вытащить ID ресурсов для которых нужно обновить кэш и почистить их из core/cache/

если не принципиально и можно грохнуть все то вот такой например способ может подойти
<?php
define('MODX_API_MODE', true);
require 'index.php';
shell_exec('rm -rf ' . MODX_CORE_PATH . 'cache/');
при условии что сервер разрешает из PHP запуск скриптов.
так же кэш можно удалить средствами самого MODx из его API.
Clean
08 сентября 2016, 22:34
+1
я в обед успел ряд допников купить… а вообще за дополнения Василия скидку просить довольно стыдно… там не миллион цена…
Clean
24 августа 2016, 20:26
0
Хорошо, спасибо, точка зрения ясна :)
Clean
24 августа 2016, 19:17
0
думаю что ты не понял сути.
Давай по порядку.
Что оно делает такого, что минишоп не сможет после небольшой настройки?
оно позволяет внедрить схему WorkFlow всего жизненного цикла заказа.
Это практически главное для чего он нужен.
Тем самым не получится перескочить через обязательные статусы и идти все должно последоватлеьно.
Это исключает и варианты ошибки, и мошенничества со стороны менеджеров магазина.
На сейчас статусы ты можешь в магазине ставить любые, вниз если есть фиксирование, и не можешь уходить с финальных. Тем не менее мне ничто не мешает пропустить какой-либо статус посередине заказа, например с Нового на Отправлен, минуя Ожидает оплаты и Оплачен
Для выставления счета уже давно есть дополнение приличное на modstore.
Это какое? mspreceiptaccount? это не много из другой оперы.
Здесь задача принять заказ с выставленным способом оплаты, но при этом не дать клиенту возможность ее произвести до одобрения менеджером сайта.
Полезно когда могут измениться как состав заказа так и параметры цены.
Также не понятно зачем нужна поддержка office и msProfile
для удобств авторизации из личного кабинета и в теории оплаты с внутреннего счета покупателя.
Тут не уверен т.к в любом случае я всегда могу стандартным API получить контекст сессии пользователя и работать или не работать с ним.
Clean
24 августа 2016, 19:06
0
по поводу имзенения стоимости доставки это доработка исключительно miniShop функционала, возможно есть смысл попросить об этом Василия, т.к по сути нужно просто вынести один input для редактирования в карточке заказа
Clean
24 августа 2016, 02:12
0
Спасибо за отзыв, что должна по Вашему представлять проверка стоимости доставки, по подробнее пожалуйста напишите, спасибо!
Clean
23 августа 2016, 11:19
0
1.Проверен -я имел в виду подтвержден. Т.е по факту клиент подтвердил что заказ ему нужен.
2.Ожидает оплаты — это следующий статус, т.к в теории между этими итерациями может быть что-то еще, например Проверен (Подтвержден) -> Ожидается поставка -> Ожидается оплата -> итп. любые варианты.
Главное забиндить обязательные статусы для системы оплаты и дать возможность гибко их менять, с настраиваемым флоу.

3.Однозначно будет, но в разумных пределах схожих компонентов.
4.По идее, сможет, ведь ему все равно как будет происходить авторизация, и куда производить оплату заказа — все есть из коробки в MiniShop2.
Другой вопрос что функционал оплаты из личного кабинета видимо тогда уже работать не будет, т.к ЛК я планирую делать с использованием Office как раз, ну а по дефолту тогда будет отправляться счет на Email.
Clean
18 июля 2016, 21:57
+1
ну авторизуйте всех гостей под специального анонимного пользователя…
Clean
18 июля 2016, 21:30
-1
а не подойдет рейтинг тикетов? в теории можно придумать формулу и отображать не число проголосовавших, а как раз JPG картинки звездочек…
Clean
07 июля 2016, 19:25
0
php-apc у меня например не завелся с последним php-fpm
Clean
07 июля 2016, 00:55
+1
Не важно какой хостинг, в любом случае алгоритм сводится к следующему если хочешь все безопасно сделать:
1.делаешь дамп всего сайта и базы
2.разворачиваешь его на аналогичном хостинге.
и дальше обновляешь Php до последней версии, старый можно удалить (желательно чтобы не было пересечений, хотя с ним тоже может вполне работать), обновляешь ModX, убираешь кэширование, и радуешься жизни.
у меня так был ресурс на linode работал на 2.2.+ версии на php-fpm 5, обновил все без проблем, только отказался от php-apc и не использую кэширование вовсе. В любом случае все летает и стало лучше.
3.если на бекапном сайте все ОК то не вижу проблем перевести аналогично и действующий.

Удачи.
Clean
07 июля 2016, 00:38
0
похоже на то что только у тебя, у меня все работает, только что проверил.
Clean
06 июля 2016, 14:52
+3
Везде должен быть порядок, а особенно в единственном самом полезном и возможно крупнейшем русскоязычном сообществе MODX. Тем более, тем, кому действительно есть о чем написать — всегда могут попросить Василия дать им такую возможность, даже если и рейтинга мало…
Clean
23 мая 2016, 00:46
0
как я и сказал, проблема была в SQL_MODE стояли no_zero_date и no_zero_in_date. Сейчас убрал — все завелось, Василий спасибо.
SQL_MODE у меня сейчас такой:
sql_mode=STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION

не могу однозначно сказать, повредит ли чему-то отсутствие таких проверок дат, но по идее раньше ведь работало :)
sql версия
mysql-server-5.7 is already the newest version (5.7.12-0ubuntu1).
Clean
23 мая 2016, 00:40
0
посмотрел код, да и вообще мануалы по последнему mysql — лечить эту ошибку с датами такого вида должна системная настройка, сейчас попробую сделать, протестирую и отпишусь, править код думаю не стоит — слишком много где так используется default для timestamp
Clean
22 мая 2016, 23:34
0
Василий, без проблем — могу это сделать сам и выслать, так и сделаю сейчас, просто я думал что у тебя есть все уже готовое под рукой и проверить результат будет проще.
сейчас ошибка с
Could not create table `modx_tickets_files` SQL: CREATE TABLE `modx_tickets_files` (`id` INTEGER unsigned NOT NULL AUTO_INCREMENT, `parent` INT(10) unsigned NOT NULL DEFAULT '0', `class` VARCHAR(100) NULL, `source` INT(10) unsigned NULL DEFAULT '1', `name` VARCHAR(255) NOT NULL, `description` TEXT NULL, `path` VARCHAR(255) NOT NULL, `file` VARCHAR(255) NOT NULL, `type` VARCHAR(50) NULL, `size` INT(10) unsigned NOT NULL DEFAULT '0', `createdon` DATETIME NULL DEFAULT '0000-00-00 00:00:00', `createdby` INT(10) unsigned NOT NULL DEFAULT '0', `url` VARCHAR(255) NOT NULL, `thumb` VARCHAR(255) NOT NULL, `thumbs` TEXT NULL, `deleted` TINYINT(1) NULL DEFAULT '0', `properties` TEXT NULL, `hash` CHAR(40) NULL DEFAULT '', PRIMARY KEY (`id`), INDEX `parent` (`parent`,`class`), INDEX `source` (`source`), INDEX `type` (`type`), INDEX `deleted` (`deleted`), INDEX `hash` (`hash`)) ENGINE=MyISAM ERROR: Array ( [0] => 42000 [1] => 1067 [2] => Invalid default value for 'createdon' )
Clean
22 мая 2016, 22:39
0
к сожалению теперь другая проблема, с другой таблицей:
Could not create table `modx_tickets_stars` SQL: CREATE TABLE `modx_tickets_stars` (`id` INT(10) unsigned NOT NULL DEFAULT '0', `class` VARCHAR(100) NULL DEFAULT 'Ticket', `owner` INT(10) unsigned NOT NULL DEFAULT '0', `createdon` DATETIME NULL, `createdby` INT(10) unsigned NOT NULL DEFAULT '0', PRIMARY KEY (`id`,`createdby`,`class`), INDEX `createdon` (`createdon`), INDEX `owner` (`owner`)) ENGINE=MyISAM ERROR: Array ( [0] => 42000 [1] => 1171 [2] => All parts of a PRIMARY KEY must be NOT NULL; if you need NULL in a key, use UNIQUE instead )
Clean
22 мая 2016, 15:27
0
Собрал пакет с гита, но ошибка осталась
Could not create table `modx_tickets_views` SQL: CREATE TABLE `modx_tickets_views` (`parent` INT(10) unsigned NOT NULL DEFAULT '0', `uid` INT(10) unsigned NOT NULL DEFAULT '0', `guest_key` CHAR(32) NULL DEFAULT '', `timestamp` DATETIME NOT NULL, PRIMARY KEY (`parent`,`uid`,`guest_key`)) ENGINE=MyISAM ERROR: Array ( [0] => 42000 [1] => 1171 [2] => All parts of a PRIMARY KEY must be NOT NULL; if you need NULL in a key, use UNIQUE instead