I have been trying to publish some documentation and can't get it to work. From what I can tell it looks to me as if readthedocs is ignoring the autosummary_generate = True directive in conf.py
I am using autosummary and it works well on my local machine, with all the individual .rst files being generated when calling make html.
When building on readthedocs everything appears to work, with no errors being thrown, but when trying to browse the documentation the links do not work. Digging a bit deeper I see this type of warnings:
/home/docs/checkouts/readthedocs.org/user_builds/libgs-ops/checkouts/latest/docs/source/index.rst:23: WARNING: failed to import libgs_ops.propagator
Since that is a file that should be generated by autosummary I am assuming the problem is, as I mentioned, that readthedocs has not generated the files.
You can experience the problem for yourselves here;
https://libgs-ops.readthedocs.io/en/latest/
See how none of the links work.
I found this thread, in which someone references a similar problem in one of the responses, but as the problem asked appears to be different I permit myself to create this new thread. As I said, autosummary works fine on my local install, just not on readthedocs.
Related
I am preparing documentation using MkDocs and trying to generate the documentation using readthedocs. I followed the user guide but readthedocs does not seem to communicate with my uploaded .md files in my GitHub project. Instead of reading my docs/index.md file, the document generated by readthedocs says
This is an autogenerated index file.
Please create an index.rst or README.rst file with your own content under the root (or /docs) directory in your repository.
If you want to use another markup, choose a different builder in your settings. Check out our Getting Started Guide to become more familiar with Read the Docs.
© Copyright 2022. Revision 8d3f60c9.
Built with Sphinx using a theme provided by Read the Docs.
One possible issue is that the builder is Sphink instead of MkDocs, so I changed the document type to "MkDocs" in admin-> advanced setting->documentation type in readthedocs but this does not solve the issue.
I then followed the instruction in readthedocs about getting started with mkdocs, import documentation, and configuration files for Mkdocs to set up configuration files as well as requirements but none of them work.
It would be much appreciated if anyone could help me resolve this issue.
I further navigated to https://shaarp-single-interface.readthedocs.io/en/latest/README.html.
The structure in the link above does contain all the nav panels I want but this page no longer maintains the readthedocs theme.
SHAARP_Single-Interface
Search docs
Home
Installation and Setup
Simulation and Analytical Methods
Input Parameters
Output Results
Examples
SHAARP_Single-Interface
Docs »
404
Page not found
Built with MkDocs using a theme provided by Read the Docs.
However, if accessing the docs using "view docs" in readthedocs, it directs me to https://shaarp-single-interface.readthedocs.io/en/latest/, which does not contain any panel I have prepared.
It seems that the building process was fine but the docs will need some time (maybe 1-2 hours) to update.
A similar issue was reported. Autogenerated index file in readthedocs
I am trying to serve PDF files from a bucket on Amazon-S3, using PDF.js in the browser. I have amended the relevant CORS policy in S3. However, I am receiving the following error message in the browser:
PDF.js v2.2.71 (build: 80135378)
Message: file origin does not match viewer's
After a search, I have found several related questions, such as this question here, as this appears to be a relatively common issue. It is fairly obvious therefore that I need to allow Amazon S3 as a host origin. Therefore, I amend my viewer.js file to include the host, like so:
var HOSTED_VIEWER_ORIGINS = ['null',
'http://mozilla.github.io',
'https://mozilla.github.io',
'https://thepdfbucket.s3.eu-west-
2.amazonaws.com'];
However, if I do a hard reload and inspect sources, I can see that the error is thrown in webpack:///web/app.js:
Uncaught (in promise) Error: file origin does not match viewer's
at validateFileURL (app.js:1482)
at webViewerInitialized (app.js:1541)
If I examine app.js, I can see the HOSTED_VIEWER_ORIGINS array, mapped from the viewer.js file. However, it does not include the amended array, i.e. my addition of https://thepdfbucket.s3.eu-west-2.amazonaws.com.
I cannot get this to work. I believe I probably have a cache issue, however, I have cleared all the browser's cache, I have even built PDF.js again from github and tried to amend the viewer.js file, prior to compilation.
If I have amended the viewer.js file, and app.js is mapped from viewer.js, but it does not reflect the recent changes, my conclusion is that it must be using a cached file. How do I clear this cache, and get app.js to reflect the changes I have made?
I really would appreciate any help here, as I've spent the whole of yesterday on this issue, and I cannot get my head around how this all fits together.
Many Thanks.
I also ran into this problem and investigated.
Version of PDF.js: pdfjs-3.3.122
The reason is that when debugging in the browser, the debug information is from viewer.js.map and not the actual working viewer.js source code.
The quickest way to debug is to delete viewer.js.map.
Perhaps the reason for the error is a mis-specified value.
That was the case for me.
Incorrect: https://google.com/
Correct: https://google.com
Translated with www.DeepL.com/Translator (free version)
For example, entering http://mywordpresswebsite.example.com/?json=1 into the browser loads the main site html, the same as omitting the json querystring variable: http://mywordpresswebsite.example.com/
The JSON API is activated. I have tried reactivating and deactivating, checking .htaccess file settings, and deactivating all other plugins. None of those have made much difference so far.
TIA
I had the same problem with my localhost test page and was wondering, why my route worked last week and was not accessible this week.
Short explanation
After some tests and a lot of frustration, I was able to use the REST API Route again by following the wordpress documentation about routes-vs-endpoints with “Pretty Permalinks” and “Ugly” Permalinks
Longer explanation
I guess in my case it was based on the reinstall of my MySQL Database. By installing the new database, my previous setup has been reset to the wordpress standard installation with permalinks as "plain", which is an "ugly" permalink. That's the reason, why the answer of Mattygabe work for me after the reinstall of the database.
But with this solution, I had a problem with my filter value and therefore I found the solution with "pretty premalinks" and changed my permalinks to "Month and name", as shown in the picture. After this change, I could access my REST API via the desired route.
There could be also some difficulties with REST APIs related to the following examples:
using "wp" within the REST route
if you work on plugins, which should be shared, keep on mind that some plugins may restrict REST Access, e.g. iThemes Security
I'm likely doing it wrong, but when I form my requests for a Wordpress installation at http://www.example.com/ like this:
http://www.example.com/index.php?rest_route=/my/rest/route/here
I end up getting proper responses back.
I had a heck of a time figuring this out and ended up grokking a URL formatted like that in the HTML returned to me. I was expecting to make requests as http://www.example.com/wp_json/wp/v2/my/rest/route/here , but I only got HTML responses.
(FWIW, I am reposting this on all similar questions on the StackExchange network. Admins/mods - if this is against the rules or seen as rep spamming, feel free to take it down. Was hoping to help anyone else hitting the same issue I am, and to also learn what it is I've done wrong and why.)
Ok, so the new endpoint for Wordpress 4.7 is mywordpresswebsite.example.com/index.php/wp-json. It's part of Wordpress Core as of 4.7 and not a plugin anymore, there's nothing to be activated. Thank you, Mark Kaplun.
I also experienced this issue. I did install the WP API plugin and then realized I didn't need it so I deactivated it and deleted it. Afterwards I tried a GET request to https://example.com/wp-json/wp/v2/posts and received the HTML of my wordpress site.
To fix this I ended up deactivating all plugins and then I started receiving the JSON response from https://example.com/wp-json/wp/v2/posts so I stepped through each plugin reactivating and in the end all my plugins are active and the endpoint is responding with JSON.
I changed Permalinks (Settings => Permalinks)
I had an issue returning html page instead of JSON response on Wordpress 5.3 and I got resolved when I changed the Permalink as Post name from plain
I've come across an issue which I've been trying to figure whether I'm just doing something wrong or whether it's an actual bug. After a lot of searching, I still can't figure out if I'm doing something wrong or if I've found an actual problem.
Part of the reason as to why I'm so confused is also because I found the intersection between react-router and history a bit confusing. It took me a while to figure out exactly how to use history's enhancer functions with react-router and I still think the issue might lay there.
I have a test case here:
https://github.com/trodrigues/react-router-basename-test
http://trodrigues.github.io/react-router-basename-test/
And the problem is:
Clicking the button issues a this.context.router.push call to navigate to /content/path
I'd expect it to navigate to http://trodrigues.github.io/react-router-basename-test/content/path
Instead it navigates to http://trodrigues.github.io/react-router-basename-test/react-router-basename-test/content/path
Some additional detail:
If I use the <base> tag instead of the useBasename enhancer this works fine. However, given that I have a slightly different setup for dev and production, using an environment variable to define the basepath would be more helpful, rather than manipulating the <base> tag at build time.
The sample app I uploaded is a minimal subset of the app I'm working on. I removed everything else that didn't matter.
The issue does not occur when running this locally with a basepath set to an empty string.
After some further investigation I figured out react-router already uses the useBasename enhancer when using useRouterHistory, which is the cause of the problem as the enhancer gets executed twice.
So I have a booking system on my website with the URL domain.co.uk/booking. I wanted to add it to a different site I have, domain.com.au/booking. It is a simple drag and drop then run an install.php file. However my domain.com.au/booking does not find anything there. the files are there in the EXACT same way as they are in my domain.co.uk site which runs fine. Are there any reasons why the path would not be found that i may simply be over looking?
N.B the error that appears is
The requested URL /booking/ was not found on this server.
Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.
If you are on a linux server, /booking/ does not equal /booking. That could explain the difference between the two sites (one is hosted on linux, the other is not).
Though this is just a wild guess.