Adds subdomain handling #11001

[chrabyrd]

Types of changes

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Description of Change

Adds the ability to have subdomains with Arches applications.

To test:

1. Create a project
2. Create an Arches application
3. Ensure the application has a serviceable route
4. Add the application to the project
5. Update the hosts.py file in the the project to include application's urls. eg:

         host_patterns = patterns('',
           host(r'my_arches_app, 'my_arches_app.urls', name='my_arches_app'),
           host(r'my_project, 'my_project.urls', name='my_project'),
         )
   

6. Notice that the route is now accessible via my_arches_app.my_project.domain

These changes remove the concept of a standalone plugin. Instead there is a new template that can extended in projects: standalone-component-base.htm. It can be extended like so:

```
    {% extends "standalone-component-base.htm" %}

    {% block main_content %}
        <div id="foo"></div>
    {% endblock main_content %}
```

with a corresponding .js file, eg:

```
    import BarComponent from '@/BarComponent.vue';
    import createVueApplication from 'arches/arches/app/media/js/utils/create-vue-application';

    createVueApplication(BarComponent).then(vueApp => {
        vueApp.mount('#foo');
    });

```

we are now able to load Vue applications without the Arches chrome, and with optional custom theming via the PrimeVue api.

Issues Solved

Closes #11001 #10998 #10997

Checklist

• I targeted one of these branches:
  • dev/7.6.x (under development): features, bugfixes not covered below
  • dev/7.5.x (main support): regressions, crashing bugs, security issues, major bugs in new features
  • dev/6.2.x (extended support): major security issues, data loss issues
• I added a changelog in arches/releases
• I submitted a PR to arches-docs (if appropriate)
• Unit tests pass locally with my changes
• I added tests that prove my fix is effective or that my feature works
• My test fails on the target branch

Accessibility Checklist

Developer Guide

Topic	Changed	Retested
Color contrast
Form fields
Headings
Links
Keyboard
Responsive Design
HTML validation
Screen reader

Further comments

Documentation: archesproject/arches-docs#425

@robgaston @jacobtylerwalls : This brings up a few interesting discussion points.

1. Do we really need the new template standalone-component-base.htm? There seems to be some cruft in base.htm, and it pulls in javascript.htm which heavy, but still no UI chrome. If we decided to use base.htm instead, we can undo the business with arches_urls being moved into its own template.

2. Regardless of using standalone-component-base.htm or base.htm , there's still the issue of extending the template at the project level. This is fine and good and supported for now, but if we're trying to trend to not have a frontend bundler eat templates then we need to abandon Django template interpolation.

3. There is significant overlap now between plugins and Arches applications. Not in 7.6 of course, but should we consider eventually dropping support for plugins?

[jacobtylerwalls]

I'm looking forward to testing this. One question so I understand: is it mandatory now to serve stuff from an arches application under a subdomain? Or, if the arches application like arches-for-science doesn't use standalone plugins (whatever we call them), will things still work (i.e. disco can still access the arches for science URLs as they are, without manipulating hosts.py, and webpack still builds)?

[jacobtylerwalls]

Some very minor feedback from a code read -- will give a functional test once I get the instructions down (might need to meet with you to make sure I'm doing things right)!

[jacobtylerwalls]

This will break if a user has INSTALLED_APPS as a list, as documented in core django. (Well, it won't break in this very template, but it will break if folks follow the release note recipe and happened to have a list for INSTALLED_APPS.)

I know we're assuming people are starting with the arches createproject template, but this seems like we're further committing to these being tuples, when my hope would be to move in the other direction, see #9942.

[jacobtylerwalls]

Of course, this complexity evaporates if we remove ARCHES_APPLICATIONS per the last comment.

[jacobtylerwalls]

Fine to leave this as is if we think #11009 has legs. I could probably put up a proof of concept before the 7.6 feature freeze.

[jacobtylerwalls]

We could probably tighten up this regex to match on the exact string?

[chrabyrd]

Could you give an example of this? This is just following the documentation for django-hosts https://django-hosts.readthedocs.io/en/latest/

[jacobtylerwalls]

Haven't tested, but since these are regexes, I assume something like changing arches to arches$ so that it doesn't match arches-lingo.

This is just the core arches hosts.py which will never have arches-lingo installed, but I figure people look to these settings as examples to riff on, and it would seem a shame if something only supposed to match arches matched arches-for-science.

[chrabyrd]

no yeah that's fair, will get the change in 👍

[chrabyrd]

undoing this as it prevented navigation to subdomains. Tested with this pattern:

host_patterns = patterns('',
    host(r'foo$', 'foo.urls', name='foo'),
    host(r'foo-bar$', 'bar.urls', name='foo-bar'),
)

the regex anchors prevented navigation to foo-bar.localhost:8000. However removing the anchors allowed proper navigation to the subdomain, even though theoretically foo should have matched first

[chrabyrd]

I'm looking forward to testing this. One question so I understand: is it mandatory now to serve stuff from an arches application under a subdomain? Or, if the arches application like arches-for-science doesn't use standalone plugins (whatever we call them), will things still work (i.e. disco can still access the arches for science URLs as they are, without manipulating hosts.py, and webpack still builds)?

Nope not mandatory 😄 -- should be an either or thing && the documentation has ( perhaps prematurely ) been updated to reflect that https://github.com/archesproject/arches-docs/pull/425/files

Quite possibly it could even be a both thing, where the same resource is served at both a subdomain and a route -- though I haven't tested it 🤔

[chrabyrd]

reverting to draft until #11009 is merged 👍