Pico displays nothing -- http status code is 200 | possible incorrect documentation re: /content-sample folder

[FBachofner]

I'm experimenting with Pico for the first time (ver. 2.0.0). I have it installed on an Ubuntu 16.04 machine running NginX and PHP 7.0.

Initially I had some problems, but with proper directory and file ownership and permissions, Pico seems to work (no more errors are thrown).

Unfortunately, nothing is displayed on the served page (and viewing the document's source shows, indeed, something completely empty).

A couple issues are: In the Pico documentation we are told there is a "/content-sample" folder. With 2.0 (installed from the pico-release-v2.0.0.tar.gz file) this is not the case (unless Pico is supposed to autogenerate it on first run -- but such a thing did not happen).

When I discovered the folder is missing, I made a simple index.md file in the regular "/content" folder (also per the documentation).

I still have an empty document served. [ I checked /themes/default and found index.twig -- which is presumably required for any .md files in the /content folder to display something . . . ]

Is there something which can be done on the command line to identify a "correct" Pico installation? Are there any other ideas?

Thanks in advance.

[FBachofner]

If I place a simple html file in the Pico content folder like so:

/content/test.html

Everything else being equal, should Pico "get out of the way" and should I see the document by browsing to: http://www.example.com/test.html ?

If so, I am not getting that test.html file either.

Perhaps the suggested nginx.conf files (here and here) are not quite right ?

[FBachofner]

It seems that the "Pico-master.zip" file downloadable from https://github.com/picocms/Pico is quite different from the "pico-release-v2.0.0.tar.gz"

"Pico-master.zip" includes both a /content-sample and a /lib folder

The /lib folder has 4 PHP files in it which seem germane to the operation of Pico.

I will reinstall from that file and report back.

[FBachofner]

After installing from "Pico-master.zip" I am still getting no document served from Pico.

I did notice I can now see my simple html file, but I have to browse thusly: http://www.example.com/content/test.html

It seems to me I should be able to browse to http://www.example.com/test.html (i.e. no "/content" folder specified ), but that doesn't work . . .

[PhrozenByte]

Strictly follow Pico's installation instructions from http://picocms.org/docs/#install. Using Pico-master.zip won't get you a supported Pico installation.

Simply forget about content-sample, it's a leftover from Pico 1.0. As soon as you've created content/index.md this file should be served. However, since you're getting a blank page, you're rather experiencing a misconfiguration of your webserver resp. a PHP error. Check your webserver's error.log and your webserver config.

[FBachofner]

Thanks for insisting I check NginX and PHP configuration. While the logs clearly showed status 200 (i.e. the page was getting served), you inspired me to learn that on Ubuntu, NginX serving blank pages is apparently a known (occasional) problem

The solution is to add fastcgi_param PATH_TRANSLATED $document_root$fastcgi_script_name; to the NginX config file

This is detailed here ... original source here

[ Perhaps the NginX config suggestions should be annotated to address this common issue? ]

Remaining problem / Question: For NginiX configuration, Pico documentation suggests location ~ ^/((config|content|vendor|composer\.(json|lock|phar))(/|$)|(.+/)?\.(?!well-known(/|$))) { try_files /index.php$is_args$args; }

This leads to an error: [emerg] invalid number of arguments in "try_files" directive

It does work with a slight modification: location ~ ^/((config|content|vendor|composer\.(json|lock|phar))(/|$)|(.+/)?\.(?!well-known(/|$))) { return 404; }

However, then a file like test.html (not test.md) from Pico's /content directory results in 404

Do you have any good ideas for NginX configurations for protecting those directories but still allowing .html files to be served from /content ?

Thanks in advance!

[PhrozenByte]

Can you please try the following config?

location ~ ^/((config|content|vendor|composer\.(json|lock|phar))(/|$)|(.+/)?\.(?!well-known(/|$))) {
    try_files /index.php$is_args$args =404;
}

Do you have any good ideas for NginX configurations for protecting those directories but still allowing .html files to be served from /content ?

This isn't possible on purpose. If you really want to add a static HTML page, simply upload it to the place you want it to be - like /var/www/html/my_non_pico_page.html. However, I guess you're just trying to use HTML in your content files. Just note that you can add HTML to your Markdown files, the markup is simply passed through (just add the contents of the <body> element of your content/test.html to content/test.md - it shoud work just fine).

If you need Twig on a per-page-basis, simply create a appropiate .twig file in your theme's folder (e.g. themes/my_theme/my_special_page.twig) and add Template: my_special_page to the YAML Front Matter of the desired page (e.g. content/my_special_page.md).

[FBachofner]

Hi @PhrozenByte

Can you please try the following config?

when I do that, I again get the same error: [emerg] invalid number of arguments in "location" directive in ... [my NginX config file]

Regarding the .html documents issue: No, I am not trying to use html in my Pico content files. If I were interested in that, I would just move to something like Flextype which is conceptually almost identical to Pico but uses html instead of markdown for content.

Actually, I am trying to keep a few "legacy" pages online. I don't want to re-write them and also don't want to be tempted to "wrap" these in whatever styling and navigation system I apply to the forthcoming Pico site. At the same time, I was also hoping to not have them at a separate folder (i.e. like www.example.com/legacy_pages )

Of course, by putting them in a separate folder within my document root I guess I can very easily "bypass" Pico for this type of content. I'll give it a shot.

Thanks for your help so far!

[PhrozenByte]

when I do that, I again get the same error: [emerg] invalid number of arguments in "location" directive in ... [my NginX config file]

That's not the same error, before it was in "try_files" directive. Check the location line, there's likely a typo or something like that.

[FBachofner]

Hi @PhrozenByte

That's not the same error,

D'Oh! My Bad. I actually did have the same error on a (different) server configuration the other day and forgot which error occurred where.

Well, you were right. My "typo" was that I didn't properly comment something out. Your suggested configuration works now.

Curious: why -- if we are trying to lock out any public access to those directories -- are we using "try_files /index.php$is_args$args =404;" rather than just "return 404;"

Thanks again! :-)

[PhrozenByte]

Curious: why -- if we are trying to lock out any public access to those directories -- are we using "try_files /index.php$is_args$args =404;" rather than just "return 404;"

It allows you to use Pico's 404 pages rather than your webserver's. Actually it doesn't really make much of a difference :laughing:

Thanks again! :-)

You're welcome!

[FBachofner]

It allows you to use Pico's 404 pages rather than your webserver's.

FYI, I got a Pico-styled 404 page whichever directive I used.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in two days if no further activity occurs. Thank you for your contributions! :+1:

[agaskins]

I know this is old, but I'm using Arch linux fully up to date, composer Pico install, and still got the blank page with 200 status.

@FBachofner, you are a god for posting this here! I only wish I'd dug for this answer hours ago!

I just added

fastcgi_param PATH_TRANSLATED $document_root$fastcgi_script_name;

to my /etc/nginx/fastcgi_params file and problem solved.

I don't really understand why this fixes the issue, though - can anyone shed some light on that? I host many other sites that worked fine without that fastcgi parameter.