search

in2code-de / luxletter

Newsletter system for TYPO3
https://www.in2code.de/agentur/typo3-extensions/luxletter/
24 stars 25 forks source link

Always add type parameter to URL in ParseNewsletterUrlService #107

Closed dahaupt closed 3 years ago

dahaupt commented 3 years ago

When creating a new newsletter, you can either specify the UID of the page or the URL.

  1. Using the page UID, the URL will be created automatically with the correct type parameter.
  2. Using the URL this does not happen automatically, so it is probably assumed that the editor specifies a URL with the type parameter or the extension /newsletter.html (if the routeEnhancer is configured).

What about generally adding the type parameter to a URL in order to improve the workflow? Additionally, the field description could be more detailed as I expected it to work for the default page URL which an editor will most likely copy from the address bar.

Feel free to ping on slack to discuss this!

einpraegsam commented 3 years ago

I think that not adding a type if an absolute URL is given, is correct. Absolute URL is a sign of "this is an external website and this can not handle the typeNum". We we really need is to clarify this situation a bit better when creating newsletters with better labels.

dahaupt commented 3 years ago

I can understand your point, but I can not think of any disadvantage doing this. If an external website could not handle the typeNum, it would just ignore it.

I guess this topic would be obsolete by improving the selection of newsletter pages (as already mentioned in #52). Should I meanwhile create a PR to improve the label of the origin field?

Some background: In our instance, we configured a custom template for the newsletter pages (extending fluidStyledMailContent) so that the preview via the backend has the correct newsletter layout and rendering directly. When requested with the type parameter, only the content is rendered (without header and footer). Therefore, it is important for us to always use the type parameter (would else result in duplicate header / footer). A direct preview via the backend would certainly be interesting for the extension in general, right?

einpraegsam commented 3 years ago

Sorry, but at the moment I don't want to add this change. Why: In TYPO3 unwanted GET parameters can lead to cHash exceptions. Something similar can happen when adding a typenum GET param to every external request. And yes, improving the selection (#52) is still my most wanted way, but I stucked on this. If you want to change the request, you could use a signal in ParseNewsletterUrlService. I will also update the label within the next few days.