Developer forum

Hi Jakob

In 8.8 due next week, you can override the parameters for the search you attach to a paragraph. That makes it possible to override the groupid - but you do not have a group selector, so that is not that user friendly though.

See release notes: http://developer.dynamicweb.com/releases/dynamicweb-8-8.aspx

That said, I think your implementation is a problematic way to go - you could run into a LOT of problems because of this (DC, hard to maintain, wrong links etc.). You could easily have handled the SEO texts using custom fields on the groups. But that is just my opinion...!

I find Jakob's solution the safest one for that case. We are also using that solution because of the impredictibility of the Friendly URL's and lack of control over them.

It's not my preffered method but the other approach (eComNavigation) just did not work.

I am glad and sad at the same time, that someone else ended up using the same approach.

As for the New Index, selecting groups in the Product Catalogue module is mandatory from my point of view. Until then, we will not be able to completely switch from the Old Index event hou the old index is giving us a lot of headaches.

I've yet to see a valid reason for this implementation model. I've seen it before and in my view of oppinion it solves a very tiny problem and introduces an elephant problem.

But if you could explain it to me, it would be nice. If it is the "-1" issue in the URL, it is an enormous amount of time spent on ??

Sometimes control over URL makes a lot of sense for SEO.

We had discussions on this area before. SEO purists are very stubborn when it comes to friendly URL' and link juice and indexed links.

Even with -1,-2 approach, if therule would be consistent, it would have been no issue. But sometimes an url with -1 gets reallocated to another product after a catalogue update.

Moreover, some SEO specialists don't like having a /product/category-name or /store/category-name especially when the structure is complex (2-3 tiers).

For these cases, we had to make a page for each Top Level category and assign categories to it. Sometimes we had to allocate individual groups to these pages in EcomNavigation and/or ProductCatalogue.

I agree it generates a s**t load of work and it's very hard to maintain. But when a customer compares your solution with other solutions that can do it, you have to find a way to solve the issue. 

I hate having to find workarounds. They are hard to maintain and unpredictible from one version to another. Maybe other developers have found other ways to solve it. Or their clients are not that SEO obsessed. Or maybe they've done their custom Navigation provider. So far, it looks like we are at least 2 guys using the same approach :)

Adrian

Yes they are stuborn, but they do not have much to support it and I really do not care much about their feelings - I'm the kind of guy that wants proof before spending a shit load of time and money to make the solution worse - and the site does not even make more money. And it even does not solve the -1 "problem" since product names are still redundant in the URL index if 2 products share the same name. Only way to avoid that is to make the name unique or include the product number in the urls. Personally I would rather spend my dime on better content or going to Fiji- the ROI is much much higher :-).

The problem is that products can be in many languages, in many groups that again is in many shops that is published on many websites on many pages. That gives flexibility but also the need for a shared URL index for the entire product catalog and another one for pages - hence the way it works today. Don't worry - I will introduce a URL index configuration from hell so it can be split into more URL indexes when needed - giving better control over duplicate product name urls. Getting rid of /products is another story though - getting rid of that is even more difficult, because 2 websites could share the hostname, and then we have no chance of finding the right page (and then locate the right website, and then locate the shop and its product URL index). Or if the webisite has 2 catalogs published - it will be even more difficult. But I think it can be done if we make enough assumptions.

I know all the arguments - i heard them in 2005, but world and also Google has changed... Its hard to believe, but they have. Now they even also index ajax based website searches with crap #-based urls nice and neat. Google indexes content (that happens to have a URL) - it does not index URLs that has content.

Ah, always love a good SEO discussion!

Hi Nicolai,

I agree with you in all aspects.

From my perspective, using URL's with parameters will have the same significance if you are relevant. Friendly URL's cannot make you relevant if you are not.

The reality of our clients is that they are facing this "science" that is called SEO and the miracles this science can do if the developers will follow the guidelines. Guidelines look very good for customers because they fell that a an SEO guideline works like a recipe for cold. You take the medicine and the pain is gone. And you are in the first 5 positions on google search for any keyword.

However, we face customers that are coming from different platforms or have seen other platforms or simply they peaked at other platforms.

Of course, there is no such thing as a perfect platform, no matter the cost. But we have to answer to their questions. A badly formated URL is not as bad as a changing URL. And I think this is my most important concern.

I understand the challenges for changing the URL system and I am not insisting on changing that. There will probably came a time when you will change that. But until then, if some of us have managed a way to work with the current system, you can at least let us carry on. And the group selector on ProductCatalogue is a good example on how you can help us without un-helping others. So far I am using the New Index just for search.

If you want another example, the current Discount Matrix, that is way better in many ways than the Sales Discount system does not feature a way to reproduce the ProductField based Discount that was pretty important (at least for us) in the old system, for displaying Old Price/New price. I am sure someone had a pretty documented argument for dropping it. But so far I could not find a way to get the same functionality so I have to keep using the old Sales Discount system.

Don't get me wrong. I just feel that you also need our feedback on how we use the system and I hope this feedback can help you weight your development decisions. 

If I am wrong, please tell me and I will stop.

Thank you,
Adrian

Hi Nicolai

I argree with Adrian, selecting groups in the Product Catalogue module is a necessity for our customers and our Online Marketing department so until then, we will use the "old" index.

BR.

Jakob Westhausen

Hi Nicolai

When will it be possible to use smart searches with the new index?

There will be a replacement using the new index later this year. How and when more exactly I cannot tell yet.

BR Nicolai