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

from django.conf import settings
from django.conf.urls.static import static
from django.conf.urls.i18n import i18n_patterns
from django.urls import include, path, re_path

from bar.views.bar_view import (
    BarView,
)

urlpatterns = [
    re_path(r"^bar$", BarView.as_view(), name="bar"),
]

# Ensure Arches core urls are superceded by project-level urls
urlpatterns.append(path("", include("arches.urls")))

# Adds URL pattern to serve media files during development
urlpatterns += static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT)

# Only handle i18n routing in active project. This will still handle the routes provided by Arches core and Arches applications,
# but handling i18n routes in multiple places causes application errors.
if settings.ROOT_URLCONF == __name__:
    if settings.SHOW_LANGUAGE_SWITCH is True:
        urlpatterns = i18n_patterns(*urlpatterns)

    urlpatterns.append(path("i18n/", include("django.conf.urls.i18n")))

from django.shortcuts import redirect, render
from arches.app.views.base import BaseManagerView
from django.utils.translation import gettext_lazy as _

class BarView(BaseManagerView):
    def get(self, request, graphid=None, resourceid=None):
        context = self.get_context_data(main_script="views/bar")
        context['page_title'] = _("BAR")
        return render(request, "views/bar.htm", context)

6. Add the application to the project
7. 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'),
         )
   

8. 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: base-root.htm. It can be extended like so:

```
{% extends "base-root.htm" %}

 {% block title %}
 {{ page_title }}
{% endblock title %}

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

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');
    });

```

and vue file:

<template>
    <div class="hello">
        <h1>{{ message }}</h1>
    </div>
</template>

<script setup>
import { ref } from 'vue';

const message = ref('Hello, World!');
</script>

<style scoped>
.hello {
    font-family: Avenir, Helvetica, Arial, sans-serif;
    text-align: center;
    color: #2c3e50;
    margin-top: 60px;
}
</style>

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.. This has been replaced with base-root.htm, which base.htm inherits from

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)!

[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 👍

[jacobtylerwalls]

+1 tested. Left some minor suggestions.

[jacobtylerwalls]

Think we can remove r prefix from project_name.

[chrabyrd]

yeah it looks unnecessary but it's how it's outlined in the docs

[jacobtylerwalls]

no problem to leave this as is, but I'm not seeing re.sub() in the docs?

[chrabyrd]

ah yeah this is because underscores and domains do not play nicely together, and project_name can contain underscores.

Adding a domain with an underscore results in:

Invalid HTTP_HOST header: 'foo_bar.localhost:8000'. The domain name provided is not valid according to RFC 1034/1035.

[jacobtylerwalls]

Yeah yeah, I just mean re.sub() returns a not-raw string anyway, so we're already providing a not-raw string -- in that case, no need to pass raw string args to re.sub() such as "arches", which isn't a regex. No matter.

[jacobtylerwalls]

same

[chrabyrd]

☝️

[jacobtylerwalls]

Thanks for the updates!