I've followed the advice at https://bookdown.org/yihui/blogdown/static-files.html by adding a .r file with blogdown::build_dir('static') - and by creating a ./static/post directory - what am I missing?
I also searched through rbind.io blogdown structures, but cannot figure out how to connect rendered graphic outputs to static/post/post-date; not how to automatically redirect outputs to that folder instead of public.
Thanks for the help.
I think I found the problem
The .gitignore file in your static directory prevents git to stage images generated by blogdown, delete it.
Related
I have two projects in R. I've moved an .Rmd document from project 1 to project 2.
When I used the .Rmd file which I had moved to project 2 to try and read in some data I get the following error message:
cannot open file '"mydata.csv"': No such file or directoryError in file(file, "rt") : cannot open the connection.
This kind of error usually suggests to me it's a working directory issue, however when I run getwd() in the command line it's the correct working directory that is listed and points to where the csv is stored. I've also run getwd() within the rmd doc and again the wd is correct.
Does anyone else have this experience of moving one .Rmd file to another project and then it not working in the new project?
The code in the .Rmd file that I am trying to run is:
Data <- read.csv("mydata.csv", stringsAsFactors = T) and the data is definitely within the project and has the correct title, is a csv etc.
Has anyone else seen this issue when moving an RMarkdown document into another project before?
Thanks
This may not be the answer, but rmarkdown and knitr intentionally don't respect setwd(): the code in each block is run from the directory holding the .rmd file. So, if you've moved your .rmd file but are then using setwd() to change to the directory holding the data, that does not persist across code chunks.
If this is the issue, then one solution is to use the knitr options to set the root.dir to the data location:
opts_knit$set(root.dir = '/path/to/the/data')
See here.
Maybe not relevant but it seems to be the most likely explanation for what's happening here:
The project shouldn't really interfere with your code here. When opening the project it will set your working directory to the root location of the project. However, this shouldn't matter in this case since RMarkdown files automatically set the working directory to the location where the RMarkdown file is saved. You can see this when running getwd() once in the Console and once from the RMarkdown file via run current chunk.
The behavior is the same when the file is knitted. So except in the case when "mydata.csv" is in the same directory as the RMarkdown file, the code above won't work.
There are two workarounds: you can use relative or absolute paths to navigate to your data file. In a project I prefer relative paths. Let's say the rmd file is in a folder called "scripts" and your data file is in a folder called "data" and both are in the same project folder. Then this should work:
Data <- read.csv("../data/mydata.csv", stringsAsFactors = TRUE)
The other option, which I do not recommend, is to set the working diretory in the rmd file via:
opts_knit$set(root.dir = '../data/')
The reason why I wouldn't do that is because the working direcotry is only changed when knitting the document but using the rmd file interactivly, you have a different working directory (the location of the rmd file)
This is a great application of the here package for dealing with these types of issues.
here https://github.com/jennybc/here_here looks around the Rmd file (and all R files) for the .Rproj file and then uses that as an "anchor" to search for other files using relative references. If for instance you had the following project structure:
-data
|--mydata.csv
-src
|-00-import.R
|-01-make-graphs.R
|-02-do-analysis.R
-report
|--report.Rmd
-yourproject.Rproj
And you wanted to use mydata.csv in your report.Rmd you could do the following:
library(here)
dat <- read.csv(here("data", "mydata.csv"))
here will then convert this path to "~/Users/../data/mydata.csv" for you. Note that you have to be in the Rproject for this use case.
Here is such a great package and solves a lot of issues.
I'm using blogdown and Hugo to generate a website.
I've created a new R project and have downloaded the theme using:
blogdown::new_site(dir = "Theme", theme = 'pacollins/hugo-future-imperfect-slim') and I can preview the template once downloaded. However, if I close R and then restart and I use the add-in "serve site" I get the following error message:
Error in site_root(config) :
Could not find config.toml / config.yaml under...
and then the directory that the config.toml file is saved in (and all of the rest of the theme files) are listed.
I can't understand what's changing between being able to preview the site in R Studio Viewer, then quitting R and restarting and it not being able to find the config file.
I did find this advice: https://github.com/rstudio/blogdown/issues/48 which suggests that my working directory is not the root directory of the website. There are two things I don't understand:
1) How can the the root directory and working directory work together okay when I initially download the theme, until I quit R and restart, and then they appear to not be the same?
2) How to I change the root directory of the website to fix the issue?
Thanks!
If you followed the blogdown's documentation to create a new site with the command "blogdown::new_site(dir="/your/website/dir")", it will set your working directory to "/your/website/dir".
When you restart R/Rstudio, your current working directory is reset (probably to your home directory). You can check the current working directory with getwd().
The solution is simply set up the working directory:
The simpler way is to execute setwd("/your/website/dir"), then you should be able to run blogdown::serve_site()
The recommended way is to create a Rstudio project at /your/website/dir with File-New Project-Existing Directory. It will create a .Rproj file under the root directory of your website. After that, you can "open project" and work on your website, then preview with serve_site().
I'm working with Nginx From Beginner to Pro. The book affirms that:
The /etc/nginx/conf.d folder contains two files, default.conf and
example_ssl.conf .
but when I open my /etc/nginx/conf.d then make the list command I have nothing but just some dots like .. . which appears and are impossible to handle -neither read or open. So I'm wondering what it happens and why I haven't my files appears in the directory. After having made some searches on web I have found nothing relevant to me.
Also it's impossible to create neither a folder or file in this directory.
Currently I have create an another folder and probably will use it to insert some custom configuration.
Today, I also fell into the same issue.
When I was trying to fetch this file using FileZilla, it was not showing up.
But then I logged in through Putty and ran the command
sudo nano /etc/nginx/conf.d
The file got opened up with all its contents.
I hope this helps others.
PS: we should not try to alter this file at beginner level.
I had to find it only to increase the hash_bucket_limit inside http object. (Because the length of my domain name regex was larger than default limit).
I am currently updating a package and am hitting a wall on this issue.
I haven't been able to find any documentation explaining why the png files under inst\doc are not appearing in the library folder when I run the following:
install(package_path)
using the devtools package where package_path is the path to the source folder for the package.
I do not have an .Rinstignore file and just in case I have made sure that my .Rbuildignore does not have any patterns matching png files.
Any help or direction towards documentation over this matter would be appreciated.
To help clarify:
Below (on the left) you can see the package within the library directory containing just the html files. This is the result of running the install() command on the library I am maintaining, "". On the right is the source directory containing the png files as well. These png files are not being transferred over.
There is no additional code involved on my part.
[![![enter image description here][1]][1]
Now what is strange is that if I move the image files out of the inst directory, (So for example putting them in the root directory of the package), they do get copied over to the library.
This is extremely old now, but I came across this thread because I had the same issue.
It seems to me that it is something to do with the name of the sub-directory in inst. I had the same problem with .png files in inst/doc/img which would not copy over on package build. But changing the file name to inst/markdown/img and everything copies fine.
I'm using R markdown (README.Rmd) to knit/render to README.md at the top level of a project directory. GitLab (both in Project and Public views) chooses the .Rmd file to render vs the .md file and produces a visual mess instead of a nicely-formatted project description.
Is there any way to tell GitLab to ignore .Rmd files when picking the "right" one to use for the project/public view or am I left with a workflow that will mean keeping the README.Rmd in a separate directory then having the R project build process render and copy a knitted README.md to the top-level project directory?
This is a fresh install (this week) of a self-hosted instance of GitLab, but you can see it rendering the wrong README here.
I've reproduced this issue. I'll look into this tomorrow and make a PR for fixing this.