Константин Шевский

Насколько я знаю, ф-ия myNav в waViewHelper косячная и удаляет waRequest::param(), в связи с чем пропадают module, action, plugin. Костыльте, сохраняйте до вызова myNav парамсы и после вызова присваивайте их.

Нежелательно. 

Делайте так:

$(document).on('click', '.my-link', function() {}) 

Пропустят.

getPackageProperty('shipping_params') 

Запретить бандлы с темами, только бандлы плагин+плагин?

Так делайте сурсмапы)

О какой проф. пригодности может идти речь в нашем ремесле? Мы типа такие должны быть челики в смокингах, уметь разговаривать парижским говором и элитным диалектом, и уж, окститесь, не позволять себе обзываться и говорить гадости. Да как бы не так.

Далее, откровенно говоря зашкваривать тех, кто не знает как работают некоторые функции движка это точно так же низко, как и говорить в этом же блин посте про проф. пригодность. Уж простите, мсье гениус, но здесь нет ни одного человека, который сразу же назовет рандомно выбранную часть движка и скажет как она работает и по какому алгоритму. При разработке не лезут туда, что не касается основной задачи.

Как ты там говоришь, "чтоб не облажаться"? "Фууу, не знаешь как функция устроена, гоните его, насмехайтесь над ним"! Вот это и есть вся ваша проф. пригодность.

Мне не стыдно спрашивать у других как работает та или иная функция, мое эго это как-то не портит, да и другие не рофлируют с меня, что вот "ха-ха, придурок, это каждый должен знать!".

Если из человека по дефолту льется дерьмо, то с ним так же и буду обращаться. Я сомневаюсь, что кто-то из разработчиков, кого ты зовешь "не профессионалами", "не вежливыми", посылают нах своих клиентов, блюют с балконов, прикуривают от вечного огня и делают кучу всякой другой дичи, которые считаются почему-то аморальными. Но даже если и так. Профессионализм вычисляется не в этом.

Почему? call нужен, чтоб передать dialog в this

Основной класс плагина должен быть назван так: shopNameofpluginPlugin, файл shopNameofplugin.plugin.php

В корзине не меняя шаблонов - никак.

Массив, в котором нужно указать на какой именно товар в заказе назначена скидка.

array(
    'order_item_id' => array(
        'discount' => 500, // в валюте
        'description' => 'Скидка на товар'
    )
);

Если вернуть в результате только items, то все скидки по товарам будут просуммированы. По сути разницы нет - назначать на каждый товар отдельно скидку или сразу назначить ее на все, поскольку это только в бекенде будет указано, в остальных местах будет сумма скидок.

Он и не должен передаваться, вы должны самостоятельно отлавливать файлы через клиент, а не сервер. Пользователь выбрал файл - сразу грузите его, проверяя форматы и размеры, сохраняете в скрытом поле ссылку, а по нажатию "Сохранить" уже готовую ссылку куда-то в базу пихаете.

Где указано о том что при тестировании мин. число оперативки 512мб?

По умолчанию вообще 128, ну и кому в радость будет использовать программу, которая потребляет столько памяти? Смотрите, что с загрузкой файлов у Вас, делайте проверки на максимальный вес файла и тому подобное.

Это в интересах пользователя. Тупая реклама нет.

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

Антон, а о целесообразности такого правила по-моему не было обсуждения, или нет? Зачем вообще запрещать размещать ссылки на другие свои продукты? Ведь в любом же случае Webasyst также заинтересован в том, чтоб продукты покупались, 20% тоже денюжки какие-то, все в принципе в плюсе - разработчик рекомендует то, что реально может пригодиться совместно с конкретным продуктом (не выставлять подряд все свои разработки в описании), покупатель заинтересован в этом, разработчик за свои 80%, Webasyst - за свои 20%.

Я, честно говоря, не понимаю причин запрещать это, может пересмотрите это требование?

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

Но это здорово, если такое допустят (а почему бы и нет? все соответствует правилам), можно переписать под него плагины некоторые. Даже переписывать толком ничего не надо, кроме приставки у классов.

У всех тем дизайна свой вид пункта табов в frontend_product.menu, универсального решения, к сожалению, нет.

И да, зачем в features_selectable хранить все выбираемые характеристики, а не только те, которые установил для выбора пользователь?

В таком случае да, я думал вам как пользователю это нужно.

Понятия не имею, что делает external. Сами плагины доставки в моем плагине (о господи, плагины плагины плагины) будут скрываться именно по этим настройкам. А отображаться будут только те, которые итак бы отображались (в доставке курьером же можно установить город, для которого будет показываться, соответственно для него в моем плагине не имеет смысла делать свои ограничения, разве что если это несколько городов).

Ну я не знаю, просто обрабатывались плагины доставки, конкретно плагин доставки "Почта России" через

$plugin_model->listPlugins('shipping', array(
	'status' => 1
));

Не получилось вывести.

Скоро выйдет мой плагин "Shipping Tricks", в нем можно будет это сделать ;-)

Я подразумеваю, плохая ли идея хранить свои данные там для каждого магазина заместо базы данных?

Старые удалятся, если в обновлении вообще нет ничего в этой папке?

Налогом?

Да ну, я за такую вещь, но пока там маловато информации, а заполнять самим, без мотивации, да зачем?)

Что мне сразу не понравилось - русские названия. Зачем называть статью о классе shopProductsCollection "Коллекция товаров"? Клево бы их отсортировать, все эти классы, по алфавиту и на нормальном исходном языке. Нам всем сразу ясно по названию класса с чем он работает, ну либо киньте в меня камень, кто будучи программистом не знает английского языка.

А вообще, даже достаточно указывать примеры результатов каких-либо функций некоторых классов, моделей и принимаемые аргументы. Все. И не терять времени на анализирование этого самостоятельно.

Но тем не менее, респект за такую штуку ;-)

Как по мне не хватает информации по шоп-скрипту, там один класс описывается - shopProduct, хотелось бы как минимум видеть там shopOrder и shopCart. Про хуки я молчу, это слишком очевидно.

Так же ничего. При том, если начинать заново установку, то она идет нормально до момента соединения с базой данных.

И проблема конкретно с 5.2, с другими все отлично работает.

Ничего вообще

Окей, но мне это явно не пригодится, нет смысла подстраивать свой плагин под "забагованность" платформы.

Бтв, в одной версии вебасиста это исправили втихаря, то есть нигде не написали, что оно пофикшено. Так что щас проблемы нет

Бамп

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