Allowing images in subdirs of /content

[FBachofner]

I conceptually like PhileCMS due to it allowing image (and other) related content "close" to posts (i.e. in the same folder).

Pico does not currently seem to allow for this.

Is there any chance that Pico 3.x will allow for such content organization? [ I am concerned that Phile has not seen an update in 2 years (abandoned?) . . . otherwise I might use it in production. ]

[PhrozenByte]

That's not possible on purpose because Pico encourages users to follow the "separation of concerns" principle. It's the same reason why we e.g. don't support Twig in content files. There are a few workarounds to make it work nevertheless. See #530, #545 and a few more (ref. GitHub's search engine)

[FBachofner]

Thanks for the quick response @PhrozenByte

I had read #530 earlier, but thought you might have rethought it a bit during the past 4 months.

(With the caveat that I am a very poor programmer) I don't understand how keeping images out of the content folder enforces "separation of concerns." Images are, after all basic "content."

Keeping Twig out of content files makes sense in regard to "separation of concerns" as Twig can act on something (and raw content should not be allowed to do so). Meanwhile, an image or video file do not execute anything or change anything, they are just displayed by the browser when called.

Or am I misunderstanding your point?

I looked at #545 and thanks to the clear explanation conceptually see the way forward, but writing the plugin is beyond me at the moment.

[PhrozenByte]

There are some more things to consider security-wise (you really shouldn't allow users to access your raw Markdown files...), since we discussed this multiple times in the past it should be easy to find more details using GitHub's search engine. You won't need any development skills, just remove the access limitations from Pico's .htaccess resp. your webserver config. You can even configure Pico's asset_url to point to your content folder. It still isn't recommended though.

[KoljaL]

I'm not quite sure if my suggestion solves this problem, but for another CMS it does.
In markdown.php I added a query that checks the existence of the image.
If it is accessible, it is an absolute path and everything is fine,
if not it is assumed that the image in the "images" folder is in the same directory as the file itself.

     $Inline['element']['attributes'] += $Link['element']['attributes'];

    // added 
   if(@get_headers($Inline['element']['attributes'][ 'src' ])[0] != 'HTTP/1.1 200 OK'){
     $Inline['element']['attributes'][ 'src' ] = 'https://' . $_SERVER['SERVER_NAME'] . str_replace("picowiki","picowiki/files",$_SERVER['REQUEST_URI']) . '/'. $Inline['element']['attributes'][ 'src' ];
   }
   // added

    unset($Inline['element']['attributes']['href']);

    return $Inline;

[FBachofner]

Thanks @PhrozenByte !

There are some more things to consider security-wise (you really shouldn't allow users to access your raw Markdown files...), since we discussed this multiple times in the past it should be easy to find more details using GitHub's search engine.

Aha. This makes sense. I was in "static site generator" mindset and was not thinking of user's potential direct access to the directory.

It makes me wonder whether an NginX rule could be written which allows PHP to access the .md files while users have no such access.

You won't need any development skills, just remove the access limitations from Pico's .htaccess resp. your webserver config. You can even configure Pico's asset_url to point to your content folder. It still isn't recommended though.

You are right, that I am reasonably comfortable with webserver config so that part would not likely be a problem. In #545, however, @marcus-at-localhost mentioned that a PicoCMS plugin would need to be written. That would probably be a challenge for me to accomplish in a reasonable time frame.

This may be moot in any case:

1. I'll take a closer look at how PhileCMS does it -- which may be applicable to PicoCMS
2. I may choose to use an SSG instead of a flat file CMS. I think I have a good bead on open source, self hosted search for static sites.

[marcus-at-localhost]

@FBachofner not sure if I got this right, but here is how I do it:

Lets assume this file structure:

...
/content/blog/my-blogpost/
/content/blog/my-blogpost/image1.jpg
/content/blog/my-blogpost/image2.jpg
/content/blog/my-blogpost.md
...

/content/blog/my-blogpost.md content is:

---
title: My Blog Post
---
# Header

![](/blog/my-blogpost/image1.jpg)
![](/blog/my-blogpost/image1.jpg)

You would access the page this way: https://example.com/blog/my-blogpost

With the .htaccess described here: #545 (comment) (I'm not familiar with NginX) you don't need a pico plugin, because the images are referenced correctly in the document /blog/my-blogpost/image1.jpg => https://example.com/blog/my-blogpost/image1.jpg.

The Pico plugin is only needed if you have to rewrite the image path, because it doesn't translate to the server path, caused by a markdown editor or whatever e.g.

---
title: My Blog Post
---
# Header

![](/e/localhost/pico/content/blog/my-blogpost/image1.jpg)
![](/e/localhost/pico/content/blog/my-blogpost/image1.jpg)

Then you can do some string replacement/removal like the following, in a pico plugin:

in plugins/Blog.php

class Blog extends AbstractPicoPlugin
{
    public function onContentPrepared(&$markdown)
    {
    	$markdown = str_replace('/e/localhost/pico/content','',$markdown);
    }
}

[stale]

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! 👍