search

picocms / Pico

Pico is a stupidly simple, blazing fast, flat file CMS.
http://picocms.org/
MIT License
3.85k stars 615 forks source link

Pico is dead... probably #108

Closed Snip1 closed 11 years ago

Snip1 commented 11 years ago

If you've come here for support, I suggest you take a look at the history of how effective that is likely to be. Just go down the list and see how many responses you find, and make your assumptions on how likely your problem is to get solved here accordingly.

In my case, I even went so far as to contact the dev directly, and was summarily rebuffed and told this was the place... which it clearly isn't.

Pico, I have to suggest, is dead. Indeed, I now rather suspect it was an ego thing the dev did to see how many links and how much ranking he could get. Disappointing, really... this could have been a killer app.

skegr commented 11 years ago

@Snip1 - Your comment is not a constructive contribution. Gilbert built a great foundation and put loads of effort into getting Pico to v0.8 along with the myriad other projects he's involved in, and the folks that have forked it to create Phile are carrying the torch. This is how Open Source works, and it's working.

grouchal commented 11 years ago

I think this is a bit harsh, the last release was less than a month ago.

Development may be slow for your needs, but dead is something else.

The Phile code does seem to address some good points, but has incompatible plugins which is a shame. Forking at this early stage seems to be a mistake.

It would be nicer if there was more responses from gh to issues and if he doesn't have time, he should try and get some help. I think it is good that pico core is kept to a minimum but that doesn't mean all suggestions should be ignored.

qwuille commented 11 years ago

15 days ago was this post https://github.com/gilbitron/Pico/wiki/Feature-Requests In the same run there had been discussion of gilb to get support for his project.

Good thing with making a fork of Pico is that there is "competition" and that is a ground rule for having something to get better at what it is, no matter what it is.

One bad feeling i get about Phile comparing to Pico is that gilb is mentioning the downsides while Phile only shows the possitive things, that means in short that there are no major areas of improvement to be done. But that is just my opinion, self made reverse marketing?

Certainly i will try Phile but I'm holding my thumbs for Pico.

NeoBlack commented 11 years ago

Hi everyone, At first, Gilbert did a great job and he has a really good idea. This was the reason for me to start working with pico. After some testings I found some issues, which I have fixed. I started a pull request and after some days and some messages the fix was merged. I offer Gilbert to support the project with our company three times, but get no reaction. He sad the main idea is, to hold the core small and implement features by plugins, this also a great idea. But after I am installing 4 plugins, my test site was very slow, this happens because the plugin structure is not optimal. e.g. the method get_pages was called over 100 times per Request and every call was parsing the complete page.

I offer Gilbert to do some refactorings and introduce some object oriented code to make it more performant. Gilbert not respond to my offer. After Gilbert told me that pico has not the biggest priority, James and me started the fork PhileCMS to work on our own implementation and to speed up the development. After some days we have refactored the complete core, but still with the same idea, a small core and features in plugins.

PhileCMS introduce a service locator, which makes it possible to replace the markdown parser, template engine or cache engine easly with a plugin. The new plugin structure works well and PhileCMS is a lot faster than before. (The template engine, cache engine and the markdown parser are plugins in PhileCMS)

Pico and PhileCMS are both open source, everyone can help to improve, and also Gilbert can look at Phile and use our code to improve Pico if he like. James and me are not the bad guys, this is the spirit of open source!

NeoBlack commented 11 years ago

One addition: Yes, the plugins are not compatible, it was not possible to get pico plugins run on the new plugins architecture. At the beginning we hope to get this working, but the main goal for PhileCMS was the performance and the plugins structure was a big performance issue. But we are working also on new plugins, a list can be found in the wiki.

grouchal commented 11 years ago

@NeoBlack I think you have made some sane architecture choices, but I just wish they could happen within the pico project. I think Gilbert must agree too because you are trying even more to reduce the core.

If Gilbert really has abandoned the project it would make sense to fork, but hopefully he has not and is going to comment soon. For all we know he might be on a Buddhist retreat in Tibet at the moment working out which decisions need to be made next ;)

I would like to see your changes (or similar) made to the pico project so that it can improve, but if Gilbert has no time or is unwilling to share the project then there is no other option but to fork! but I think it is a bit soon now.

NeoBlack commented 11 years ago

@grouchal I was searching a long time for a small CMS for our customers and on my research I found pico. I like it and will use it on our projects. but for reasons I have listed above, it was not possible to use it in a production environment. I love the spirit of open source and I think we are on the right way. Gilbert has the choice to decide which parts of our code he will use for pico or not. And when he is ready to do more for pico, he can get all of our code, that is open source. I can not tell my boss that I work a bunch of hours on a project and do a lot of changes without the warranty, that the changes will be merged into the core. We can not work with a tool which has to be patched on each release. Do you know what I mean?

Snip1 commented 11 years ago

@skegr & @grouchal ~ I apologize for what you perceive as my tone... and you are not entirely wrong in that perception. However, allow me to at least try to explain.

I am not unfamiliar with Open Source, nor a total n00b at working with OS apps. So, I make it a point to test relatively newer contributions to the sphere... the likelihood is that the developer and interested third parties (such as yourselves) are more likely to still be involved and interested in moving the solution forward. Also, I really have been searching for quite a while for exactly what Pico purports to offer... so I got excited as well.

However, Pico is still quite rough and somewhat obtuse to deal with... so I asked what I thought was a fairly simple and reasonable question... and got no response over the course of several days. That surprised me, so I checked into the forum here. And lo and behold: basically nobody gets an answer in anything like a timely manner.

So then I did what I thought was another reasonable thing: I asked the developer directly where to go for documentation and support, as it appeared this forum clearly wasn't it. His response?

"There is no official support for Pico I’m afraid, but Github is definitely the best place to ask yes."

So... what am I to think? Nobody answers here, and the dev isn't even interested. If that is not "dead... probably" what is?

I will be checking out Phile (why did you delete your post, @tyeeman)... who knows? Maybe that's the one ;)

BTW.. interesting that nobody replies to actual issues, but lots of responses to this. Not quite sure what that means, but it is curious. Is everyone basically in the same boat as me... needing Mr Pellegrom?

james2doyle commented 11 years ago

I have always wanted to make a small, lightweight, markdown-based CMS. Pico really was exactly what I was looking for.

I've developed about 6 plugins for Pico, more if you count the ones I haven't shared. I have also answered a few issues/questions on the Github issues page. I have about 3 sites, in production, that run Pico. So to say I haven't tried to support Pico, or I haven't given it a chance, is wrong.

I think Pico can still go on and live. Phile is now quite different. It may be based on 0.8, but I am tempted to run a diff and see if there is any resemblance anymore. I am considering taking the line out, just because @NeoBlack has done a great job and now it is almost completely unrecognizable.

I think we are all objective with our PRs and Issues. A few weeks ago @NeoBlack made an issue/comment regarding the number of times get_pages is called. Gilbert said it was for the excerpt. @NeoBlack said, "why not just use/reuse the meta description or move this into a plugin?" I mentioned that this could be easily done with a Twig filter. These suggestions went unheard.

So I understand what @Snip1 is saying. I don't agree that Pico is dead, more like "loosely maintained". If you want something with better performance, regular updates and improvements, service locator (override template engine and parser), more verbose plugins, caching, data store, and reasonable support, then please check out PhileCMS.

If you want to see Phile in production, my personal site runs the latest Phile, with the Sundown parser. You can see it is insanely fast.

shawnsandy commented 11 years ago

Interesting conversation, while I do not consider myself a developer I do write a little code, I was looking for a simple easy to use database free, lightweight PHP CMS and Pico was the best solution I had found and would never use it for any high content site or blog for that matter, it is not designed for that. So it did not matter that it was not the fastest, it was fast enough, did it need improving absolutely.

But I do not care for questions like these, no opensource project will grow if we expect it to be perfect from start it's success is dependent on the support of it's users. WordPress for example is very faaaaaaaaaaaarr from perfect but it has a huge community of contributors that work together on improving it, and this it why has grown to become the one of the most popular OS project on the planet.

As for Phile I took a look at and it is well written, OOP based, seems faster, but I decided to stick with Pico because

So what happens when another developer does not agree with Phile's core philosophy and Forks, that will not help Phile, the only thing it does is create more fragmentation something that is a huge problem in the OS community.

james2doyle commented 11 years ago

@shawnsandy I agree with you on most points. We can all wax poetic about the follies of open source, but I think you are exaggerating the amount of times open source projects get forked into new ones.

The first commit of Pico was 6 months ago. Phile came about because there was a slow development cycle, lack of issues being addressed, and performance with multiple pages. Also we were looking for something a little more verbose, and in order to do that, the fork has become more "complicated", speaking in terms of PHP complexity. So you can stick with Pico, there is absolutely nothing wrong with that.

But what happens when you encounter an error you can't fix? Or worse, don't know how to fix it, because you are "not a developer"?

That's when having PRs and issues solved, also known as progression, would be nice.

NeoBlack commented 11 years ago

@shawnsandy thanks for your posting. I agree with James, so I will not answer the same thinks again. we have rewritten the Core within some days, the community will be bigger the next time. The documentation is one of our next tasks, we have started with some pages in our Wiki.

shawnsandy commented 11 years ago

@james2doyle -- Sorry, but my point was not about how many times but that forking divides the support base and that a strong support base is crucial to the success of OS projects.

Pico at it's core is a single file -- lib/Pico.php. I did encounter several things I could not fix and I did not want to wait on the slow development cycle, so modified the Pico class so that I could extend it and overwrite whatever functions I needed to change, I submitted the changes and they were added to the Pico pulled (manually).

I love what you guys are doing, my hesitance to commit is solely a personal preference.

james2doyle commented 11 years ago

@shawnsandy I agree with you about the support base, but right now that is what is lacking, and that is why it was forked. I was hesitant to start the fork because of this very reason (split community, lack of users), and just doing a ton of work for nothing. If that strong support base is so crucial, what can we say today about the state of Pico support?

So far I am extremely happy with the work of @NeoBlack and the resulting speed and abilities of Phile. We have almost twice as many commits as Pico and we are going on day 14. But that needs to be taken with a grain of salt, of course.

Snip1 commented 11 years ago

(Replying via email... not sure that will work)

Not that I know about these things... but could Pico not have been taken over by yourself and NeoBlack?

On 2013-11-07, at 3:08 PM, James Doyle wrote:

@shawnsandy I agree with you about the support base, but right now that is what is lacking, and that is why it was forked. I was hesitant to start the fork because of this very reason (split community, lack of users), and just doing a ton of work for nothing. If that strong support base is so crucial, what can we say today about the state of Pico support?

So far I am extremely happy with the work of @NeoBlack and the resulting speed and abilities of Phile. We have almost twice as many commits as Pico and we are going on day 14. But that needs to be taken with a grain of salt, of course.

— Reply to this email directly or view it on GitHub.

John Snippe Myeloma: http://www.snippe.ca Scribblings: http://blog.snippe.ca

james2doyle commented 11 years ago

This was suggested by Gilbert a couple weeks ago in a large discussion

Snip1 commented 11 years ago

OK... so now I am REALLY curious!

If Gilbert already was open to the idea, and since Pico already has some pretty significant cred/buzz going... why Phile? Could your optimizations not have been done within the Pico framework (or alternately, might Gilbert have been cool with what sounds like a basic re-write?)

ATM, this does sound a little bit like re-inventing the wheel.. but of course, we wouldn't have NASCAR if that wasn't an ongoing reality, would we? ;)

At this point I'd really like to apologize to Mr Pellegrom for my grumpies the past day or so... I am starting to see the light regarding Github et al. It really is a somewhat different biosphere than what I have been used to, and I should have stayed on shore for a few more days (weeks? months?) before wading in and discovering it is deeper than I thought...

james2doyle commented 11 years ago

@Snip1 it didn't seem like he was up for the rewrite. This is probably why most PRs getting "merged in manually". But I am happy with the fork, it has gone much farther than I was expecting. At first I didn't want to even go outside of the single-file-style that Pico uses, but @NeoBlack convinced me and I am quite glad he did. It has lead to infinitely more flexibility.

Phile now has the choice of 3 template engines (Twig, Lex, Smarty) and 2 different markdown parsers (PHP-Markdown and Sundown(PHP C-Extension)). Which is pretty cool to me!

Snip1 commented 11 years ago

On 2013-11-07, at 3:42 PM, James Doyle wrote:

Phile now has the choice of 3 template engines (Twig, Lex, Smarty) and 2 different markdown parsers (PHP-Markdown and Sundown(PHP C-Extension)). Which is pretty cool to me!

Ubiquity Rulz ;)

John Snippe Myeloma: http://www.snippe.ca Scribblings: http://blog.snippe.ca

shawnsandy commented 11 years ago

@james2doyle, @NeoBlack -- For the most part I agreed with Gilbitron as it pertains to keeping Pico very lightweight and keep customizations out of the core. If you plan to run a full blown blog or website for that matter a flat file system is not the way to go speed would be the least of your problems, .

The problem with Pico is that it was not written with DRY principles in mind and already there was a lot of copy and paste code ( get_pages() ) flying around in plugins. I am interested to see how you guys dealt with that. For example can I reuse a core function in my plugins or extend a plugin or do I have to copy and paste it???

If these things are adequately being addressed then you would have convinced me that the fork was worth it.

NeoBlack commented 11 years ago

@shawnsandy I am not sure, if I understand your question. What do you mean exactly? Give me some examples and I will give you an answer ;)

Most of the core components are implemented as a service, this makes it possible to replace the template engine, markdown parser, cache system or the new data storage engine with your own, without touching the core. The plugins can register for events, this makes it possible that the a method like get_pages will only be called if plugin has registered for this event. To access pages, you have to use the new page repository, which give you all pages, or one page by path (all with a great php object cache).

shawnsandy commented 11 years ago

@NeoBlack Examples

Even some of the plugin I have written I have done the same thing. IMO the practice leads to bloated code, much like what we see within the WordPress, I am hoping that you found a way to address issues like this...

NeoBlack commented 11 years ago

ok, we have some core methods in an utility class, which can be used by any plugin. e.g. \Phile\Utility::resolveFilePath("MOD:myPlugin/config.php");

the method returns the full file path to the config file in the plugin folder. the method get_files was complete removed, but general: all methods which are useful can be added to the Utility class and an will be accessible in all plugins. If you think a method like the get_files method is good a idea please open an issue on the phile project and we will add it or maybe code it by your self and create a pull request. we have added a method to receive files on a directory, you can use this method like this:

Utility::getFiles(CONTENT_DIR, '/^.*\\'.CONTENT_EXT.'/');

currently we have no login system, but this is planed as a plugin, and sure this login would be available for all other plugins. in the future we will support dependencies for plugins, so you can define your plugin needs an other plugin.

prodigy2m commented 10 years ago

Pico is the next BIG thing. There are lots of file based CMS's around, however, PICO is very clear and focused on simplicity and performance. Our development group found this framework to be on top 10 best. I am looking forward seeing more people using and developing plugins for Pico. Great work. And thanks!

grouchal commented 10 years ago

I've moved on to Jekyll

Snip1 commented 10 years ago

I am currently back to db-centric sols. Anchor is the toy-de-jour.

I rather doubt Pico will be the "next BIG thing"... even the head dev (Gil) isn't particularly interested in it.

On 2014-03-07, at 3:47 PM, prodigy2m wrote:

Pico is the next BIG thing. There are lots of file based CMS's around, however, PICO is very clear and focused on simplicity and performance. Our development group found this framework to be on top 10 best. I am looking forward seeing more people using and developing plugins for Pico.

— Reply to this email directly or view it on GitHub.

james2doyle commented 10 years ago

Phile is a fork of Pico I started with @neoblack

https://github.com/PhileCMS/Phile

On Friday, March 7, 2014, Snip1 notifications@github.com wrote:

I am currently back to db-centric sols. Anchor is the toy-de-jour.

I rather doubt Pico will be the "next BIG thing"... even the head dev (Gil) isn't particularly interested in it.

On 2014-03-07, at 3:47 PM, prodigy2m wrote:

Pico is the next BIG thing. There are lots of file based CMS's around, however, PICO is very clear and focused on simplicity and performance. Our development group found this framework to be on top 10 best. I am looking forward seeing more people using and developing plugins for Pico.

Reply to this email directly or view it on GitHub.

Reply to this email directly or view it on GitHubhttps://github.com/gilbitron/Pico/issues/108#issuecomment-37073941 .

James Doyle

t: @james2doyle https://twitter.com/james2doylew: ohdoylerules.com http://ohdoylerules.com

prodigy2m commented 10 years ago

@james2doyle Nice! I am following Phile CMS now :)