Сюда пришёл узнать: где искать, где что ещё нужно обновить ?
Узнайте что нельзя лазить в базу напрямую, а нужно использовать АПИ.
https://docs.woocommerce.com/wc-apidocs/
Узнайте что нельзя лазить в базу напрямую
Ну да, мне так много кто говорит, и не только по WordPress, только легче от этого не становится, всё равно так или иначе приходится лазить то туда то сюда … =)
Без приколов, мне попадаются такие задачи, при которых мне иногда просто приходится чуть ли не самому разбираться, вплоть до необходимости написать контроллер базы, который отслеживает те или иные изменения при работе с мордой, ну или просто чёрный ящик.
Ладно, это всё лирика; просто потому что все говорят «нельзя» без объективных причин для запрета, в итоге никто ничего и не знает =)
, только легче от этого не становится, всё равно так или иначе приходится лазить то туда то сюда
Это скорее говорит о том, что Вы не знаете как работать с движком. Не знаете нужных функций/АПИ.
В базу можно полезть что бы напр изменить пароль или мыло, но какие-то более глобальные изменения простыми SQL запросами не сделать — легко поломать сайт (как пример — сменить домен с пом SQL-запросов, коих рецептов валом в интернетах. Для современных сайтов это чревато плохими последствиями.)
просто потому что все говорят «нельзя» без объективных причин для запрета, в итоге никто ничего и не знает =)
Объективные причины — это связи, суррогатные ключи, сериализованные данные и много чего ещё. + Многое зависит от применяемых плагинов и тем.
Если и реально нужна работа с базой то есть спец класс wpdb.
Но в основном это уже для серьёзных задач, которые не решаются с пом. АПИ.
связи, суррогатные ключи, сериализованные данные и много чего ещё. + Многое зависит от применяемых плагинов и тем.
Вот это я и хотел здесь найти: оно же как то работает, а значит имитировать всё необходимое — возможно. И это действительно
Объективные причины
того что в базу лазить таки не «нельзя» а нежелательно, но никто не запрещает. Но речь естественно не о терминологии.
Зато в wp_postmeta значения атрибутов хранятся просто текстом, при том что атрибуты я заносил (через морду) как правила, у которых по идее должны быть связные ID с другими записями и/или таблицами.
оно же как то работает
Конечно работает. В этом деле задействовано много разных функций, которые работают в/из др функций и тд 🙂
а значит имитировать всё необходимое — возможно.
Конечно возможно — использовать АПИ.
Давайте для понимания глубины возможных проблем я Вам нафантазирую 😉
Скажем есть некий плагин который проверяет длину неких данных в ячейке таблицы (да хоть тот же атрибут). Проверив, он записывает/запоминает это значение и далее что-то с ним делает. Не трудно догадаться, что поменяв напрямую значение этих данных Вы поломаете работу плагина.
Да, это чистая моя фантазия, придуманная на ходу поздно вечером. Но нельзя исключить что нечто подобное может быть реальностью.
поменяв напрямую значение этих данных Вы поломаете работу плагина
Наверное именно поэтому нужно понимать, что где и на что делается замена, и/или выполнять трассировку данных из разряда «что было что стало», исследовать всевозможные наборы данных в конкретных случаях. С вами же я общаюсь в целях найти и упростить такую работу =). Плагины же тоже пишут, и не только разработчики WordPress, а значит кто то точно знает всю структуру (опять же, в конкретном заданном случае).
Проверив, он записывает/запоминает это значение и далее что-то с ним делает
Хорошо, куда запоминает/записывает ? Не уж то ли в базу данных ? =)
Ещё мне рассказывали, что файловое хранение каких либо данных плохо воспринимается всерьёз, потому что при мало-мальски сложной структуре такой подход будет показывать тормоза, и вряд ли кто либо будет пользоваться тем, что тормозит; а значит — наши плагины хранят инфу не в каких то там своих файлах, а в базе.
В конце концов, мне всего лишь нужно обновить циферки, и найти что там за «состояния» карточек товара аля в наличии / нет в наличии, что бы имитировать эти данные.
Модератор
Yuri
(@yube)
где находится взаимосвязь отдельных требуемых постов в таблицах wp_posts и wp_postmeta.
Реляция по wp_posts.ID = wp_postmeta.post_id
https://codex.wordpress.org/Database_Description
Реляция по wp_posts.ID = wp_postmeta.post_id
Хорошо, эту связь я знаю … Я наверное вопрос неправильно поставил:
где находится взаимосвязь отдельных требуемых постов в таблицах wp_posts и wp_postmeta
По каким параметрам мне следует понимать, что wp_postmeta.post_id привязан к вариативному товару, и где данные состояния наличия и диапазона цены того товара, к которому привязан этот post_id ?
Формулировка вопроса натолкнула меня на кое что проверить …
Модератор
Yuri
(@yube)
По каким параметрам мне следует понимать, что wp_postmeta.post_id привязан к вариативному товару
post_type = ‘product_variation’
, и где данные состояния наличия
meta_key=’_stock’
meta_key=’_stock_status’
и диапазона цены того товара
Нет диапазона цен. У товара/вариации есть обычная цена
meta_key=’_price’
и цена распродажи
meta_key=’_sale_price’
Я привёл пример запроса обновления цены; там обновляется несколько полей: _regular_price, _price, _stock и _stock_status
Предполагаю, то что Вы хотите сделать выглядит примерно так:
$variation = new WC_Product_Variation( $variation_id );
$variation->set_price();
$variation->set_regular_price();
$variation->set_sale_price();
$variation->set_stock_quantity();
$variation->set_stock_status();
$variation->save();
P.S. Если нужно, гугл подсказывает более расширенные примеры.
post_type = ‘product_variation’
Хорошо, а как знать к какому ID привязана заданная вариация ?
У меня есть post_id заданной вариации, и мне нужно обновить всю информацию не только о цене/количестве/наличии, но и состояние карточки товара, к которой заданная вариация прикреплена.
Нет диапазона цен.
Ссылка на картинку. На скрине выделен диапазон, который не обновляется при обновлении цен вариаций этого товара, так же не обновляется состояние «В наличии», если всем вариациям задать состояние outofstock. Значит где то ещё хранится связанная информация.
Предполагаю, то что Вы хотите сделать выглядит примерно так:
Да, но тогда вопрос: что мне писать в require моего PHP-кода парсера прайса ? =)
$variation = new WC_Product_Variation( $variation_id );
И что за $variation_id ? Который post_id в таблице wp_postmeta ?
P. S. Использование API WordPress затруднительно виду того, что парсер работает на удалённом сервере, и посылает запросы к БД на хост, где расположен сайт; причина — парсер обрабатывает XML-файл размром в 10 мегабайт, в итоге парсинг и формирование запросов по времени занимают примерно 200 секунд, а хостер этого не любит, говорит мол у тебя есть только 60 секунд на выполнение скрипта (поэтому выполнение скрипта было перенесено с хостинга на удалённой VPS).
, и посылает запросы к БД на хост, где расположен сайт;
Вот посылать запросы нужно не «к БД», а на скрипт, работающий с сайтом через АПИ. Этот скрипт может быть как непосредственно «в ВП» (через REST-API), так и отдельный Ваш (хоть через REST-API, хоть подключая ВП (wp-load.php) и используя др АПИ, хоть wpdb ,)
https://developer.wordpress.org/rest-api/
https://docs.woocommerce.com/document/woocommerce-rest-api/
..Ну это если Вы хотите работать правильно и не иметь (/не создать клиенту) приключений на седалище.
Да, но тогда вопрос: что мне писать в require моего PHP-кода парсера прайса ? =)
wp-load.php подключить, как Вам уже посоветовал SeVlad.
И что за $variation_id ? Который post_id в таблице wp_postmeta ?
ID, который в wp_posts.
в итоге парсинг и формирование запросов по времени занимают примерно 200 секунд, а хостер этого не любит, говорит мол у тебя есть только 60 секунд на выполнение скрипта
Может стоит поменять хостинг? У меня на текущем шареде разрешают выполнять CRON-скрипты до 10 часов.
P.S. Чтобы сделать в обход API Вам нужно просто изучить как WooCommerce обновляет цену для «товара-оболочки» и повторить. Скорее всего где-то кэшируется. Возможно, в transients.
