Open meeshoogendoorn opened 2 years ago
Just stumbled upon this as well. We really need this for having custom entities on PWA.
@elkmod Is this possible to build in the next update. if we could extend it from our own custom plugins. That way we could create blog or storeLocator plugins that would be compatible with SwagShopwarePWA plugin. Right now we have to change this with every update.
I would like to contribute to this issue but don't have any clue how to overcome this problem and what would be the best way😌
Hi @meeshoogendoorn - sorry for the late response here. We are hesitant about that change, because the MATCH_MAP
constant is already a workaround in itself.
Do you remember having to select a "Storefront" sales channel type when setting up shopware-pwa? This was, because we use some SEO-URL "magic" that is only defined in the shopware/storefront
package, so we can use pretty URLs following an arbitrary template (such as shop.com/my-category/p-142523/this-is-a-nice-shoe
).
That "magic" is defined in this namespace. You can see that there is one file for each entry in PathResolver::MATCH_MAP
. When there is no "SEO URL" present for the given entity, we can fall back on the "implicit" routing. That routing is defined in the respective controllers (which are also part of the shopware/storefront
package):
Long story short - we would have to replicate all the routes mentioned above within SwagShopwarePwa
to get rid of the dependency on shopware/storefront
. But in the long term, we would like to get rid of that workaround and, hence we don't want to introduce a way to extend it in the first place, which I hope makes more sense now.
The "clean" solution to the problem you are proposing would be to provide custom route classes implementing Shopware\Core\Content\Seo\SeoUrlRoute\SeoUrlRouteInterface
, so that they will be properly resolved in the first step of the path resolving process.
I understand, I will look into the clean solution. What i thought was because of custom entities is only something developers would use we maybe could create a config file in config/packages
named shopware_pwa.yml
where we could define an array with key and regex like the following:
match_map:
- { index: frontend.blog.page, regex: ?^regex_string/$ }
- { index: frontend.news.page, regex: ?^regex_string/$ }
We would create the following configuration treebuilder class:
<?php
declare(strict_types=1);
namespace SwagShopwarePwa\Configuration;
use Symfony\Component\Config\Definition\Builder\ArrayNodeDefinition;
use Symfony\Component\Config\Definition\Builder\TreeBuilder;
use Symfony\Component\Config\Definition\ConfigurationInterface;
class Configuration implements ConfigurationInterface
{
public function getConfigTreeBuilder(): TreeBuilder
{
$treeBuilder = new TreeBuilder('shopware_pwa');
$rootNode = $treeBuilder->getRootNode();
$rootNode
->children()
->arrayNode('match_map')
->arrayPrototype()
->children()
->scalarNode('index')->end()
->scalarNode('regex')->end()
->end()
->end()
->end()
->end();
return $treeBuilder;
}
}
and process it on installation of the swagShopwarePwa plugin 👨💻
and we could use that array as a workaround. That way we could extend the workaround without to much changes. But i will look into the cleaner solution to see if i can get it working 😄 Thanks for the response.
Well while looking into LandingPageSeoUrlRoute
found a very small typo
throw new \InvalidArgumentException('Expected ProductEntity');
Should be
throw new \InvalidArgumentException('Expected LandingPageEntity');
on following line: referenced line
When we create the option to extend the MATCH_MAP we are able to create custom views for the pwa like
frontend.blog.page
for example.Right now hen we want to create a new resourceType for a new kind of page we have to do the following in the SwagShopwarePwa plugin.