Ответы в темах

Просмотр 15 ответов — с 16 по 30 (всего 105)
  • Автор wildapache

    (@wildapache)

    @efess переписывать конечно я ничего не буду, я имею ввиду стандартный функционал wp, но, считаю что в этом случае легче сделать свою таблицу, с ценами и индексом, чем придумывать с термами какой-то ценовой-конструктор. В теории на выборку с вариантом (своя таблица) нужно будет сделать, всего-то 2 запроса, причем все они с индексом, как в собственной таблице так и в таблице wp. Куда ещё проще я не знаю. В любом случае считаю это лучше чем вариант с термами, красивее и проще. Посмотрим как реализую. Но, за термы, спасибо, что упомянули, я просто не знаю как я упустил это при разработке, наверно потому что я думал что используются только кастомные поля и всё, для этого дела.

    Автор wildapache

    (@wildapache)

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

    На счёт таблицы, думаю быстрей чем своя собственная уже не придумаешь. Термы я ещё не понял как можно использовать для цен, потому что там нет нужно оператора при их выборке, к примеру он есть в мета дополнительных полях. К примеру я могу в мета найти цены с 10,50 по 11,80, а вот с термами такое сделать думаю будет очень затруднительно. Тем более если в постах будет всего пара тройка штук доп.полей к примеру цена, размеры и пару статических данных то нагрузка на выборку из них будет намного меньше если бы там были всё поля которых в раза три-четыре больше.

    Автор wildapache

    (@wildapache)

    Читал, писали что при большом количестве — это типа ноусенс, по этому его там нет изначально.

    Как вариант, предлагали сделать отдельную таблицу и встроить её в работу wp.

    Вы тестируйте только на одной конкретной странице комментариев ?

    @efess на досуге покопался немного, установить woo возможности небыло, но, вот «пощупать» админку с категорией атрибуты я нашёл где. На счёт аттрибутов интересно они придумали со встроенной страницей редактирования, правда меня это запутало, так как не понял сначала как такое в вп стандартными методами из фага сделать. А они оказывается совместили, типа чтобы наглядно было, хотя думаю такой вариант тоже не всегда лего понять, тем более обычному юзеру. Но, вот реального примера что-то не нашёл, где они используют термы для поиска ? Или теги термов ? Пока что понял, то что нужно для поиска и сортировки, нужно знаносить в термы, полностью все доп поля формы, нет смысла туда заносить, к примеру если нет поиска по ним либо они не нужны для отображения в каких-то отдельных от поста вариантов.

    Так, я и говорю за tax, что там не всё можно реализовать как если бы с meta_query. Но, главное теперь понятна разница, я просто не знал что разница есть в скорости, по этому делал проще, тепрь нужно будет половину общих, вынести в термы, а более уникальное оставить в custom fields.

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

    • Ответ изменён 5 месяцев, 1 неделя назад пользователем wildapache.

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

    Тоже ничего не понял, в Woo не знаю, не копался там.

    Тогда что нужно хранить в дополнительных полях тогда ?

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

    Как это выглядит/работает с термами ?

    @efess По тексту примерно понял разницу, а вот на деле нет. Как таксономию можно использовать ввиде дополнительного поля, если это как бы вообще отдельный тип записи можно сказать ? К примеру если я создам свой тип постов (таксу) у которых будут доп поля, тогда что ?

    Тем кто серьёзно подходит к созданию проекта, всё это учитывают.

    Хотя когда смотрел что там у конкурентов, как я уже писал курьёзов попадалось много, конечно были и те кто в тумбы на главной загружал фулл сайзы, но, таких я в счёт не брал. Просто было заметно что вот делали делали потом видать забили или надоело или бюджета не хватило, напихали уже чтобы работало и норм, как говорится чуток не дотянули до «идеала».

    @efess а что там я читал в другом топике за нагрузку на wp_postmeta ?

    Просто у меня в проекте как раз есть несколько дополнитительных полей (custom fields) при размещении поста.

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

    Традиционно в таких случаях советуют кастомные поля, чтобы они в выборке запроса участвовали. Но с ними своя проблема при большой базе постмета. Они при отсутствии индексации в базе данных по значению постмета начинают сильно тормозить запросы к базе.

    Можно тут поподробней ? Посмотрел в БД, там же ищёт по индексу umeta_id ?

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

    GIF — ещё валидный, но, точно не для качественных сайтов.

    Загрузка в основном идёт фото с телефонов и редко пк.

    • Ответ изменён 5 месяцев, 1 неделя назад пользователем wildapache.
    • Ответ изменён 5 месяцев, 1 неделя назад пользователем wildapache.

    У меня в обработке только два основных : jpeg, png

    Остальная вся экзотика футболится

Просмотр 15 ответов — с 16 по 30 (всего 105)