I am trying to re-setup an existing Octopress blog to a new PC.
And When I generate pages.
An atom.xml is generated with following content at the first line.
And when I hit the browser I get an error:
This page contains the following errors: error on line 1 at column 28:
Entity 'ldquo' not defined Below is a rendering of the page up to the
first error.
My _config.yml file has this:
subscribe_rss: /atom.xml
subscribe_email:
root: /
permalink: /blog/:year-:month-:day/:title/
source: source
destination: public
plugins: plugins
code_dir: downloads/code
category_dir: blog/categories
markdown: rdiscount
rdiscount:
extensions:
- autolink
- footnotes
- smart
highlighter: pygments
I think I am aware that ' chars are changed to ldquo due to rdiscount smart extension. But If thats the case, I should not be getting the error on browser.
I am confused. Any help would be great.
If I remove 'smart' extension, then the generated atom.xml does not contain the > , due to which it fails again and throws some other error.
Please help
Also raised here:
https://github.com/imathis/octopress/issues/1759
I dont think its your config file.
Try to change the markup engine and see if its still displaying the error.
As i see it the engine replace them and since i cannot see your code its hard to find out the exact problem.
Replace the markdown configuration and test it again.
Related
Hi I've been facing an issue on my website avcpetstore.com
-theme used in this is (Porto ecommerce theme)
I've tried the following steps already.
disabling all plugins (doesn't workout)
disabling current theme and activation other 2 themes (doesn't workout)
Php memory limit increased already - permalinks setup multiple times (did't workout)
all other things in terms of debug did't workout. console showing
Browser's console showing this error
Unable to fix malformed JSON
checkout.min.js?ver=7.0.0:1 ---------- Unable to fix malformed JSON
Probably in your checkout page file while copy-paste code you miss clicked and remover or added symbol like '<' so you should review code from end to start looking for unintended content. Also you could try disabling (commenting) all the hooks to that file one by one, maybe there is mistake in them.
Also you can try using the default woocommerce template file to see if it start working again and trying adding your custom code on top of your fresh default file.
I am using the Sphinx autodoc and napoleon extensions to generate the documentation for my project (Qtools). This works well on my local machines. I am using Sphinx 3.1.2 (or higher). However, when I build the documentation on Read the Docs (RTD), only text added directly to the reStructuredText files that form the source of the documentation is processed. The docstrings that are supposed to be pulled in by autodoc do not appear in the HTML documentation generated by RTD. So for example in docs\source\section2_rsdoc.rst I have:
Response spectra
================
The response spectrum class
---------------------------
.. autoclass:: qtools.ResponseSpectrum
:members:
Response spectrum creation
--------------------------
.. autofunction:: qtools.calcrs
.. autofunction:: qtools.calcrs_cmp
.. autofunction:: qtools.loadrs
See also :func:`qtools.convert2rs` (converts a power spectrum into a response spectrum).
This results in:
Response spectra
The response spectrum class
Response spectrum creation
See also qtools.convert2rs (converts a power spectrum into a response spectrum).
In other words, all directives are apparently ignored, and hyperlinks to other functions are not added. I have examined several basic guidance documents such as this one, but I cannot figure out what I am doing wrong. RTD builds the documentation without any errors or warnings. In RTD advanced settings I have:
Documentation type: Sphinx HTML
Requirements file: requirements.txt
Python interpreter: CPython 3.x
Install Project: no
Use system packages: no
Python configuration file: blank
Enable PDF build: no
Enable EPUB build: no
I haven't touched any other settings.
In conf.py I have tried the following variations of line 15: sys.path.insert(0, os.path.abspath('.')), sys.path.insert(0, os.path.abspath('../..')) and the current sys.path.insert(0, os.path.abspath('../../..')). None of those made any difference.
I would be grateful for any help!
RTD builds the documentation without any errors or warnings
This is slightly incorrect. As you can see in the build logs, autodoc is emitting numerous warnings like this one:
WARNING: autodoc: failed to import class 'ResponseSpectrum' from module 'qtools'; the following exception was raised:
No module named 'qtools'
This has happened for all your variations of sys.path.insert, as you can see in some past builds.
Trying to make it work this way is tricky, since Read the Docs does some magic to guess the directory where your documentation is located, and also the working directory changes between commands.
Instead, there are two options:
Locate where the conf.py is located (see How do you properly determine the current script directory?) and work out a relative package from there.
Invest some time into making your code installable using up-to-date Python packaging standards, for example putting all your sources inside a qtools directory, and creating an appropriate pyproject.toml file using flit.
I'm using saltstack to manage my personal config. In particular I'm managing my ~/.profile programatically. I have various things throughout the setup which append text (mostly env var exports) to it, and they all work exactly as expected. I want to to use slsutil.banner to prepend a banner saying that the file is managed programatically by salt, and not to touch it by hand. So I have in my profile/init.sls:
profile-managed-banner:
file.prepend:
- name: {{ pillar['profile_file'] }}
- text: {{ salt['slsutil.banner']() }}
This should write the default banner to the beginning of the file.
When I then run run salt-call (the setup is masterless. Running salt-call as sudo if that's at all relevant) I get:
ID: profile-managed-banner
Function: file.prepend
Name: /home/modallyFragile/.saltProfile
Result: True
Comment: File /home/modallyFragile/.saltProfile is in correct state
Started: 15:59:07.760790
Duration: 1.757 ms
Changes:
So clearly salt can find and use all the functions (or at least it thinks it can) and the the file is having something prepended to it. If I check the file though, I get this:
None
[ ... further config here]
If I substitute the templating for a string (so - text: some string here) it works as expected (prepends 'some string' to the file). So the probelm is with the templating slsutil.banner then. I've tried passing (various combinations of) arguments explicitly and nothing seems to help.
Why might this be happening and what can I do about it? Failing anything more substantive, what could I do to further diagnose the problem (I'm pretty new to saltstack, is there a particular log I should be checking with all the relevant info, etc. etc.)?
I can't find any issues or problems by searching (github or more generally), so I'm drawing a blank. Literally any suggestions would be really helpful. Thanks!
Adding this as an answer. As per the official documentation:
Create a standardized comment block to include in a templated file.
And this does work inside a templated file.
Just for example files/user-profile.j2:
{{ salt.slsutil.banner() }}
# the default umask is set in /etc/profile; for setting the umask
# for ssh logins, install and configure the libpam-umask package.
umask 022
PATH=$PATH:/my/local/bin
Used in a setup.sls:
create-user-profile:
file.managed:
- name: /home/user1/.profile
- source: salt://files/user-profile.j2
- template: jinja
Will create a file /home/user1/.profile with a default banner at the top and the remaining content as it is.
Then it starts making sense. If you want a banner on file that "it is managed by Salt", then the file should be managed by Salt (as template). Prepending the banner in a remote file, leaving the remaining file contents unmanaged contradicts the purpose of the banner.
So if you want a banner in the file, you can manage the ~/.profile file as a template, and write it to minions as above.
Update:
It might be worth reporting this as an issue if we want a custom banner prepended to a file without managing it.
The problem is that your Jinja, once rendered, produces invalid or incorrect YAML. In this case, what is happening is that the slsutil.banner() function returns several lines that all start with '#'. The YAML renderer considers them comments and throws them out.
The solution is to escape the comment characters so they are properly interpreted by the YAML renderer. Fortunately, Salt comes with a very helpful Jinja filter that does this for you: yaml_encode. Your state works fine with this small change.
profile-managed-banner:
file.prepend:
- name: {{ pillar['profile_file'] }}
- text: {{ salt['slsutil.banner']() | yaml_encode }}
I've got mkdocs.yml file which looks like:
site_name: blabla
pages:
- One page: page2.md
- Second page: page2.md
- Navigation: Navigation.md
When I open it url is like this: http://10.2.0.8/blabla/master/Navigation.md and doesn't work and I get 404 Not Found
nginx/1.14.0 (Ubuntu) error. If I delete .md at the end of url it works fine.
However, on locally it opens like http://127.0.0.1:8000/Navigation/
does anyone know what's the problem with this?
As described in the official mkdocs documentation, the intended behavior is that http://10.2.0.8/blabla/master/Navigation.md does not exist, but rather http://10.2.0.8/blabla/master/Navigation as shortcut for http://10.2.0.8/blabla/master/Navigation/.
What might have gone wrong in your case is the deployment of the HTML & CSS files. Assuming that your markdown sources are in ~/blabla, a mkdocs build --clean within that directory will create a subdirectory ~/blabla/site/ which you then have to deploy in the respective directory, say /var/www/html/blabla/. Under Linux, I suggest a rsync -r --delete-before ~/blabla/site/* /var/www/html/blabbla/. In other words: The issue might also be that you simply have not deployed the whole site or at a different place.
I'm running Rstudio 0.98.490 on Windows 7. Sometimes when I click on "Knit HTML", the output does not include the title section. For example, if the following is my .Rmd,
---
title: "Sample Document"
output: html_document
---
Section 1
--------
blah blah
Then the first thing that shows up in my .html file is "Section 1" instead of "Sample document". This is very bad. How can I ensure that the title shows up?
Additional details: The missing title does not always happen, and I don't know why. Here are several things that I tentatively associate with the missing title:
when the title fails to display, a .md file appears in my directory; otherwise it is automatically cleaned up.
the title fails to show up every time that a log screen like this shows up during compilation in Rstudio:
What is going on???
What's happening is that--for some reason--RStudio is not using the new RMarkdown v2 but rather the classic knit-to-HTML feature to render your document.
It's likely that the culprit is an option called rstudio.markdownToHTML (more information about this option is available here: Customizing Markdown Rendering).
If this option is set, then RStudio assumes that you have a custom workflow and doesn't use rmarkdown.
So, three things to try:
Check to see if the option is set immediately after you observe the problem. If it is, you have your culprit. Make sure the option is not set automatically (e.g. you might try searching through your R sources to see if it's getting set in an .Rprofile somewhere)
Make sure you're running the very latest version of RStudio and the rmarkdown package: devtools::install_github("rstudio/rmarkdown"). RStudio won't use the rmarkdown package if it looks out of date.
Finally, if all else fails, you can always render your document manually using rmarkdown: rmarkdown::render("zdlmn.Rmd"). If you have to resort to this, then a post to the RStudio support forums with your sessionInfo() and RStudio/rmarkdown versions would be helpful.
There are two ways to open a .Rmd file with Rstudio.
(1) Double-click on the .Rmd file you want to edit, and Rstudio opens with the file loaded in the editor window.
(2) Open Rstudio directly, and then do File -> open ...
On my computer, (2) leads to the good behavior and (1) leads to the bad behavior.
I have no idea why, so I don't consider this to be a "real" answer, but I'm posting this because it's a life-saver for me while I figure out what's really going on.