Pico v0.9 and beyond....

[theshka]

I have recently started collaborating on Pico, and an issue was raised regarding the closing of stale threads and pull requests. In the interest of cleaning up, I have quickly reviewed all issues and closed any that I thought were irrelevant, resolved or abandoned. Likewise, I have merged many pull requests and begun labelling issues for discussion and better organization.

If you think a thread was erroneously closed, please let me know. I will gladly reopen any issue or pull request anyone raises issue with. Going forward, Issues & PR's will ideally be labelled with a type:, status:, and priority:.

I hope this refresh of the Pico repo will stimulate new dialog and contributions. Please feel free to discuss your thoughts below.

Thanks, everyone! :) 👍

Note: If anyone is interested, during Pico's decline it branched out as BaunCMS and PhilleCMS as well.. See #199, #208

[johnnywon]

Respectfully, .9 needs to be fixed before this project goes forward. If "Pico is a stupidly simple, blazing fast, flat file CMS" then I don't see why the functionality of .8 was scrapped for a command line install as a pre-requisite for making Pico work.

The dead-simple drag and drop and it works is what attracted me and my friends to Pico, v.9 absolutely should be even simpler to install and use.

Duplicate: #223

[theshka]

It was suggested in the issues that I linked you to earlier that; Pico be split in to two branches. One for development (no vendor) and one for production (complied). As this project was dead in the water before I arrived, I am willing to entertain this. Would you like to make the desired changes and submit a pull request for feedback?

[johnnywon]

Honestly, I do not have the skills to make the desired changes. Your efforts are much appreciated, especially from people like me who are more design than PHP expert. My suggestion would be to go back to the original ethos of Pico "stupidly simple, blazing fast, flat file CMS" and keep-on with a singular production branch that might error on the side of messy but "stupidly simple" and "blazing fast."

If it is poor practice to have a /vendor folder, it should be weighed against the simplicity of install, especially for laypersons, since it would mean greater overall usage vs. organizational efficiency. I think the growth and simplicity of Pico is credit to it's dead simple install and we must continue the cause.

[theshka]

Perhaps a composer auto-installer script could be crafted for those without SSH access.
@johnnywon you may also want to consider using BaunCMS https://github.com/BaunCMS/Baun

[johnnywon]

I would recommend keeping it simple with the original ethos "stupidly simple" and "blazing fast."

Anything that requires an auto-installer script, or SSH access, or any dependency greater than PHP is unnecessary friction.

[rosewoodmarketing]

I'm going to add my little plug to emphasize the value of "stupidly simple & blazingly fast". Someone will have to determine what that is (its obviously different for different people) but I'll add my little voice. :-)

I use Drupal for my client sites, but I've been on a quest to find something more simple and lightweight for smaller websites. What I see on the home page at picocms.org sounds perfect. And it would seem to me that Pico has a lot going in that direction and would find a lot of users with that interest.

But...command line / Composer installation? No way. Gotta be simple. Upload and go. Fantastic.

I'm going to take it a little farther and suggest that the admin interface be integrated though in the basic download - or offer a download with admin and one without. For me, all client websites need an admin interface. With WYSIWYG. Simple WYSIWYG tho...really simple. Only a few options. No image placing, tables, etc. Just the minimum text formatting basically. Keep the dev stuff in the files, that's fine. But clients should be able to edit and create pages in a simple interface.

Anyhow...that's from my perspective. :-)

[mistergraphx]

@rosewoodmarketing :

The auto-installer can be a plugin, to keep the core of pico as stupid that it say's ;-)

I use a modified version of pico, but the goal is to install it locally first and publish and maintain your website(s) after. Once you have install an instance of Pico locally, you can clone it for your customers…

For the other considerations, there is some plugins to do those jobs (live editing, wysiwyg, file management). I think the core of Pico must stay "simple", but the segmentation of the Baun core is interesting in some points, actually Pico is just one class, and it's (or will) become to be a problem/limit.

Just for example, i 've to use Markdown Extra on some projects and Parsedown by default … a formatter class that can be extended could be a good point, a plugin class with a plugin description file could be another ;-) .

[johnnywon]

Eric & Mistergraphx I think have nailed it. The mantra of "stupidly simple
& blazingly fast" should guide our decisions rather than introduce friction
like an installer script or create unnecessary complexity for the sake of
"being proper."

On Wed, Jun 3, 2015 at 5:30 PM mistergraphx [email protected]
wrote:

@rosewoodmarketing https://github.com/rosewoodmarketing :

The auto-installer can be a plugin, to keep the core of pico as stupid
that it say's ;-)

I use a modified version of pico, but the goal is to install it locally
first and publish and maintain your website(s) after. Once you have install
an instance of Pico locally, you can clone it for your customers…

For the other considerations, there is some plugins to do those jobs (live
editing, wysiwyg, file management). I think the core of Pico must stay
"simple", but the segmentation of the Baun core is interesting in some
points, actually Pico is just one class, and it's (or will) become to be a
problem/limit.

Just for example, i 've to use Markdown Extra on some projects and
Parsedown by default … a formatter class that can be extended could be a
good point, a plugin class with a plugin description file could be another
;-) .

—
Reply to this email directly or view it on GitHub
#221 (comment).

[pjrvs]

Agreed with what's been echoed above. .9 is no longer "stupidly simple" to install. I'll stick with .8 (which I use and love).

[theshka]

This is why feedback is so important in developing!

Although I agree with @mistergraphx , Pico should be installed locally then pushed to your server, hence composer wouldn't be a problem for those without SSH. However, I do see how this can be problematic for those less technically inclined, and I would entertain putting the compiled vendor folder back in the repo to have that 'upload-and-go' feel.

With all that said, it is messy to keep the vendor folder, so I think it would be best to split this project in to two branches, one without composer for developing, and one with for distribution. Agree/Disagree?

In response to @rosewoodmarketing, I do not think including the admin panel, etc. is keeping with the "stupidly simple" manta everyone is so keen on. Pico should be a solid core and extensible though the library of plugins that have been developed for the class. Like you said, not everyone is using Pico in the same way. If you need a WYSIWYG editor, there is already a couple plugins for that.

I hope this has given anyone interested in developing for Pico a place to start. Pull-requests should not pile up any longer, so feel free to submit some for consideration.

[pjrvs]

I agree that if there was a version I could basically drag/drop to a server, I'd be game and very appreciative.

[rosewoodmarketing]

@theshka, the value of the admin panel in the normal Pico download I think would very much be a benefit in keeping with the "stupidly simple" operation many of us are looking for. I don't mind editing files, but I have very few clients who I'd even try to explain how to edit website files. A simple admin panel is much more of a common interface even basic computer users are used to using.

Like @johnnywon said, if a CMS requires the command line to install (or add plugins), then I'm out. Maybe some day I'll be geek enough to use it. :-)

[theshka]

I found this article sums up the FFCMS landscape pretty well: https://www.ostraining.com/blog/general/2014-static-websites/ , one of the major drawbacks is that these systems is that These are great platforms, but only for a niche audience of developers and designers. Perhaps this isn't the project for you to try and have your clients navigate?

I don't think Pico will ever be the next Wordpress, as @mistergraphx said "Pico is just one class, and it's (or will) become to be a problem/limit."

[pjrvs]

I don't use for client sites, but for my own (which gets ~50k uniques/month) it's perfect. I write in markdown any way, and when I see traffic surges, I dig that there's no DB to bog down load time. Still though, simple as possible without being any simpler... I'm down for that.

[dav-m85]

The "compiled" version get my vote. We could pack with it a composer installation along with autorun install scripts (like first request no autoload.php => create it, and after autodiscover added plugins), and keep the git installation for those who like to play with the shell (like myself).

[dav-m85]

Who owns picocms.org ? @theshka ? Consider migrating this to github.io ?

[dav-m85]

As said by @PhrozenByte,

How to fix the "composer problem" discussed in #221 and #223? There's a very simple solution: When creating a release on GitHub (after you've pushed the tag) you can upload "binaries". Simply execute composer locally, create a ZIP archive and upload the result as "binary".

It would be nice to add a travis on this one.

[theshka]

@ALL ... closing this issue, any further discussion please see #252