For instance, R code in vignettes or the examples from help-pages are not evaluated, thus all results are missing. Reverting back to pkgdown 1.4.1 solved the issue. I've heard from other people having the same issues, so it might not be a specific personal setup.
Is this the same as #1278? If so we can't reproduce it, so we need more than a vague indication that other people are having the same problems.
I'm not sure if it's related to #1278. Here's an example (note that initial headers are also missing):
Affected paragraph in the vignette:
Computing the de-meaned and group-meaned variables
Another example:
First code-chunk is affected...
Your package is too big to easily debug. Here's what I see locally:
https://naughty-swartz-8a258c.netlify.com/
github htmlpreview does not seem to render the site correctly, I recommend using netlify.
github htmlpreview does not seem to render the site correctly
That was just for a quick demonstration, the bug (you can see the missing parts in the html file (source code) directly also occurs in the locally created files as well after uploading to GitHub websites.
But your site renders differnetly again (and probably correct?), I'll download the current dev-version of pkgdown and report what I have found out.
Ok, these are the (visual) differences:
Rendered with version 1.4.1:

Rendered with version 1.5.0 and 1.5.0-dev:

Your example:

As you can see, the first example is as expected. 2nd example misses code chunk and sidebar has wrong CSS. Your example show code chunk, but sidebar has wrong CSS.
I'm not sure what you mean by wrong CSS. The TOC changed to bootstrap-toc in 1.5.0.
I can reproduce this issue in a minimal reprex package: https://indrajeetpatil.github.io/minimalReprex/
GitHub repo: https://github.com/IndrajeetPatil/minimalReprex
README input:
pkgdown output:
@IndrajeetPatil this is what I see when I build your reprex; seems OK for me:
@jayhesselberth My guess is that this issue seems to affect only pkgdown websites hosted via GitHub.
This is the only common thread I see among everyone who is facing this issue. My package websites, @strengejacke's websites, websites mentioned in #1278 are all github.io, while your examples are with netlifly.com.
This issue always occurs with rendering code chunks in the presence of <- operator, as noted also in https://github.com/r-lib/pkgdown/issues/1278#issuecomment-606138502.
@IndrajeetPatil the specific host is unlikely to cause any differences. It's more likely to be how you are building the site.
I used pkgdown::build_site() to build the sites, and both locally and on GitHub there are these issues. Rendering issues are expected in the sense that the generated HTML files from pkgdown 1.5.0 do not contain the full HTML code (see my links to the html-source-code files above).
I have no idea why this happens and why output is different from the generated pages by @jayhesselberth and my try to generate the pages?
It's more likely to be how you are building the site.
Me and everyone else facing this issue.
I have been building all websites using pkgdown::build_site() and this change in output occurred when I upgraded from pkgdown 1.4.0 to 1.5.0, so pretty sure it has nothing to do with how I am building it since I haven't faced this issue before.
Here is a fully reproducible repo: https://github.com/hadley/rendertest. I don't see any problems with rendering at https://hadley.github.io/rendertest/reference/test.html (on the README, in the article, or on the reference page). You can see exactly what code is run to build the site: https://github.com/hadley/rendertest/runs/553246043?check_suite_focus=true#step:9:1.
Thanks for the efforts in solving this issue!
I've cloned Hadley's repo, and ran pkgdown::build_site()
Bellow, a screenshot of the article "test" in my machine.

And following the screenshot of the same article in Hadley's rendered page

It really seems this is a local problem, which I have no idea about that.
devtools::session_info()
#> - Session info ---------------------------------------------------------------
#> setting value
#> version R version 3.6.2 (2019-12-12)
#> os Windows 10 x64
#> system x86_64, mingw32
#> ui RTerm
#> language (EN)
#> collate Portuguese_Brazil.1252
#> ctype Portuguese_Brazil.1252
#> tz America/Sao_Paulo
#> date 2020-04-02
#>
#> - Packages -------------------------------------------------------------------
#> package * version date lib source
#> assertthat 0.2.1 2019-03-21 [1] CRAN (R 3.5.3)
#> backports 1.1.5 2019-10-02 [1] CRAN (R 3.6.1)
#> callr 3.4.3 2020-03-28 [1] CRAN (R 3.6.2)
#> cli 2.0.2 2020-02-28 [1] CRAN (R 3.6.3)
#> crayon 1.3.4 2017-09-16 [1] CRAN (R 3.5.0)
#> desc 1.2.0 2018-05-01 [1] CRAN (R 3.5.0)
#> devtools 2.2.2 2020-02-17 [1] CRAN (R 3.6.2)
#> digest 0.6.25 2020-02-23 [1] CRAN (R 3.6.3)
#> ellipsis 0.3.0 2019-09-20 [1] CRAN (R 3.6.1)
#> evaluate 0.14 2019-05-28 [1] CRAN (R 3.5.3)
#> fansi 0.4.1 2020-01-08 [1] CRAN (R 3.6.2)
#> fs 1.3.2 2020-03-05 [1] CRAN (R 3.6.3)
#> glue 1.3.1 2019-03-12 [1] CRAN (R 3.6.3)
#> highr 0.8 2019-03-20 [1] CRAN (R 3.5.3)
#> htmltools 0.4.0 2019-10-04 [1] CRAN (R 3.6.1)
#> knitr 1.28 2020-02-06 [1] CRAN (R 3.6.2)
#> magrittr 1.5 2014-11-22 [1] CRAN (R 3.5.0)
#> memoise 1.1.0 2017-04-21 [1] CRAN (R 3.5.0)
#> pkgbuild 1.0.6 2019-10-09 [1] CRAN (R 3.6.1)
#> pkgload 1.0.2 2018-10-29 [1] CRAN (R 3.5.2)
#> prettyunits 1.1.1 2020-01-24 [1] CRAN (R 3.6.2)
#> processx 3.4.2 2020-02-09 [1] CRAN (R 3.6.2)
#> ps 1.3.2 2020-02-13 [1] CRAN (R 3.6.2)
#> R6 2.4.1 2019-11-12 [1] CRAN (R 3.6.1)
#> Rcpp 1.0.3 2019-11-08 [1] CRAN (R 3.6.1)
#> remotes 2.1.1 2020-02-15 [1] CRAN (R 3.6.2)
#> rlang 0.4.5 2020-03-01 [1] CRAN (R 3.6.3)
#> rmarkdown 2.1 2020-01-20 [1] CRAN (R 3.6.2)
#> rprojroot 1.3-2 2018-01-03 [1] CRAN (R 3.5.0)
#> sessioninfo 1.1.1 2018-11-05 [1] CRAN (R 3.5.2)
#> stringi 1.4.6 2020-02-17 [1] CRAN (R 3.6.2)
#> stringr 1.4.0 2019-02-10 [1] CRAN (R 3.5.2)
#> testthat 2.3.2 2020-03-02 [1] CRAN (R 3.6.3)
#> usethis 1.5.1 2019-07-04 [1] CRAN (R 3.5.3)
#> withr 2.1.2 2018-03-15 [1] CRAN (R 3.5.0)
#> xfun 0.12 2020-01-13 [1] CRAN (R 3.6.1)
#> yaml 2.2.1 2020-02-01 [1] CRAN (R 3.6.2)
#>
#> [1] D:/Documents/R/win-library/3.6
#> [2] C:/Program Files/R/R-3.6.2/library
Created on 2020-04-02 by the reprex package (v0.3.0)
Hmm, I have no other guesses then.
For what it's worth, I have updated my minimal reprex package demonstrating this issue with session info, which might be of some help:
https://indrajeetpatil.github.io/minimalReprex/
If I clone Hadley's rendertest repo and run pkgdown::build_site() locally on my machine, I still see the same problem:

I've added session info + pandoc version to my test vignette: https://hadley.github.io/rendertest/articles/test.html
It doesn't make sense to put this information in the README, since will capture the information about the computer used to build the README.md, not the computer used to turn the README.md into html.
@TiagoOlivoto do you see the same problem if you have an expression like 1 < 2?
I just forked your repo, updated to pkgdown 1.5.0 and re-build the site using pkgdown::build_site():
https://github.com/strengejacke/rendertest
https://strengejacke.github.io/rendertest/articles/test.html
Okay, comparing Hadley's test and my identical test vignette session infos, I see the following differences that _might_ explain the difference:
fs 1.3.2 versus fs 1.4.0 (unlikely)R 3.6.3 versus R devel (unlikely)2.7.3 versus pandoc 2.9.2.1 (unlikely)@TiagoOlivoto and @strengejacke Are you also working on Windows machines?
P.S. Whatever problem is, it has to be common between my and Daniel's workflow, so I can strike out which are unlikely to be the cause of this.
I just updated pandoc from 2.7.2 to 2.9.2.1, same result:
https://strengejacke.github.io/rendertest/articles/test2.html
@TiagoOlivoto do you see the same problem if you have an expression like
1 < 2?
@hadley I have no problems with1 < 2. The code is also rendered correctly if I change< -with=
Answering to @IndrajeetPatil, I'm working on a Windows 10 x64 machine.
Interesting, I was wondering if <- was problematic because of html escaping, but that doesn't seem likely if < is ok.
@TiagoOlivoto could you please try running this code on your machine:
pkgdown:::context_set("package", "test")
pkgdown:::highlight_text("x <- 1 + 2")
#> [1] "<span class='no'>x</span> <span class='kw'><-</span> <span class='fl'>1</span> + <span class='fl'>2</span>"
pkgdown:::context_set("package", "test") pkgdown:::highlight_text("x <- 1 + 2") #> [1] "<span class='no'>x</span> <span class='kw'><-</span> <span class='fl'>1</span> + <span class='fl'>2</span>"
@hadley here is the results
pkgdown:::context_set("package", "test")
pkgdown:::highlight_text("x <- 1 + 2")
#> [1] "<span class='no'>x</span> <span class='kw'><-</span> <span class='fl'>1</span> + <span class='fl'>2</span>"
Created on 2020-04-02 by the reprex package (v0.3.0)
I've been trying to change some commands randomly to see the results, and I noticed that if I just run the code and store the results into an object, the code is rendered correctly. If I try calling that object, the problem then arose.


I just realised I used the wrong session info call — you want to see all the pkgdown dependencies, not the packages used in the current session: https://hadley.github.io/rendertest/articles/test.html
Build rendertest site on windows using github actions, and yup, I see the same problem: https://github.com/hadley/rendertest/blob/gh-pages-win/index.html#L82
But would you say it is related to GitHub, or to Windows, or is the reason for this bug still difficult to locate?
The only difference between the two runs is that one is on Windows and one is on mac. That strongly suggests that it's some extremely weird bug on windows.
Thanks to @gaborcsardi we now have a simple reprex:
pkgdown:::context_set("package", "test")
pkgdown:::highlight_text("x <- 100\r\nx")
#> [1] "x <- 100\r\nx"
pkgdown:::highlight_text("x <- 100\nx")
#> [1] "<span class='no'>x</span> <span class='kw'><-</span> <span class='fl'>100</span>\n<span class='no'>x</span>"
Created on 2020-04-03 by the reprex package (v0.3.0)
I'll work on a fix, and then plan for a patch release late next week.
Most helpful comment
I'll work on a fix, and then plan for a patch release late next week.