a13x

тут не хватает идентификатора заказа, а так как он у всех уникальный, то его надо передавать в кнопке оплаты.

1. проверку на ссылку изображений лучше сделать регуляркой вместо explode, ибо с ней неважно как будут разбиты ссылки, по запятой, точке запятой или переносу строки 2. не обязятельно использовать CURL, file_get_contents тоже отлично работает, а CURL это отдельная бибилиотека которая может быть не включена. 3. кто мешет проверять на размер после скачки файла через strlen? кода меньше, результат тот же. (скачать нулевой файл или же запросить заголовки - по времени одно и тоже)

$opts = array("http"=>array("method"=>"GET","header"=>"")); $context = stream_context_create($opts); $url = sprintf("https://api.partner.market.yandex.ru/v2/campaigns/%s/orders/%d/status.json?oauth_token=%s&oauth_client_id=%s", $this->settings->market_campaign_id, $id, $this->settings->market_oauth_token, $this->settings->market_oauth_client_id); $response = file_get_contents($url, false, $context); print_r($response); а если так отправить запрос, что отвечает?

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

Можно подключить N1ED на основе tinymce 5. Если интересно пиши, но будет дорого и красиво. https://yadi.sk/i/qZv1L1maOj3tBw https://yadi.sk/i/MZHPmo-7eFOPkA https://yadi.sk/i/M9g3oeQxsHoEnQ

Это именно слабое место т.к. вы не работали с ИМ где очень много категорий с вложениями и вот тогда при заходе в родительскаую запрос будет содержать 100-200 ID дочерних категорий. Не так, а вот так "pc.category.id = 33". Избавившись от 100-200 айди запрос будет в разы быстрее выполняться. А я встречал не один раз, да и на форуме об этом я писал года 2-3 назад т.к. кто-то искал решение.

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

Логично. По сути если не использовать в category_id массив с $category->children, а просто указывать category_id как число, то и группировка не нужна вобще, при условии конечно если в базе данных хранятся связи товара со всеми категориями, а не с последней. Теперь всё понятно. Зря Денис сделал так, связь со всеми категорями избавила бы систему от нагрузки, когда на сайте много категорий\вложенных категорий, например в опенкарт так сделано.

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

Кто знает зачем в классе Products методе get_products() используется переменная $group_by if(!empty($filter['category_id'])) { $category_id_filter = $this->db->placehold('INNER JOIN __products_categories pc ON pc.product_id = p.id AND pc.category_id in(?@)', (array)$filter['category_id']); $group_by = "GROUP BY p.id"; } вместо того чтобы в конце запроса использовать ... GROUP BY p.id ORDER BY $order? По сути в выводе всегда нужно группировать товары по ID. Может в этом есть какой то смысл, но какой не могу понять.

100$

Н надо ничего преобразовывать, оригиналы хранятся в том виде в каком их закачали, ресайзы всегда будут в webp формате. Именно такое задание, какая цена?

А если надо делать ресайз с любых форматов в webp, сколько стоит решение? Мне кажется автору именно так и надо.

Так может проблема в поисковом запросе? Ведь если искать разработчика системы, которую мало кто знает, то вероятности найти его достаточно мала, а если искать специалиста широкого профиля (PHP разработчика) то найти его не проблема, при условии что это не специалист по WP. Но это чисто моё мнение. Думаю тех кто пишет на ларавел проект заинтересует.

Простите что вмешиваюсь, но первая ссылка вот такая должна быть https://hh.ru/search/vacancy?clusters=true&area=1&ored_clusters=true&enable_snippets=true&salary=&text=разработчик+php

Неправильно. Выборка осуществляется в условии WHERE. Я вобще не понимаю зачем там используется таблица brands, т.к. в селекте нигде ничего про бренд не сказано. В товарах итак хранится brand_id, поэтому ничего не мешает вместо b.id использовать p.brand_id, но от нагрузки это врядли спасёт, т.к. вероятная причина в этом (b.id = 63 OR b.id = 13 OR b.id = 34 OR b.id = 14 OR b.id = 25 OR b.id = 35 OR b.id = 40 OR b.id = 165 OR b.id = 201 OR b.id = 15 OR b.id = 211 OR b.id = 19 OR b.id = 23 OR b.id = 17) рекомендую использовать конструкцию ... AND p.brand_id IN (63,13,34,...) вот это буд

Call to undefined method Blog::update_views() Нет у вас такого метода, а вы его вызываете (41 строка)

включите ошибки и копните в сторону логов.

потеря клиента ничего особенного? :)))) сразу видно не ваш бизнес, иначе так бы не говорили.

Что будет, если человек запрашивает смс, а ему её не выслали, или она заблочилась у него (антиспам фильтр) или тупо сервер рассылки перегружен, что будет тогда? Такая практика оооочень часто встречается когда смс не приходит или приходит минут через 5-10.

Странно что вы до сих пор не поняли, что есть люди кто делает хорошо, а есть те кто делает "о, вроде заработало, так и оставлю". Надеюсь найдете исполнителя за 2000р. который вам поможет. Тут как минимум есть куча уточняющих вопросов как это должно работать и будет работать, но я не хочу их задавать т.к. бюджет вы не озвучили.

Какой бюджет на все про всё?

конечно, зачем выбирать дочерние категории запросом когда лучше это переложить на пользователя, верно? :))) бесплатное решение на то и бесплатное чтобы быть плохим!

Всё он прекрасно принимает и всё работает. Читайте мануал по настройке через json+ld

Обновлен список возможных доработок для симплы.