Show HTML file as a page

[motty-mio2]

I'm considering to migrate my site built with static html files to picocms based web site. Then, I want to keep old file link. I tried make directory like here.

-content/sub/
    ├─ old.html // invisible
    └─ new.md // visible

I cannot see the html file with "Error 404".

Can I see the html like markdown file, if possible, without changing the html.

[mayamcdougall]

Hi there. 👋🏻

By default, Pico's included .htaccess blocks access to anything inside of the content folder so that users can't snoop on your plain markdown files. This is why you're seeing a 404. 😉

First of all, if you were trying to make a hybrid site like this, you wouldn't necessarily want your .html files to be in the content folder due to the way Pico handles URLs. Pico doesn't expose the content folder in its URL. So when you visit the page sub/new.md the URL will be example.com/sub/new, not example.com/content/sub/new. So even if you could access your .html page without it 404-ing, the URL would be different since one is processed through Pico and one isn't. The .html page would have /content/ in its URL, while the .md wouldn't.

Unfortunately, this does mean that you'd likely have to keep your .md and .html files in separate folders.

Since the .htaccess RewriteRules are a blacklist and not a whitelist, I'm pretty sure that if you rearrange your files, it should just work. I'm not 100% sure though.

Try laying them out like this:

-content/sub/
    └─ new.md
-sub/
    └─ old.html

It's not ideal, but I think it'll behave the way you're hoping. Let me know if it helps or not and we'll take it from there. 😁

---

@PhrozenByte, since we're talking about a modified directory structure here, this feels like it also boarders a little on a security question. Do you have any input on whether this would be a good idea or not? Did I sum this up okay or am I missing something?

Also, I swear these questions come in pairs or groups. This is the second issue in the last few days involving .htaccess, and I'm suddenly finding myself having to brush up on how it all works. 😂

[motty-mio2]

Thanks to your post, I'm starting to understand what pico is doing. Then I tried this directory layout.

├──content/sub/
│  ├─ index.md
│  └─ new.md
└─sub/
    └─ old.html

I can access these urls.

• example.com/sub/new
• example.com/sub/old
• example.com/sub/index But I cannot use this
• example.com/sub/ (for index.md)

I re-check around .htaccess settings.

[mayamcdougall]

Hmm, I didn't think of that. 🤔

What I think is happening here is that Pico's RewriteRules prioritize real files (for loading assets/images/etc) before falling back on index.php (aka Pico itself) if a URL doesn't exist.

But since /sub/ does exist, it's looking for an index.html there instead of running Pico.

You could try using /content/sub.md (not in the /content/sub/ folder) and see if that makes a difference (Pico will use either file as the sub-folder index). I doubt it will matter, since I think the issue is web server related, before it loads (or in this case doesn't load) Pico.

@PhrozenByte, what would your recommended solution be?

If it's only a small number of pages you're looking to integrate, you could always do something hacky, like store those pages as separate Templates in your Pico Theme, then load them through Pico using some stub markdown files. 🤔

I could walk you through that if you wanted. It wouldn't be a very scalable solution, but if it's just a handful of pages, it might be the simplest way to integrate them without things getting weird.

I'll check in tomorrow and see what your thoughts are and/or if PhrozenByte has been by. It's really really late for me right now, but I saw this in my inbox right before bed and apparently couldn't leave it for tomorrow. (I tried... but then I got stuck thinking about it anyway. 😂)

[mayamcdougall]

Alright, so the hacky solution if you wanted to try it.

• Place old.html in the folder of your chosen Pico Theme (so, for the Default theme it would be in /themes/default/)
• Rename it old.twig, since these days Pico prefers templates to be .twig. Don't worry, we won't actually be adding any Twig syntax to it.
• Make a new markdown file at /content/sub/old.md (or at /content/sub/old.html.md if it's important to you to maintain the .html in the URL).
• In the metadata of that file, add a line that says Template: old, matching the name of the .twig file we created earlier (minus the .twig extension).
• Add any other metadata you might need for navigation / sorting purposes, like Title: or Date:. Since there's no Twig in our new "template", they won't be used for anything on that page, but they will be used by other pages when making things like your navigation. For example, Title would be used for the link text, and Date would only really be needed if you're sorting your pages by date. Etc.

Now, when you navigate to this new page (example.com/sub/old), Pico will attempt to load your old HTML page as a Twig template. And, since there's nothing in the rules that says your template actually has to be dynamic, we cheated and just had it load your old static HTML. 😉

(Also, I didn't put it in the instructions, but make sure to get rid of or move that /sub/ folder that wasn't working somewhere else. We don't want it interfering anymore.)

Anyway, there you go. I see no reason why this method wouldn't work for you. It's just not very scalable. If you've got a handful of pages, give it a shot. If you've got a couple hundred pages... maybe wait and see if PhrozenByte has a better solution for integrating them. 😅

If you do use this method, and you end up changing your Theme in the future, all you should have to do is copy/move those extra .twig files you created into the new Theme folder.

[PhrozenByte]

I don't really see a reason why one would want to mix complete static HTML pages (i.e. with menu, header, footer, etc.) with dynamically rendered pages :confused:

Anyway, if you create a /var/www/html/sub/old.html you can naturally access it on https://example.com/sub/old.html; you could fiddle around with rewriting and stuff to support things like dropping .html in the URL, but this is a matter of your webserver config, not of Pico. In theory you could also use Maya's "rename everything to .twig approach"... But still, I don't see a reason why one would want to do that.

If this is just about the contents of a old website (i.e. without menu, header, footer, etc.), you can simply copy the HTML snippet of the old page to the matching .md file. Markdown won't interfere, Markdown supports arbitrary HTML contents.

[mayamcdougall]

I don't really see a reason why one would want to mix complete static HTML pages (i.e. with menu, header, footer, etc.) with dynamically rendered pages 😕

I mean, neither do I, but I try not to question things. 😉

Everyone's got their own use case after all. 😂

The real issue was just that there wasn't a great way to combine the two reliably without the web server getting confused (for example, on where to find the correct index, mentioned above).

I'll file this as "PhrozenByte doesn't have a good solution" either. 😂

@motty-mio2, if you want to give me a little more detail about your setup and your end goal, I can try to walk you through things as you go.

Also, PhrozenByte does mention a good point that I should have brought up:

If this is just about the contents of a old website (i.e. without menu, header, footer, etc.), you can simply copy the HTML snippet of the old page to the matching .md file. Markdown won't interfere, Markdown supports arbitrary HTML contents.

Pico is perfectly capable of reading HTML tags in your Markdown files. If that makes some of your migration easier (being able to copy-and-paste the content of your older pages while leaving the rest behind), it might be a valid solution too. Just depends on what your end goal is. 😉

Let me know how I can help more. Feel free to ask any questions you have. ❤️

[motty-mio2]

Thank you @mayamcdougall, @PhrozenByte.

I also currently think that using other folder (like sub) is a best.

The real issue was just that there wasn't a great way to combine the two reliably without the web server getting confused (for example, on where to find the correct index, mentioned above).

I fully agree this. My use-case is odd one... I rethink what is needed or not.

Thank you for yout generous support.

[mayamcdougall]

You were still having issues with /sub/ not resolving to /sub/index though, right?

I've been working with RewriteRules for another Issue today. I wonder if I could write you a quick RewriteRule that would correct that? 🤔

[motty-mio2]

Oh... I forgot it.

With new RewriteRules. sub/index.md could works well?

[mayamcdougall]

Hopefully. 😉

Let me mess around with it for a bit. 🤔

[mayamcdougall]

Alright, so I think I have a solution.

I'm not an expert on this, so I can't say for sure that it's correct, but it seems to be working in my testing. I modified this from an existing example I found somewhere.

    RewriteCond %{REQUEST_FILENAME} -d
    RewriteCond %{REQUEST_FILENAME} /$
    RewriteCond %{REQUEST_FILENAME}index.html !-f
    RewriteRule ^ index.php [L]

To my understanding, this reads:

1) If the requested directory exists. 2) If the requested url ends in / 3) If the requested filename ends in index.html but doesn't exist. 4) Rewrite internally to index.php (Pico).

You might not need the first condition, I'm not sure. The other two were definitely required though, to prevent redirecting to Pico when we don't want it to.

Add this block to your .htaccess, and it should hopefully take care of the "Missing Index" problem.

Again though... I'm not an expert. I'm just fumbling through this, trying to be helpful. 😅

Definitely do some testing on your own to make sure it behaves correctly.

[motty-mio2]

Thank you!!

It works well on my env.

├──content/sub/
│  └─ new.md
└─sub/
    └─ index.html

[mayamcdougall]

Yay! 🙌🏻

Glad that worked for you. 😁

Hope you're enjoying Pico.

Let me know if there's anything else I can help with. 😉

You can either open a new issue when the time comes, or continue chatting here.

Don't be afraid to ask questions. Take Care. ❤️