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
Comment | File | Size | Author |
---|---|---|---|
#24 | interdiff-2733463-16-23.txt | 4.67 KB | burgdawg |
#23 | host_path.patch | 7.69 KB | burgdawg |
Comments
Comment #2
hedrickbt CreditAttribution: hedrickbt as a volunteer commentedGreat 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.
Comment #3
hedrickbt CreditAttribution: hedrickbt as a volunteer commentedComment #4
hedrickbt CreditAttribution: hedrickbt as a volunteer commentedComment #5
xjmComment #6
alexpottThis 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.
Changing means we need test coverage in \Drupal\Tests\Core\UrlTest - which the patch has nice.
Let's just do one parsing of the URL not twice.
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.
This could be re-written to be more efficient. Ie.
Not needed in a Drupal patch
This should be tested by adding something to
providerTestValidAbsoluteData
not its own test method. Plus 'server:' should not be valid URL on its own.Comment #7
hedrickbt CreditAttribution: hedrickbt as a volunteer commentedHello @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
Comment #8
alexpott@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.
Comment #9
dawehner@alexpott and myself talked about and agreed that
server:/
is a bit of a confusing term. What about usingdomain:/
? This is way more explicit and is part of the URL spec.Comment #10
burgdawg CreditAttribution: burgdawg as a volunteer commented@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.
Comment #11
daffie CreditAttribution: daffie commentedFor the testbot
Comment #12
burgdawg CreditAttribution: burgdawg as a volunteer commented@alexpott I didn't include all my changes, here is the correct patch.
Thanks
Comment #15
daffie CreditAttribution: daffie commented@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.
Comment #16
burgdawg CreditAttribution: burgdawg as a volunteer commented@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
Comment #17
daffie CreditAttribution: daffie commentedFor the testbot.
Comment #18
effulgentsia CreditAttribution: effulgentsia at Acquia commented@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.
I would suggest
host:
instead, since that is the terminology for it in https://en.wikipedia.org/wiki/Uniform_Resource_Identifier#Syntax.Comment #19
alexpottFunnily enough @dawehner came up with
host:
in IRC after posting #9 - I thought he'd posted the update here... definitely +1 to #18.Comment #20
burgdawg CreditAttribution: burgdawg as a volunteer commentedDo 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
Comment #21
daffie CreditAttribution: daffie commented@burgdawg: You can make the changes that alexpott wants. You do not have to wait for the subsystem maintainer for that.
Comment #23
burgdawg CreditAttribution: burgdawg as a volunteer commentedUpdated to use host. Should be ready for a review.
Comment #24
burgdawg CreditAttribution: burgdawg as a volunteer commentedHere is the interdiff file
Comment #25
burgdawg CreditAttribution: burgdawg as a volunteer commentedJust wanted to know if anyone is looking at this?
Thanks
Comment #38
smustgrave CreditAttribution: smustgrave at Mobomo commentedThis 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.
Comment #39
catchI'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.
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.