I've been really enjoying the blogdown package to create a personal website. It's very easy to put up easy
Often, I would like to use markdown documents from other (Rstudio) projects for blogposts.
I'd like to hear other peoples workflow for doing so. Do you export the HTML and include it directly in the blogdown output? Or do you recreate the RMarkdown file (and if so where do you put the data?)
That's a great question.
I haven't run into this issue yet, but I think copying rmarkdown files is a nonstarter. There must be one file.The struggle is now to reach it from outside the project, correct?
I've played around with symlinks, which Hugo and blogdown respect. In a course website, I store all the data files in /static/data/ so they're easy to link to (/data/whatever.csv), but I also use subdirectories for pages on the site, so I have a structure like this:
That way, in each Rmd file, I can write code like read_csv("data/whatever.csv") and students don't have to worry about messing with relative paths.
You could do the same thing for Rmd and data files that are completely out of your blogdown site—symlink the Markdown files and data into blogdown to maintain a single file, and the site should compile.
Thanks @andrewheiss, that's an infinitely more elegant solution that I could have derived myself. I hadn't come across symlinks before, so thanks for sharing them! When I get a bit of time, I'll try to put this into practice
I don't mean to answer your question, but I just want to bring this section in the blogdown book to your attention: https://bookdown.org/yihui/blogdown/static-files.html In particular, the second half of this section might be useful to you.
If the Rmd/data live in other projects or directories outside of your website project, I cannot think of a better idea than @andrewheiss' symlinks.
Thanks @yihui. I'd come across the section in my initial search to answer the question but I don't think I full understood it the first time. Thanks for highlighting it. With a second reading, I better understand the implications of the section.
I've been thinking about this question a lot. Instead of symlinks, I really like using git submodules to include project data in my blog posts.
So first I would git submodule add [github_url.com] into a directory within my website's repo. This gives me a version controlled local copy of my project's file that can pull updates from the remote branch on github.
Then within my blog post's .Rmd using knitr::opts_knit$set(root.dir = ...) with a path pointing to my submodule. This allows me to execute code in my .Rmd file as if the code existed within the project repo. This means I don't have copy/paste or modify any of my project's existing code (such as path names).
I also like to use knitr::read_chunk paired with the code decoration ## ---- chunk_name ---- in my project's source code so I can call chunks like
So, I've just realized I may be having something deployed already.
I have this blog post, which is also this repo on Github. It feeds from the same directory: it is located under my /content directory in blogdown, but is also an .Rproj in itself.
I could have had the blogpost text as repo's readme (I'd only have to rename the .rmd file into README.rmd), but I chose not to do so because of external images that weren't rendering in the README.
That's it. I don't do anything else with it. All in one place.
Is that what you've been looking for?
I've seen very strange behavior when putting repos within repos (such as a project repo within your website's repo). That is why I recommend using git submodules.
Also, how is your website generated? Do you use Netlify? Previously I made the mistake of saving /public to Github, when I really wanted Netlify to build it instead, as the blogdown book suggests.
Yes I use Netlify.
I may need to explore the git submodules, but for now I guess I'll stick with the current workflow. If it ain't broke don't fix it, right?
I started using git submodules to make a standalone Rmarkdown project as part of my blogdown site: http://blog.oilgainsanalytics.com/. Thanks to @tmastny tmastny for the eye opener. The solution is great because (1) it allows me using data and R scripts from the main blogdown publication platform; (2) publish the submodule as a standalone project by itself in Zenodo, with its own README.Rmd and other .Rmd notebooks; (3) develop, test, generate HTMLs and PDFs, and run the analysis without adding overhead to blogdown.
The only inconvenient I am facing is that the standalone analysis project (submodule) - living under content/publications/external/volve-reservoir-model-evolution-, is that the .Rmd notebooks in the submodule project are also built when I serve the blogdown site.
I have used @yihui new option options(blogdown.draft.output = TRUE) placing it in .Rprofile, setting the notebooks in the submodule frontmatter with draft:true, but still blogdown is rendering them. I have also used the parameter ignoreFiles which is immune to the purpose as well.
Have any of you found a way to prevent rendering .Rmd files that reside under any of the content subfolders?