-
-
Notifications
You must be signed in to change notification settings - Fork 212
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
& vs & in e_url addon and validation #4054
Comments
@Moc it should be labeled as a question, it wasn't intention marked it as bug |
An HTML validation error caused by e107 sounds like a bug to me. I'll add an issue template for the Update: Issue template for questions is live! |
@Deltik Great. Thank you. |
@Jimmi08: Thanks for the feedback! I've prepended all the issue type labels with " As for the auto-type assignment, the types are fundamentally different, so it makes sense to add them right off the bat. If that's a mistake for whatever reason, a maintainer can change it later. Issue statuses are now prepended with " |
@Jimmi08 Perfect! Thank you. |
- FIX: e107::url() now puts "&" in the query string instead of "&" for compliance with the older, looser definition of ambiguous ampersands in the HTML specification. Fixes: e107inc#4054 - FIX: Typo in comment - FIX: Clear the core/e107/addons/e_url registry (cache) because if a plugin is installed after that cache is initialized, the cache is not updated anymore. The plugin's e_url is therefore not loaded, so SEF URLs won't be generated for that plugin until the cache is regenerated. - NEW: Test for e107inc#4054 - FIX: e_pluginTest::testGetFields() expects the initial condition of the "forum" plugin to be uninstalled.
@Jimmi08: #4067 should fix this issue. Can you try to apply the following patch (same changes as #4067) to see if the issue is fixed?: fix-4054.patch |
What I did (I never used patch file before):
Result:
|
Fixes: #4054 This is a better fix for #4054. HTML code injection can no longer occur in URLs generated by e107::url() thanks to htmlspecialchars(). The previous implementation only addressed: & => & Now, quotation marks and alligator brackets are also escaped, so: <a href=""></html>"></a> is now rendered as: <a href=""></html>"></a>
Bug Description
e_url uses & in URL configuration and it causes validation error with HTML validator extension
How to Reproduce
Steps to reproduce the behavior:
Expected Behavior
No warning error, but W3C validation didn't find this, so maybe enough is just to explain why did you decide to use
&
in httpBuildQuery method instead of&
. ThanksScreenshots
The text was updated successfully, but these errors were encountered: