We currently host our Drupal site like the following:
//myserver.com/ds/ourDrupalSite/

In addition to hosting the drupal site, we also host shared content on the same server. Currently if a url has a leading /, it is considered to be relative to the root of the Drupal site. I am attaching a patch that adds support for a "server" scheme that would make the url relative to the root of the server.

For example
server:/someurl/ would resolve to //myserver.com/someurl/

Thanks

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

burgdawg created an issue. See original summary.

hedrickbt’s picture

Great patch! This works for me. I can now user server:/images/someimage.png to get to the "root" of the server for content outside of my Drupal site.

hedrickbt’s picture

Status: Active » Needs review
hedrickbt’s picture

Status: Needs review » Reviewed & tested by the community
xjm’s picture

alexpott’s picture

Status: Reviewed & tested by the community » Needs work
Issue tags: +Needs subsystem maintainer review
  1. I can see how this might be used in a situation where Drupal is being used as part of a suite of applications all running of the same server in sub-directories. Doing something like this certainly could make deployment simpler. I'm going to ping this to @dawehner for a sub system maintainer POV.
  2. +++ b/core/lib/Drupal/Component/Utility/UrlHelper.php
    @@ -397,7 +397,9 @@ public static function isValid($url, $absolute = FALSE) {
    +      $/xi", $url) or
    +      //ckb root_server 5.20.2016
    +      (bool) preg_match("/^server:/", $url);
    

    This can be part of the first preg_match above. Also changing UrlHelper means we need new coverage in \Drupal\Tests\Component\Utility\UrlHelperTest - which the patch has - nice.

  3. +++ b/core/lib/Drupal/Core/Url.php
    @@ -306,7 +306,8 @@ public static function fromUri($uri, $options = []) {
    +      //ckb root_server 5.20.2016
    +      if ($uri_parts['scheme'] !== 'base' and $uri_parts['scheme'] !== 'server') {
    

    Changing means we need test coverage in \Drupal\Tests\Core\UrlTest - which the patch has nice.

  4. +++ b/core/lib/Drupal/Core/Utility/UnroutedUrlAssembler.php
    @@ -54,7 +54,8 @@ public function assemble($uri, array $options = [], $collect_bubbleable_metadata
    +    if (parse_url($uri, PHP_URL_SCHEME) === 'base' or parse_url($uri, PHP_URL_SCHEME) === 'server') {
    

    Let's just do one parsing of the URL not twice.

  5. +++ b/core/lib/Drupal/Core/Utility/UnroutedUrlAssembler.php
    @@ -54,7 +54,8 @@ public function assemble($uri, array $options = [], $collect_bubbleable_metadata
           return $this->buildLocalUrl($uri, $options, $collect_bubbleable_metadata);
    
    @@ -107,7 +108,9 @@ protected function buildLocalUrl($uri, array $options = [], $collect_bubbleable_
    -    $uri = substr($uri, 5);
    +    //ckb root_server 5.20.2016
    +    $isServer = parse_url($uri, PHP_URL_SCHEME) === 'server';
    +    $uri = substr($uri, $isServer === TRUE?7:5);
    

    We should consider passing the pass scheme into buildLocalUrl so we don't have to re-parse the URL in order to remove base: or server: later.

  6. +++ b/core/lib/Drupal/Core/Utility/UnroutedUrlAssembler.php
    @@ -120,10 +123,18 @@ protected function buildLocalUrl($uri, array $options = [], $collect_bubbleable_
         // Strip leading slashes from internal paths to prevent them becoming
         // external URLs without protocol. /example.com should not be turned into
         // //example.com.
    -    $uri = ltrim($uri, '/');
    +    //ckb root_server 5.20.2016
    +    if (!$isServer ) {
    +      $uri = ltrim($uri, '/');
    +    }
     
         // Add any subdirectory where Drupal is installed.
         $current_base_path = $request->getBasePath() . '/';
    +    //ckb root_server 5.20.2016
    +    if ($isServer){
    +      // don't include base drupal path
    +      $current_base_path = '';
    +    }
    

    This could be re-written to be more efficient. Ie.

    if ($is_server) {
      $current_base_path = '';
    }
    else {
      // Strip leading slashes from internal paths to prevent them becoming
      // external URLs without protocol. /example.com should not be turned into
      // //example.com.
      $url = ltrim($uri, '/');
      // Add any subdirectory where Drupal is installed.
      $current_base_path = $request->getBasePath() . '/';
    }
    </li>
    
    <li>
    <code>
    +++ b/core/lib/Drupal/Core/Utility/UnroutedUrlAssembler.php
    @@ -120,10 +123,18 @@ protected function buildLocalUrl($uri, array $options = [], $collect_bubbleable_
    +    //ckb root_server 5.20.2016
    

    Not needed in a Drupal patch

  7. +++ b/core/tests/Drupal/Tests/Component/Utility/UrlHelperTest.php
    @@ -585,4 +585,14 @@ public function providerTestExternalIsLocalInvalid() {
    +  /**
    +   * Tests isValid for a server: schema.
    +   * ckb root_server 5.20.2016
    +   * @covers ::isValid
    +   */
    +  public function testValidAbsoluteServerScheme() {
    +    $valid_url = UrlHelper::isValid('server:', TRUE);
    +    $this->assertTrue($valid_url, 'Server is a valid URL.');
    +  }
    

    This should be tested by adding something to providerTestValidAbsoluteData not its own test method. Plus 'server:' should not be valid URL on its own.

hedrickbt’s picture

Hello @alexpott,

This is our exact use case, multiple sites (complete Drupal installs) on the same server under different directories.

Not only does this allow access to different Drupal sites on the same server, it allows simplified access to static content managed outside the Drupal projects due to sharing that same static content between sites. Say for example images, css, js, PDFs, etc that are managed by a git project.

I am new to submitting feature requests to the Drupal project. Is there more you need me to do, at this time, on this ticket for its consideration into the Drupal project?

Thanks,
Brooke

alexpott’s picture

@hedrickbt well there are a number of points in the review in #6 that require the patch to be updated - and doing that will make it easier for reviewers to concentrate on the actual feature request.

dawehner’s picture

@alexpott and myself talked about and agreed that server:/ is a bit of a confusing term. What about using domain:/? This is way more explicit and is part of the URL spec.

burgdawg’s picture

@alexpott, I have made the changes that you requested and here is the new patch. Thank you for taking the time to review the patch.

daffie’s picture

Status: Needs work » Needs review

For the testbot

burgdawg’s picture

@alexpott I didn't include all my changes, here is the correct patch.

Thanks

The last submitted patch, 10: server.patch, failed testing.

Status: Needs review » Needs work

The last submitted patch, 12: server2.patch, failed testing.

daffie’s picture

@burgdawg: Can you create interdiff.txt these make reviewing the changes to patches a lor easier. In your patch you are using tabs instead of spaces. Most editors let you make the setting to change a tab for a number of spaces. For Drupal this number is 2.

burgdawg’s picture

@daffie: It seems that my last two patches did not get all my changes. I am uploading a new patch with the interdiff that you requested.

Thanks

daffie’s picture

Status: Needs work » Needs review

For the testbot.

effulgentsia’s picture

@alexpott already gave a +1 to the concept in #6, so removing the "Needs framework manager review" tag. The implementation still needs to go through the normal patch review process, but it can do so without that tag.

What about using domain:/?

I would suggest host: instead, since that is the terminology for it in https://en.wikipedia.org/wiki/Uniform_Resource_Identifier#Syntax.

alexpott’s picture

Funnily enough @dawehner came up with host: in IRC after posting #9 - I thought he'd posted the update here... definitely +1 to #18.

burgdawg’s picture

Do I need to update the patch to use "host:" #18 or should I wait until the maintainer has reviewed it, in case they want to make additional changes?

Thanks
burgdawg

daffie’s picture

@burgdawg: You can make the changes that alexpott wants. You do not have to wait for the subsystem maintainer for that.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

burgdawg’s picture

Updated to use host. Should be ready for a review.

burgdawg’s picture

FileSize
4.67 KB

Here is the interdiff file

burgdawg’s picture

Just wanted to know if anyone is looking at this?

Thanks

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

smustgrave’s picture

This issue is being reviewed by the kind folks in Slack, #need-reveiw-queue. We are working to keep the size of Needs Review queue [2700+ issues] to around 400 (1 month or less), following Review a patch or merge require as a guide.

Posted in the #contribute slack channel if a core committer could take look.

catch’s picture

Status: Needs review » Needs work
Issue tags: -Needs subsystem maintainer review +Needs issue summary update, +Needs change record

I'm removing the 'needs subsystem maintainer' review tag since as @smustgrave pointed out there isn't one for 'base system' and two framework managers have already reviewed this.

+++ b/core/lib/Drupal/Core/Utility/UnroutedUrlAssembler.php
@@ -107,6 +108,7 @@ protected function buildLocalUrl($uri, array $options = [], $collect_bubbleable_
+    $isServer = $urlScheme === 'host';

This should probably be $is_host now the scheme name has changed - in general any local variables or method parameters should be snake case.

The issue summary no longer matches the patch/discussion in the issue, so could use an update. Also this needs a change record to explain the addition.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.