WordPress WooCommerce

Не понятно что значит соединить?
1. есть Категории
2. может быть таксономия Бренды

- можно сделать виджет их пересечения в сайдбаре
- можно фильтровать категории в брендах
- можно фильтровать бренды в категориях

это все разные задачи. решаются по разному.
решаются программистом через программирование.

Оптимальная сборка для простого магазинов из моего опыта:
1 InSales + МойСклад - если нет в команде программистов и каких то супер сложных задач
2 WooCommerce + Storefront + плагины оплаты и доставки + МойСклад - это если есть деньги на программистов и есть какие то супер сложные задачи требующие программирования

1 вариант может стоить от 10 до 100 тр в год.
2 вариант может стоить от 100 тр до 1 млн руб в год, встречал проекты с бюджетом около 20 млн руб / год. Когда надо было много сложных задач решать.

ВуКомерц это php. Любой php можно заточить под 1-10-100 млн уников в сутки если это будут делать толковые специалисты с головой.
Если денег хватит только на обезьян-программистов без мозгов, то они убьют любую платформу. На любой посещаемости. С любым объемом данных. Птм если денег на хороших специалистов нет то берите InSales. Для начинающих самое то.

Этот плагин учитывает лишь данные которые есть в CommerceML. Надо дебажнуть. Если эти данные там есть, то допилить плагин, если нет то надо пилить свое решение.
Под своим решением понимается доработка 1С в части управления данным в Woo через REST API. В этом случае на стороне Woo ничего не надо ставить. Надо лишь грамотно отправлять данные в REST API. Так делают крупные ecommerce проекты. Данные заливаются в WooCommerce из ERP системы.
Либо менять 1С на МойСклад. Там обратный REST API, управлять потоком можно со стороны Сайта.
Сайт сам забирает данные в МойСклад через плагин https://wordpress.org/plugins/wooms/

Для лендинга лучше использовать конструкторы. Тогда таких вопросов не будет.
Если хочется это делать на базе контента то нужен исходный код сего произведения. Птм что из этого описания вообще не понятно чего тут состряпали и из чего. А телепаты редко тут бывают.

Видимо оба плагина выводят блок через хук the_content. У хуков есть приоритеты. Видимо их поменяли.
Надо поискать опции или фильтры которые позволяют настроить приоритеты.
В крайнем случае можно убирать и подменять хуки.
Без изучения исходного кода можно лишь гадать.

Можно сделать продукты внешними. Есть такая опция. И там укзывать ссылку. Ваще без программирования.

Можно добавить свое метаполе Ссылка и потом через хуки или подмену шаблона ее накинуть на кнопку.

Можно если у вас в команде есть хорошие спецы. Если нет то почти любая платформа обречена на провал.
Если спецов нет или бюджеты малы то лучше брать нечто типа InSales memark.ru/product/insales/gurl
Если есть хорошие спецы (а их в РФ мало) либо бюджеты позволяют их нанять то проблем нет.

В зависимости от задач и трафика будут возникать задачи из мира highload. Интеграция с Memcache/Redis, поисковые данные с Algolia/Elastic.

В Woo есть узкое звено - хранение данных в метаполях. Но если у вас простое описание то это не должно дать проблему. Ну и решается при наличии хороших спецов. В будущих версиях планируют переписывать хранение на обычные таблицы. Это даст чуть больше приросту на голом движке, но не много. Любой highload рано или поздно упирается в узкие горлышки и нужно уметь их расширять через соответствующие технологии. Если есть спецы которые это все знают то все решаемо. Узкие горлышки так или иначе будут на любых платформах.

То что Woo/WP как то плохо подходит под ecommerce это не более чем стереотип который исходит от танцоров которые свою глупость пытаются прикрыть критикой инструмента.

Попробуйте лучше использовать плагин https://ru.wordpress.org/plugins/duplicator/
Больше шансов на успех при малом опыте.
Либо надо дебажить и читать логи. Причин может быть 1000 шт. И телепатией тут сложно решить задачу.

Как одна система мало шансов. Плюс стоит копать в сторону облаков если нет штата своих ИТ спецов. Любой опенсоурс это поддержка которая имеет смысл когда есть 3-4 ИТ-человек в штате.

Если прям хочется приключений и проблем то файлы и документы я бы сделал на Seafile. А базу знаний на WordPress. Для проектов можно Redmine поставить.

Если облака то Mail.ru для бизнеса или Яндекс Тим. Если есть бюджет то Google Apps.

Проекты свои веду в fleep.io - по мне так идеально (это смесь задачника и чата). В сложных случаях подключается Трелло или GitLab (для ИТ разработки).

Еще раз - если в штате нет 3-4 человек которые смогут обеспечить поддержку и внедрение, то брать opensource и self-hosted - это очень рискованно. Прям очень.

Никогда не задумывался над таким вопросом. Всегда использовал базовый цикл WP.

Например если тип поста report то базовый цикл предположим открывается по адресу reports. С этим можно работать.

Если нужно поменять шаблон вывода - делается endpoint типа /reports/mytmp/ и при таком открытии - формриуется другой шаблон вывода.

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

Если не отговорил то копайте в сторону Rewrite Rule API https://truewp.ru/blog/wordpress/wp_rewrite.html
При должном усердии можно все, даже почесать ногой за ухом.

Для начала научитесь выводить что либо через шорткоды. Прежде чем трогать page.php Это шаблон который нужно трогать только если хорошо понимаете что делаете.

Сделайте шорткод add_shortcode. Вставьте его в любую страницу. Сначала выведете что либо типа Hello World. Потом уже учитесь выводить что то типа новостей.

Не понятно как новости связаны с Custom Post Type UI. Обычно для новостей используется типовой раздел записей - блог. Делать новости через CPT UI - это очень странно.

В общем есть подозрение что вы куда то не туда зашли. Вероятно надо откатиться на шаг назад - описать задачу в целом. Потом подобрать более подходящие решения. И только потом искать пути реализации.

Можно достаточно быстро набросать свой плагин на базе Customizer API. Там на каждую опцию 10-20 строчек.
Если оч хочется плагин то попробуйте carbonfields.net
ACF тоже так умеет, но вроде бы через расширение, которое платное. Могу ошибаться.

Можно пилить какие то промокоды. И дописывать логику их автопринятия. Не уверен что это адекватное и оптимальное решение. Но есть шанс что сработает. Нужно пробовать.

В крайнем случае можно написать свою логику скидки. Например можно добавить параметр к продукту типа ?add-cart-sale-15. Кнопку которая этот параметр подставляет.
И если вызвать такой адрес то добавлять в корзину этот продукт с ценой в минус 15%.

Технически это реально. Архитектура Woo позволяет это сделать.
Однако - нужно время на изучение исходной логики и методов ее изменения. Для этого нужен достаточно опытный программист. Новичку с такой задачей не справится.

Первое с чего стоит начать - забыть про MVC микро фреймворки аля Ларавел / Yii и т д.
Если Ларавел это быстрый истребитель, то в сравнении с ними WP - это авианосец. Который может на своем борту нести функциональную нагрузку как 100 Ларавелов.
Отсюда разница в архитектуре - у WP она в разы толще. Ее изучить в разы сложнее.
Поднять сайт на WP может школьник без подготовки. Однако когда встает вопрос каких то разработок - WP в разы сложнее.

И самое главное - в нем реализованы все парадигмы ООП. Самое важное - это принципы компоненто ориентированной разработки. Которые базируются на Event Driven архитектуре. Это то о чем говорил Ален Кей 20 лет назад и назвал это ООП. Но лишь единицы во всем мире поняли что он имел ввиду. И WP это одна из не многих платформ которая сумела эти идеи реализовать правильно. Вся ее разработка базируется на обмене сообщениями - через хуки. А вся логика бьется на компоненты.
Там есть место MVC, но то как там это работает ни капли не похоже на MVC аля Laravel/Yii ...

Потому самое главное забыть про принципы Laravel и прочих модных течений MVC. И погружаться в архитектуру, которая покорила мир. Благо статей навалом. Стартовать можно вообще с пеленок. Но чтобы стать профи в этом деле - нужны годы практики. Хороших спецов в этой теме единицы.

Лучше брать WooCommerce как самое зрелое решение.
Зрелость важнее нормальности скрытия корзины.
Хотя и ее скрыть можно через хуки и правки.

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

Ну вы понарисовали :) У меня товарищ открыл бизнес по доставке еды, 5 минут погуглил, нашел МобиДел, и работает уже пол года, бабло гребет, не вникает.

Что касается задач то стоит посмотреть Трелло. Удобно разбивать дела на доски и удобно общаться.

Если компания древняя и большая то лучше подойдет Директум. Он хорошо соединяет динозавров и современные технологии.
Если молодая и шустрая то тут сложно. Я бы пробовал вордпресс и casepress.org тк это облачный движок n1 в мире и мы на нем работаем в части внутренних процессов.