Docs enhancements suggestions (WIP list)

[lasomethingsomething]

Some proposed optimizations (WIP issue):

• https://developer.shopware.com/docs/guides/hosting/ needs its own index.md overview info, then create a secondary page for reqts (move existing text there)
• docs on proper feature and unit testing: how to set up (community mtg request)
• Guidance for getting deep into how to debug Redis and rabbitmq, OpenSearch, how Shopware store data there. This is often lead to very deep rabbit holes, practically on p.sh but more generally.
  • Create detailed guide for troubleshooting queue in rabbitmq as well as carts and sessions stored on Redis.
• Describe how full page cache works out of the box and with varnish/ Fastly. Check previous versions and Soner (@shyim) blog for detailed break down of Shopware cache end to end; now have only https://developer.shopware.com/docs/guides/hosting/performance/caches.html. Very important to have a detailed transparent guide on how change works and how plugin developers should operate with it, especially on classic frontend, add hole punches, custom cache tags. How to keep things fast and dynamic.
• Indexing: same, detailed transparent guide and also what happen exactly in the core when advanced search is enabled.
• Besides search itself, how catalog and indexing changes when OpenSearch is involved
  • more info how to fine-tune avdvaced search on OpenSearch config side
• Stoplight and APIs: need much more guidance for products and order operations, concrete examples of complex queries with associations and filters (WIP).
  • "Not straightforward to feel out the sequence for API calls when first approaching Stoplight."
  • What Soner highlights here https://github.com/shopware/shopware-admin-mcp
  • sequence diagrams for basic happy-path workflows outlining which API calls are necessary to get a customer logged in and through a checkout
    look into project admin-api [method] [endpoint]: pre-authenticated curl interface to the Admin API. Make API requests to Shopware Admin API (supports GET, POST, etc.). (existing CLI command, related)
• "Continue with related topics" block in pages almost never has relevant links; probably just have a next sections of current topic would be much more useful
• ../development/tooling/vscode.md page
• Ensure this is handled (setup option, tooling): https://www.jetbrains.com/help/phpstorm/shopware-integration.html
• Better distinguish PaaS offerings: naming, separation
• -diagrams about how to perform fundamental Admin tasks:  "Right now I just go to the Shopware admin, do what I’m trying to do and check which calls were actually made in the network tab"
• Need a production shop before you have this
• doctor command (was debug); check existing docs to update
• Point people to the admin, sign up for account, install their first plugins. 

• Admin page should point people to the store
— shop should know if you’re returning: db or config value
— demo data extension tag (https://store.shopware.com/de/zenit19853952944f/demodaten-fuer-zenit-design-themes.html is free; we could package this up https://github.com/shopware/SwagPlatformDemoData)
• Post-end of Docker install docs, you would use Composer to go through the first run wizard steps. Devs don't like make shell -- messes with terminal config, no aliases or colorings.
• Clarify the Docker + installer wizard flow in docs: The Docker guide explains how to start containers, but it does not clearly map the installer DB fields to the Docker defaults. Docker installation path.
  • The DB credentials are currently only implicit in compose.yaml / Docker config.
  • The installer UI does not explain that the database host should be the Docker service name, not localhost.
  • The dev docs do not spell this out at the database step of the wizard.
  • There is no single place in the installer flow that makes this connection explicit.
• Add a screenshot/image to the installer DB step docs. Show the exact values to enter for a Docker setup.
• Add explicit “What to enter in the installer (Docker setup)” guidance Use the service name, not localhost:
  • Server: database. Document why database is correct instead of localhost.
  • User: root
  • Password: root
  • Database name: shopware (or another name if creating a new DB). Explain that the DB runs as a separate Docker service/container, so the installer must connect via the Docker network service name.
  • Check Create new database
  • Mention the actual OpenSearch service used in Docker setup. We are actually running opensearchproject/opensearch, and that should be reflected in docs. his is currently missing / not clearly stated.