Superset / Subset Site options?

[wolfspyre]

I'd like to have a 'supersite site' which has all documents/assets/etc.... IE: the "behind the firewall / employee version"

and one-or-more 'subset' site(s), which contains non-sensitive/customerfacing/externally focused pages...

In researching patterns for managing multiple sites with hugo, I've seen a few options proposed.... is there a pattern that aligns particularly well for this with geekdocs/geekblog in mind?

[xoxys]

I'm pretty careful to recommend a strategy for this scenario. In theory, it would be possible to structure the content directory like this:

content/
-- private/
---- folder1/
---- folder2/
-- public/
---- folder3/
---- folder4/

This way it would be possible to add e.g. basic auth to example.com/private while keeping example.com/public accessible for everyone. BUT there is a potential to leak sensitive information by the search index that can't be separated for private/public pages or the main navigation that might contain page titles of sensitive themes as well. You might want to take a look at #95 as well, but we really can't guarantee any content leak this way.

My personal recommendation is to create two standalone hugo sites, one for public and one for private usage.

[wolfspyre]

The strategy you describve is the direction I am currently leaning towards.

The use case in mind is mostly to give myself a place to stick things I don't want to be public.

this isn't a PII wall or anything. it's simply 'what docs I'm writing for myself, vs what docs/pages I want to share with the public'

I concur that the words 'public' and 'private' have contextual meanings that vary greatly and it's a good idea to be explicit and clear.

Thinking out loud...
would this be easy?

Define a few spheres of concern ... and make a way to congeal a control surface to address them in an elegant / hierarchical way....

IE create a scope/audience/sensitivity attr in topmatter which could be used to indicate a path to prepend or something?

horrific exemplar pseudo-logic:

IE:
settings.yml

audience:
  - default:
    - prepend: '/'
    - search: true  
  - internal:
    - prepend: '/internal'
    - search: true
  - me:
    - prepend: '/me'
    - search: false

• if the value of the audience keyword is absent or default, there's no change from default behaviors.

• if value of the audience keyword is "internal"
  : this page's path would get prefixed with /internal

• if the value of the audience keyword is "private"
  : this page's path would be prefixed with /internal and the page content would not be excluded from search

• if the value of the audience keyword is "me"
  : this page's path would be prefixed with /internal and the page content would be excluded from searchable content.

OR

would it be "better" to have a '(DONT||ONLY) RENDER ME IF THE SITE FQDN == foo.bar.baz' knob?

¯\_(ツ)_/¯

[xoxys]

To be honest, I don't think this will end up in the theme, sorry. It's a lot of effort and with every change or new feature we would have to take care to not break it.

[wolfspyre]

I truly appreciate the transparency. i’ll chew on the idea some more and see if i can identify a pattern that includes less enduring toil and complication.

it seems like the most common suggestion is to patch themes’ templates to handle a new attr in topmatter to toggle an exclude clause in various searches.

it kinda feels like a behavior that might be easier to consistently encourage with something like a droplist or an exclusory context in hugo…

if flag is on
and attr exists
use attr as a droplist
for any content file that has a tag with the droplist value(s)…. behave differently

i could see the option to just redirect any access to that file’s content with a configurable error page’s content

or masking the file’s existence entirely based on some configurable context…

thanks again for your effort and energy. I appreciate your consideration.