search

FriendsOfTYPO3 / frontend_editing

TYPO3 CMS Frontend Editing
https://friendsoftypo3.github.io/frontend_editing/
102 stars 39 forks source link

[BUGFIX] Strengthen request URI check #666

Closed webian closed 1 year ago

webian commented 1 year ago

Crawlers and bots sometimes make request with malformed URI. E.g.:

This is to avoid exception in these cases.

webian commented 1 year ago

Hi @MattiasNilsson, thank you for the merge.

Maybe the log of this repository can be improved if it can be setup so that PR commits are not merged into one but kept separate. By instance, this PR was made of 3 distinct and independent commits. Merging them into one makes it harder to understand the now single commit.

Also, maybe is not necessary to make a release so often. All those [RELEASE] Prepare for version ''X.Y.Z'' commits add noise to the log that is then harder to follow when e.g. searching for the source of a bug.

What do you think about this?

webian commented 1 year ago

This could be used as a Github repository setup reference https://github.com/benjaminkott/bootstrap_package and maybe Benjamin can help to set this one up.

MattiasNilsson commented 1 year ago

@webian Sure I am open for all suggestions if improvement.

mabolek commented 1 year ago

Maybe the log of this repository can be improved if it can be setup so that PR commits are not merged into one but kept separate. By instance, this PR was made of 3 distinct and independent commits. Merging them into one makes it harder to understand the now single commit.

I think squash merging is a good approach to keep the main branch clean. Compare to the TYPO3 Core, which uses a similar approach (though technically not the same). Let's say the ideal is that a PR should only contain one set of related changes. Unrelated changes should go into separate PRs. That way they'll also be easily distinguishable in in the change log. 🙂

webian commented 1 year ago

@mabolek theoretically you are right. The practice is a little different in this case.

The high quality of the code organization of TYPO3 core can't be compared with that of this extension, which has many small bugs, outdated (no more used) code and scarcity of comments.

I say no more because I don't want to offend anybody. Nothing personal.

What matters is that after many years since the beginning of this project (2016 crowdfunding) there is still no frontend editing that can practically be used in production.

I will try, if I find the time, to organize my PR better.

mabolek commented 1 year ago

What matters is that after many years since the beginning of this project (2016 crowdfunding) there is still no frontend editing that can practically be used in production.

I guess it depends on how you define it. Many production sites are using Frontend Editing today, but it's also a question of contribution, specific implementation, and what you ultimately expect from the extension.

I wrote a bit about the TYPO3-specific challenges surrounding Frontend Editing in an article a few years back, and they're still with us today.

Frontend Editing will always also be dependent on how it's implemented and the templates and environments it's implemented in. 🙂

MattiasNilsson commented 1 year ago

@mabolek theoretically you are right. The practice is a little different in this case.

The high quality of the code organization of TYPO3 core can't be compared with that of this extension, which has many small bugs, outdated (no more used) code and scarcity of comments.

I say no more because I don't want to offend anybody. Nothing personal.

What matters is that after many years since the beginning of this project (2016 crowdfunding) there is still no frontend editing that can practically be used in production.

I will try, if I find the time, to organize my PR better.

As with all open source it is about time. This extension have been around since 2016 and with the same code base to keep it compatible throughout all the TYPO3 versions. But this comes with a price complexity and legacy code in a complex topic of the TYPO3 frontend rendering.

Basically what I am saying, we are always open for improvements and are trying our best to keep the code up to date!

webian commented 1 year ago

[...] Many production sites are using Frontend Editing today [...]

I doubt that any editor would prefer it over the Page module. Too many bugs and missing features. Or maybe your editors use it only sporadically to change some text.