URL Class #4647

MGatner · 2021-05-05T01:45:53Z

Description
"Stage Three", this PR introduces a companion class to URI: URL. The URL class handles internal URIs (i.e. specific to the project) in the following manner:

A URL is always constructed with a relative path
A URL will always use the App config values from its construction (baseURL, indexPage, forceGlobalSecureRequest)
A URL is immutable, not affected by changes to $_SERVER or services once it has been created

I would like URL to become the definitive source for internal URLs within the framework (e.g. replace the logic in base_url() and current_url(), be used by RedirectResponse, etc) but for now this PR is just introducing the concept and demonstrating the tests. Please be thorough with any reviews, since URLs have been a long pain point (particularly around subfolders).

Note: This PR relies on #4644 and #4646.

Checklist:

lonnieezell · 2021-05-05T03:06:41Z

Haven't looked at the code yet but my initial thought is - this is making the framework more complex and confusing than it needs to be. Can we just start prepping for a bigger release and fix this in the existing URI class? Have two classes so closely related to each other are going to be super confusing for any devs that dig into the inner workings. Or just to those who's IDE starts to suggest both classes for them.

Additionally - isn't the purpose of site_url to be base_url but taking index.php settings into account?

MGatner · 2021-05-05T11:58:06Z

We really need both. It doesn't need to be implemented this way, but we need to be able to do two things:

Build out a URI representing any valid URI for use anywhere one would want a URI
Build "project-specific" URIs, based off the configuration in App and (potentially) any special routes

Currently this is a real problem:

CodeIgniter4/system/HTTP/URI.php

Lines 566 to 584 in 4cc1452

    
           // If hosted in a sub-folder, we will have additional 
        
           // segments that show up prior to the URI path we just 
        
           // grabbed from the request, so add it on if necessary. 
        
           $config   = config(App::class); 
        
           $baseUri  = new self($config->baseURL); 
        
           $basePath = trim($baseUri->getPath(), '/') . '/'; 
        
           $path     = $this->getPath(); 
        
           $trimPath = ltrim($path, '/'); 
        
           if ($basePath !== '/' && strpos($trimPath, $basePath) !== 0) 
        
           { 
        
           	$path = $basePath . $trimPath; 
        
           } 
        
           // force https if needed 
        
           if ($config->forceGlobalSecureRequests) 
        
           { 
        
           	$this->setScheme('https'); 
        
           }

I've tried to mitigate it in #4646 but this "bleeds" point 2 into point 1. URI should not know or care about the framework settings because it makes it impossible to create any URI one might want because the framework settings take over.

Currently we handle "project-specific" URIs with the URL Helper functions (base_url(), site_url(), current_url()) - the problem with these is that the final project has no concept of "what is project" versus "what is path" (e.g. http://example.com/foo/bar - is the baseURL http://example.com/ with "foo/bar" path? or is it http://example.com/foo/ with "bar" path?) so I decided to go with a class solution so we have some way of storing and accessing that info.

I originally had URL as FrameworkURI that was an extension of URI, but there are too many setters in URI that could "violate" an internal URI so I split it out; at that point I realized it was basically a full URL so went with the name, but I'm open to changing it.

MGatner · 2021-05-05T12:56:59Z

isn't the purpose of site_url to be base_url but taking index.php settings into account

Exactly. site_url() amounts to "take base_url(), add App::$indexPage, add any given path, be smart about slashes." URL::to() tries to encompass this behavior but with a little more utility of resolving named and reverse routes.

paulbalandan · 2021-05-05T18:08:45Z

system/HTTP/URL.php

+	 */
+	public static function base()
+	{
+		return static::public('');


Since the class is final, then inheritance is no more possible. So, there's no need to use the static keyword. Instead use self.

Suggested change

return static::public('');

return self::public('');

On the topic, how do you think the class should be scoped? Originally I had a normal class with final static and constructor methods (hence the leftover static references here) but I decided that nobody would go through the hassle of extending for the few allowed methods so made the whole thing final.

paulbalandan · 2021-05-05T18:09:26Z

system/HTTP/URL.php

+		$config            = clone config('App');
+		$config->indexPage = '';
+
+		return new static($uri, $config);


Suggested change

return new static($uri, $config);

return new self($uri, $config);

paulbalandan · 2021-05-05T18:09:49Z

system/HTTP/URL.php

+		$config            = clone config('App');
+		$config->indexPage = '';


Suggested change

$config = clone config('App');

$config->indexPage = '';

$config = clone config('App');

$config->indexPage = '';

paulbalandan · 2021-05-05T18:10:09Z

system/HTTP/URL.php

+			return self::$current;
+		}
+
+		return static::fromRequest(Services::request());


Suggested change

return static::fromRequest(Services::request());

return self::fromRequest(Services::request());

paulbalandan · 2021-05-05T18:10:24Z

system/HTTP/URL.php

+	 */
+	public static function to(string $uri)
+	{
+		return new static(rtrim($uri, '/ '));


Suggested change

return new static(rtrim($uri, '/ '));

return new self(rtrim($uri, '/ '));

paulbalandan · 2021-05-05T18:13:57Z

system/HTTP/URL.php

+	 *
+	 * @param string $uri Additional URI string to include
+	 *
+	 * @return static
