Developer forum

Hi Adrian,

You can use the Data Integration to import records into the database directly. That's how we do it on those situations.

Best Regards,

Nuno Aguiar

Hi Nuno,

Thank you for your feedback.

Already did that. That's not the problem. The problem is how DW is redirecting.

Redirect to : /lichidari-de-stoc results in /Files/lichidari-de-stoc

Basically any link having a preceding slash gets /Files in front of it.

I have already tried the value without the preceding slash and I got /Fileslichidari-de-stoc

The problem is not in getting the values in, although I would prefer to have a more suitable way to select the link to redirect to for the manual situations, but rather how the redirects are interpreted.

Does it make sense?

Thankyou,
Adrian

Can you show your data? You cannot add /something to the destination. It has to be Default.aspx?ID=123...

Hi Nicolai,

My data is irrelevant as long as I cannot add /something.

I have +1000 links that need redirecting and I cannot do this conversion from a friendly link to Default.aspx link manually, as you can probably imagine.

My original link has the name of the group as last part of the URL: http://olddomain/some-path/group-name and I have to redirect it to http://newdomain/products/group-name

As you can imagine, I can process this outside of DW and generate an import for the new paths. But since DW does not accept /something I cannot do it.

And this is not the first occurrence of this request. I have seen it before and I don't understand why it is not possible to add it as a feature. I don't see too many cases where a redirect would be targeting a file (see the default behavior of DW when adding /something).

I hope you can consider supporting this in the future.

Thank you,
Adrian

Hi Adrian

Because this feature was not created for this scenario

This is how it works:

'/This-is-not-understood-by-Dynamicweb' redirect to 'Something Dynamicweb understand, i.e. Default.aspx?ID=123&groupid=123"

Dynamicweb can handle that. Anything else, you just add to web.config.

Hi Nicolai, 

I understand that the current feature does not support this scenario.

But you cannot expect regular admin users to start defining redirect rules in IIS.

Having a "Redirects" section in the backend should allow the admin to import the redirects directly. Of course, Default.aspx format is ideal since it is not dependant on changes in the names of pages or products. But sometimes (and apparently very often) there is this need to support exact URL redirects.

I understand that the URL interpretation is the same as for the rest of the core code (I have seen this /Files approach in other modules already) but the redirects require a particular approach to how URLs are handled.

This is how I see it, especially when comparing with other systems. I know the ecosystem of Dynamicweb partners is very tech-savvy and anyone can handle redirects in IIS. But that's not the point. A CMS should give a decent amount of control to the Admin without having to know how to mess with IIS. 

If I am the only one with this view, please disregard it.

Thank you,
Adrian

Hi guys,

I am facing a similar challenge with a list of redirects. They state that /some-page should redirect to /some-other-page. However, they redirect to /Files/some-other-page, similar to Adrian's situation.

I would like this scenario to be supported as well. It seems to be a waste of time to set all the redirects in web.config, when DW offers the possibility to import redirects with the data integration module.

Best regards
Roald

+1

Adrian

Reviving this topic again to see what the latest status is.

I also have a situation where I have tons of old and new URLs with a mapping between them. The new URLs are on the DW platform using the friendly URL, not the internal URL (i.e. ./products/product-name rather than Default.aspx?ID=123?ProductID=456)

What are my options to handle this?

1. The Redirects Module
Doesn't seem like a great candidate as per Nicolai's comments above but I'll happily use it if I can.

2.Use IIS URL Rewrite
With the many links I have, I think I'll quickly hit the max size of web.config. I could increase that but I am a little worried about performance.

3. Handle it myself with code
Store the links in a document or database and handle Dynamicweb.Notifications.Standard.Application.AuthenticateRequest in Dynamicweb. Lookup up the new URL based on the old one and if there's a match, redirect and set Handled to true.

Which of these three will be the best solution? Are there other / better alternatives?

Thanks!

Imar

Also interested in this topic such as Imar :)

Looks like there's no news but we also have a feature request for it too, as well as we likely have a customer that will need it https://doc.dynamicweb.com/forum/feature-requests/feature-requests/advanced-url-redirects

+1

Adrian

These are 2 very long threads - what is the question or suggestion?

If you want to rewrite an already Dynamicweb existing URL to another URL, you are on your own.

If you want to redirect a url that no longer exists in Dynamicweb, url redirect module should be fine.

If you want to do pattern based redirects, I would go for web.config.

We will not spend a lot of energy on adding features that already exists in IIS and that will make it possible to fuck up the solution when used wrong. And it will be...

The question is in this:

>> Which of these three will be the best solution? Are there other / better alternatives?

Like I said, I have friendly URLs on both ends (old and new). The old ones are Sana (yay!), the new ones are ours. Is the Redirect module a good fit for this given that I need to feed it URLS like /bla/something rather than something you can browse to / select in the backend (like Default.aspx?ID=123).

And if it's not, is AuthenticateRequest my hook to do it custom when I cannot use web.config?

Imar

You can redirect /old to /new if that is what you mean? See dump of settings.

See it in action here: http://rapidodemo.dynamicweb-cms.com/old

And yes you can use the module if that is what you need....

Hi Nicolai,

Nuno and I spent some time diagraming some options that we believe would be valuable. You can take them or leave them, but we hope that you at least consider them. We also believe that the suggestions aren't too far-fetched, and that they build on the current implementation.

Non-goal

• Complex pattern based matching. We agree that URL Rewrite is the best tool for that. (however, there may be opportunities over time to incorporate some more powerful options, but it's not the key goal right now.)

 Goals/Requests:

• To support pretty much every static URL option, including mapping to pages, products, files, product groups.
• To conclude some pattern matching too.
• It can continue to use the 404 handler so that processing is post every else, so it won't have a performance hit. We have a suggestion to give some tooltips when an existing mapping clashes with a redirect rule though.
• Have an import tool that will try its best to match the URL with the Default.aspx?ID= pattern. This gives users the ability to start with a spreadsheet to build long lists of redirects based on the friendly URL, without having to figure out the ID for each one. We have end customers building these spreadsheets all the time, and we want to make this easier for them. Then, on import, it will turn it into the Default.aspx?ID= pattern so that the redirect works after future page renames.
• A side benefit of all of this is that another feature can be added so that when products are renamed, their original URL is written to this table to keep historical URLs. This is a big problem today when products are renamed (even for a simple spelling difference) because there is no redirect from the old to the new.
• We show RegEx in the diagrams but that’s option for a next iteration. Even having just the static functionality would address most of the needs.

I've attached a doc that Nuno created (we both brainstormed on it). It has built-in comments, but let us know if you have any questions. It gives some UX suggestions that help explain our thoughts.

Redirects are a big topic for us on nearly every project, so we hope that these ideas are of interest to you too.

Thanks!

Scott