So I have Hugo project A that imports, as a Hugo module, Hugo project B. The repository for B is consists of the standard set of Hugo project files rather than a built Hugo website. So is there a way to instruct A to import B into some intermediate directory, run a command in a shell (the hugo build command, in this case), and then place the contents of that into the module.imports.mounts.target directory in A?
I don’t really get the part where you want to put mount targets from module B into module A. If you have configured module B properly then adding it to module A as dependency will import the mounts. This sounds like you either misunderstand how this works or have “broken configured” your setup. Which is something we can look at with the blackbox or your present some sample code for both modules. (the blackbox comment was sarcastic, sorry… provide the code that you have to achieve what your want to implement).
GoHugo has no hook system where you can add activities after a module is added. What you could do (I would do that this way) is to check within your module on every call (carefull) if specific settings are set. If not, then warnf or errorf to the CLI with either an understandable comment or a link to a website where you describe what to do that something is amiss. There are modules out there that help with this. Don’t want to market my own
If all you want to do is run a script that “properly” installs your module B, then why not adding a simple Bash script to your module A that runs the installation and setup steps? Compatibility issues will arise, of course.
My apologies, I probably explained myself poorly. What I meant was this:
My goal is to get the built contents of Hugo repo B to be inside a certain directory in Hugo repo A, almost as if A and B were in the same project (and the content files of B were just in a subdirectory under /content/ in A) and I just ran
hugo on that single project and built them together:
What would be the best way to achieve this?
Are you aware of Hugo module
If you have a hugo repository (projectB) like: https://github.com/danielfdickinson/wildtechgarden-public
and add a mount in projectA like:
[module] [[module.imports]] path = "github.com/danielfdickinson/wildtechgarden-public" [[module.imports.mounts]] source = "assets" target = "assets" [[module.imports.mounts]] source = 'content' target = 'content' [[module.imports.mounts]] source = 'static' target = 'static'
assuming you have
static in your projectB:
If projectB is just something that should be under
content/projectB you could do:
[module] [[module.imports]] path = "github.com/yourname/projectB" [[module.imports.mounts]] source = '.' target = 'content/projectB'
source = "." takes the root directory of projectB and mounts, in projectA on path pointed to by
For more details on
Thank you for this idea. So for this, how would you handle situations where a file in project A and B have the same name? I attempted to do it this way, but some pages in A and B (common ones like “About” or “Troubleshooting”) shared the same name and I got an error about ambiguous references. Is there a clean way around this?
Well, it depends. If what you really want is something like I have at https://test-umbrella.wildtechgarden.ca/ which is currently just a list of sub-‘sites’ each which is completely independent (and can be deployed independently of each other) then the solution is to use a theme that supports building with a baseURL such as
https://example.com/projectA, or for the other project:
https://example.com/projectB, and (my plan for this site) optionally add a top-level site that points to the others. When you deploy projectA you would deploy projectA to the
/path/to/example.com/projectA and likewise with
projectB to it’s subdirectory.
If on the other hand you need them to be a unified site, then I would suggest that you have a top-level ‘About’, and that you rename Troubleshooting according to what you are troubleshooting (since in a search engine ‘Troubleshooting’ is not very unique, you probably would do well to have names like ‘Troubleshooting DS-1’ and ‘Troubleshooting SSD Model A’ in any event).
For automated renaming, I don’t think there is a way, but if you can show us the error message (and preferably your repos as well: Requesting Help) we might be able to suggest another way of doing the reference in the layouts so that you don’t get the complaint from Hugo.
.Page.TranslationKey should be unique for every page on the site as it is based on the full path.
If you were using this suggestion, you might want to change it to:
[[module.imports.mounts]] source = 'content' target = 'content/projectB'
for projectB. That way the paths will be unique and one won’t replace the other.