одно и тоже имя оставлять в папках, соответствующих каждому размеру?Очевидно же что рано или поздно вы перезапишете какую-то фотку, так как такое имя уже будет загружено (типичный пример без имени(1).jpg). И да - для каждого размера своя папка. Кроме того, часто имена фоток бывают на русском языке, с пробелами, в разном регистре, что для веба не очень хорошо. Фото надо переименовывать. Есть 2-3 варианта, которые зависят от условий. Самый простой и очевидный, подходящий для одной фото на объект - имя будет соответствовать идентификатору объекта (товара в вашем случае). Если их больше одной - можно использовать
<picture>
, в котором задайте приоритеты вывода и размерность. Необходимо узнать сколько было показов иллюстрации и сколько было переходов на страницу с иллюстрацией.На техническое описание не похоже... Считайте просмотры страниц с иллюстрациями, все остальное бред и статистический мусор, вы скорее потонете в его объеме, нежели что-то толковое для себя выведете. Если просмотры это увеличение изображения по клику и вам их надо прям вот посчитать - тупо аяксом при клике отсылаете айди иллюстрации на какой-то свой счетчикКонтроллер и зачитывайте "интерес"... А так - фокус, прокрутка- это все пальцем в лужу...
попробовав пописать на ларавел я понял, что он даётся ощутимо тяжелее чем чистый PHP.Это по тому что у вас нет понимания ооп в достаточном объеме. Да и "чистый" пхп нифига не проще, если писать что-то чуть сложнее чем "несложный сайтик на классах", и вы быстро потонете в говнокоде.
Как вариант дергать скрипт кроном через wget. Получится как через вебЕсли не ограничить запросы на этот урл по ип/ключу/порту или как то иначе, рискуете получить дыру для ддос.
Есть вот такая форма.Где там форма то?
Важно, чтобы name было одним и тем же, поскольку это потом надо для jsПривязывать жс к имени поля - редкий идиотизм, для этого есть куча разных идентификаций, включая православные дата атрибуты.
update_post_meta(...Смахивает на вордпресс или подобный божественный код. Указывайте в тегах вордпресс, чтобы народ сразу не пугался такого всратого кода.
Тем не менее, он предвидит рост проекта и понимает, что рано или поздно его умения закончатся и он уже не будет тянуть свою работу.В чем собственно вопрос умений закончится? В чем вы видите недостатки конкретно текущего кода/проекта на данный момент?
Например, когда сервис станет многопосещаемым.Во первых - попахивает преждевременной оптимизацией, а во вторых - есть такая штука как нагрузочное тестирование, ну и вообще - замер производительности системы по ключевым точкам. Вот когда вы увидите в цифрах просадку в конкретном месте, тогда есть смысл думать что конкретно в этом месте менять. И тогда уже - гугл, тостер, СО, доки, статьи по оптимизации конкретных технологий...