Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Remove trailing slash from YOURLS_SITE #2244
We should be more forgiving with noobs who cannot RTFM (or maybe don't understand English) and define their
For the record, roughly 4% (!!!) of YOURLS users misconfigure this variable with a trailing slash.
added a commit
May 2, 2017
Dec 3, 2017
After careful consideration...
After careful consideration, I might suggest removing
In the same comment (see number 8 on the List of Benefits), I propose an Admin Diag Page Plugin (Noob Friendly!) Personally, I believe this should in the core for all to use.
Good question @ozh - these would be those in the advanced user category! :)
I'm slightly opposed to using code bloat, on every request, to catch config errors. In the install instructions, I would direct users to a diagnostic tab in the Admin area for checking their install (the final step in the install and a must use step before writing a support issue).
Long Answer - See In-depth Information
"https in shorten URLs"
HTTPS would still require YOURLS_SITE to be defined. I'd consider HTTPS an advanced user configuration. From issues I have read, it seems HTTP is used the majority of the time.
This patch uses YOURLS_SITE only in the formation of short URLs. I changed the "YOURLS installation URL" part of the purpose.
YOURLS_ABSURL becomes the "YOURLS installation URL" This allows backward compatibility for config.php users with YOURLS_ABSURL defined. I changed the "YOURLS installation URL" part of the purpose
Splitting the two purposes of YOURLS_SITE is absolutely required for many features, including multisite. Changing the "formation of short URLs" purpose of YOURLS_SITE would have made a smaller patch. It
I would suggest catching the trailing slash error with a diag page in the admin area, not in bloated active code.
Shop Rules for Config Files.
The shops I worked in had rules for config files.
Defined constants must be defined with either:
Consider defining the parts of YOURLS_SITE
Although this method has three constants instead of one, without Special Syntax, it is much less likely to be wrong. YOURLS could adopt this even now, with cleaner results like an admin protocol override or directory.
It sounds like more options = more complexity. However, most actual errors in config files are caused by Special Syntax.
The exception to the above are things which are copy/paste.
$_SERVER Doesn't Populate Correctly!
As a University Professor, I cannot tell you the hundreds or even thousands of times I have heard this. You can read this all over the Internet, even on php.net! However, it is simply not true!
What people actually mean is Apache, IIS, and Nginx may populate $_SERVER differently.
Expected by who? Did they actually read the Web Server Manuals? Or did they expect it because someone said it somewhere on some website, and it was quoted by a million other people?
Because you are talking about me, and the code I "heavily rely" on, I assume we are talking about $_SERVER being populated as I expect it! I'm not a noob. I expect $_SERVER to be populated with the environmental server vars passed to PHP from the web server. I expect Apache to pass Apache vars, IIS to pass IIS vars and Nginx to pass Nginx vars - as defined in their respective manuals. Likewise, I never expect Apache or Nginx to pass IIS vars!
Of course, different servers may pass different (confusing) vars into PHP. A self-respecting coder would structure his code to not allow this to change the output from one server to another. Here is an example:
$_SERVER is Populated Correctly and I can rely on results expected, based on the server manules.
I will absolutely agree with you that there are some "noobs who cannot RTFM!" I had plenty in my PHP classes who thought all they needed was the PHP manual. They never even consulted the manuals for IIS, Apache, Nginx, etc, to see what was being populated in $_SERVER.
It might interest you to know that Define YOURLS_PROTOCOL was written and thoroughly tested, on different web servers, over a six month period by 18 experienced PHP programmers working together.
The need for this was due to an unreliable WordPress function
Much of this faulty WP function now exist in function
@ozh - I believe we are very near an acceptable solution regarding this patch. It appears this is now just a matter of opinion, so let's work out a way forward.
THEREFORE, we should rewrite the patch to remove as many $_SERVER elements as possible.
My former student offered to post this on the Alumni Newsletter (about 3,000 working programmers who, at one point or another, were my students in University). It would be helpful if you would first approve some ground rules.
Proposed Ground Rules
@ozh - I think we are near an acceptable solution regarding this patch. Based on your comment we should rewrite the patch to remove as many $_SERVER elements as possible. I will have my former students look into this. I would like your approval of these three Instructions I will include for them.
Proposed Rewrite Instructions
To fix the trailing slash issue, I was more on something trivial like trimming YOURLS_SITE whenever it's used, not introducing yet another constant. There are already too much consts in YOURLS. Constants are nearly impossible to test in unit tests, and they cannot be modified by plugins.
I see what you mean about unit tests.
On install, it would help noobs get it right!
This would allow existing error checking code, that runs on every page load, to be removed. The result would be some small performance boost and less error checking code bloat.
Either or both of these would be easy enough to build.
To really help noobs the most, we should move the core config options from config.php to the database. A config page in the admin area could then ask human questions, that could be selected with a mouse click, and be properly stored in a machine-friendly format. Here is a work-in-progress idea for noobs.
By my count, there are 42 Places YOURLS_SITE is used. Meaning 42 places we would need to add the trim function. It also means, when we move YOURLS_SITE to the DB, those 42 trim functions will not be needed and will contribute to Code Bloat!
A Cleaner Trim
I suggest, for noobs, we rename YOURLS_SITE to YOURLS_SITE_URL and keep YOURLS_SITE in config.php TEMPORARILY, as we transition to putting the Config settings in the DB. The Config class could trim YOURLS_SITE to define YOURLS_SITE_URL.
YOURLS_SITE (in config.php) would retire forever when moved into the DB.
Split YOURLS_SITE Patch
I am currently making tests, and final adjustments, on the latest version of the Split YOURLS_SITE Patch #2335. Per @ozh comment above, this version does not heavily rely on
Also, notice the Ten Core Constants this Retires (eliminates), and how they are replaced in the DB (
Constants are a problem for many plugins under developement.