Максим Федоров

php.net/manual/ru/mysqli-result.fetch-row.php

Вот psr https://github.com/php-fig/fig-standards/blob/mast...

Пункт 4.4

A method declaration looks like the following. Note the placement of parentheses, commas, spaces, and braces:

<?php

namespace Vendor\Package;

class ClassName
{
    public function fooBarBaz($arg1, &$arg2, $arg3 = [])
    {
        // method body
    }
}

Попробуйте следующее:

SELECT
  pd.product_id,
  d.name,
  d.discount_percent,
  d.discount_amount
FROM s_products_discount pd
JOIN s_discounts d ON pd.discount_id = d.id
WHERE 1
AND pd.product_id IN ('41987', '41988', '41989', '41990', '41991', '41992', '41993', '41994') # проверять список ид ДО более сложной проверки
AND d.priority = (
  SELECT MAX(sd.priority)
  FROM s_products_discount spd
  JOIN s_discounts sd on spd.discount_id = sd.id
  WHERE spd.product_id = pd.product_id
  AND sd.visible = 1
  AND sd.date_from <= '2018-05-05'
  AND sd.date_to >= '2018-05-05'
)

У меня только возник вопрос... А зачем везде LEFT JOIN? Разве в текущей задаче нужен именно он, а не просто join? Такое чувство, что left пишется просто по привычке.
В чем состояла оптимизация - вы строите временную таблицу, где к каждому продукту ищется максимальный доступный приоритет. Если представить, что у нас пол миллиона продуктов, вы хотим выбрать только десяток - все равно будет построена таблица по всем продуктам. Я же переместила подзапрос в where, где будет сравниваться приоритет для конкретного продукта. Судя по моим маленьким тестам, даже на малом количестве данных запрос не проигрывает, на большом количестве данных разница должна быть заметнее.

Нет, это делается не таким образом.
Работа с изображениями в php через специальный библиотеки GD/ImageMagick.
Но чтобы не возиться самому с велосипедо строением, лучше уже использовать готовые обертки.
Я советую image.intervention.io, у них отличная документация, широкие возможности по манипуляциям с изображениям, фильтры, кропы, эффекты и тд и тп. В том числе и работа с текстом, поддержка шрифтов.
Если уж хочется именно css/html шаблоны, то есть библиотека https://github.com/niklasvh/html2canvas , но тут уже вам стоит разделить логику и отображение. Мы у себя успешно использовали эту библиотеку для реализации генерации баннеров автоматически под нужный размер, используя адаптивную верстку. Сама библиотека не идеал, на практике бывают всплывают косяки и проблемы, но думаю для вашей задачи более чем подойдет.

Ну как. Записывать в таблицу к юзеру значение, например, после успешной оплаты - оно позволяет ему просматривать этот контент, и в статье проверять, есть ли у текущего юзера это значение или нет.

Вы неправильно настроили панель разработчика. У мобильных телефонов количество физических пикселей больше, чем количество «css-пикселей» в браузере. Разница выражается параметром Device Pixel Ratio (DPR) — это коэффициент умножения, сколько физических пикселей в одном «css-пикселе».

take.ms/v1Ms8

В режиме Responsive у Хрома по-умолчанию DPR=1.0 (у макбука по-умолчанию 2.0, т.к. retina-экран). Вы выставили ширину вьюпорта 540px, но у вашего телефона, скорее всего, DPR = 1.5 и разрешение в браузере соответствует 360px (540 / 1.5 = 360).

Вам надо включить отображение DPR и доработать верстку на малых экранах от 540 до 320px.

знаю одну контору со своим языком и видел куски их кода, но сам с этим не работал - бог миловал.

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

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

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

остальное всё - сплошные минусы. в общем, оправдано это может быть только в очень специфических, полумонопольных условиях.

Нет, GitHub Pages предназначены для хостинга только статичных файлов, исполняемые файлы на сервере не поддерживаются.
Однако определять язык браузера и делать редирект можно и с помощью javascript.

<script>
var userLang = navigator.language || navigator.userLanguage; 
alert ("The language is: " + userLang);
if (userLang === "ru-RU"){
window.location.href="https://google.com/";
}
</script>