New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What is the Bolt CMS ethos? #954

Closed
tolusonaike opened this Issue Feb 28, 2014 · 12 comments

Comments

Projects
None yet
5 participants
@tolusonaike

tolusonaike commented Feb 28, 2014

I came across bolt while trying to pick up Silex and i think its awesome. I hope i don't come off as critical, confrontational, or demanding, i am just really excited about this project.

After reading the docs and some open/closed issues, i get this feeling that there is a "developer" guard protecting its functionalities. I wanted to understand Bolt's philosophy by posing a few questions:

  • Does Bolt have a hard-line against a UI for configuration files? (Since this will be a brick wall for casual users. Period.)
  • Will there ever be ability to customise or add Global settings to the backoffice (Site logo, Description, theme options and settings, etc)
  • Will there ever be the ability to manipulate content through "blocks" or widgets through the backoffice

In other words, is Bolt aiming to be THE developer's CMS and nothing else? I know "keep it simple" is a big moto around here...but simple for who?

@bobdenotter

This comment has been minimized.

Show comment
Hide comment
@bobdenotter

bobdenotter Feb 28, 2014

Member

Hi Tolu,

i get this feeling that there is a "developer" guard protecting its functionalities.

If we come off that way, it's merely because we try to stay focused. And with "staying focused" comes "saying no". This is not because we try to discourage contributions (au contraire!!), but we try to streamline efforts, to maintain consistency. If we did not do this, it would get more confusing for the end-user, and nobody benefits from that. Read this interesting article: http://insideintercom.io/product-strategy-means-saying-no/

Does Bolt have a hard-line against a UI for configuration files? (Since this will be a brick wall for casual users. Period.)

Nope, we do not. However we disagree that it's a "hard line". It all depends on who the casual users are. As listed on our frontpage, there are three target audiences:

  • Backend Developers (who know PHP, and assumingly HTML/CSS)
  • Frontend developers (who know HTM/CSS)
  • Editors who know writing content.

We make sure the first two of those groups will be able to set up bolt using FTP, SSH, composer or whatevers. These groups have no trouble whatsoever using yml. In practice, we-the-developers set up Bolt for a client, and the client happily uses it, and in practice never has the need to touch the yml files. And the few clients who do want to do this, have never expressed qualms about the yml files.

Will there ever be ability to customise or add Global settings to the backoffice (Site logo, Description, theme options and settings, etc)

I think so. It's currently not very high on my agenda, but i'm not at all against it.

Will there ever be the ability to manipulate content through "blocks" or widgets through the backoffice

Yes, please!

In other words, is Bolt aiming to be THE developer's CMS and nothing else? I know "keep it simple" is a big moto around here...but simple for who?

We're not even trying to be "THE developer's CMS". There's always the matter of the right tool, for the right job. We're not strving to replace Wordpress for those that like use a blog with a bazillion wonky plugins.. We're not trying to replace Drupal, if you need a complex site with Organic Groups, Faceted / Exposed filters.. But, there's a lot of room in between, and we're firmly placing ourselves there.

Member

bobdenotter commented Feb 28, 2014

Hi Tolu,

i get this feeling that there is a "developer" guard protecting its functionalities.

If we come off that way, it's merely because we try to stay focused. And with "staying focused" comes "saying no". This is not because we try to discourage contributions (au contraire!!), but we try to streamline efforts, to maintain consistency. If we did not do this, it would get more confusing for the end-user, and nobody benefits from that. Read this interesting article: http://insideintercom.io/product-strategy-means-saying-no/

Does Bolt have a hard-line against a UI for configuration files? (Since this will be a brick wall for casual users. Period.)

Nope, we do not. However we disagree that it's a "hard line". It all depends on who the casual users are. As listed on our frontpage, there are three target audiences:

  • Backend Developers (who know PHP, and assumingly HTML/CSS)
  • Frontend developers (who know HTM/CSS)
  • Editors who know writing content.

We make sure the first two of those groups will be able to set up bolt using FTP, SSH, composer or whatevers. These groups have no trouble whatsoever using yml. In practice, we-the-developers set up Bolt for a client, and the client happily uses it, and in practice never has the need to touch the yml files. And the few clients who do want to do this, have never expressed qualms about the yml files.

Will there ever be ability to customise or add Global settings to the backoffice (Site logo, Description, theme options and settings, etc)

I think so. It's currently not very high on my agenda, but i'm not at all against it.

Will there ever be the ability to manipulate content through "blocks" or widgets through the backoffice

Yes, please!

In other words, is Bolt aiming to be THE developer's CMS and nothing else? I know "keep it simple" is a big moto around here...but simple for who?

We're not even trying to be "THE developer's CMS". There's always the matter of the right tool, for the right job. We're not strving to replace Wordpress for those that like use a blog with a bazillion wonky plugins.. We're not trying to replace Drupal, if you need a complex site with Organic Groups, Faceted / Exposed filters.. But, there's a lot of room in between, and we're firmly placing ourselves there.

@tolusonaike

This comment has been minimized.

Show comment
Hide comment
@tolusonaike

tolusonaike Feb 28, 2014

Thanks for the response, just what i was looking for.

We make sure the first two of those groups will be able to set up bolt using FTP, SSH, composer or whatevers. These groups have no trouble whatsoever using yml.

I guess we could consider Bolt Developer-centric then? Btw sorry for the confusion, when i said "Developer" guard i was alluding to "Developer first" behavior.

I guess in my mind the 3rd target audience , the editor, is what i am considering a casual user. I see myself setting up a Bolt site for a client who wants a simple CMS but id hate to hardcode custom data like phone number, address, email,logo inside of the template because there isn't any way to do this from the backoffice. But i see this functionality has been added for yaml #856 and it could probably be added and edited through the menu.

I am also against a bazillion wonky plugins, but at least some custom options (e.g. for the editor) and the ability to provide these custom options ( by the developer, for the editor ) is pretty important in any CMS, even somewhere in between Wordpress and Drupal.

Seriously though, awesome project here.

tolusonaike commented Feb 28, 2014

Thanks for the response, just what i was looking for.

We make sure the first two of those groups will be able to set up bolt using FTP, SSH, composer or whatevers. These groups have no trouble whatsoever using yml.

I guess we could consider Bolt Developer-centric then? Btw sorry for the confusion, when i said "Developer" guard i was alluding to "Developer first" behavior.

I guess in my mind the 3rd target audience , the editor, is what i am considering a casual user. I see myself setting up a Bolt site for a client who wants a simple CMS but id hate to hardcode custom data like phone number, address, email,logo inside of the template because there isn't any way to do this from the backoffice. But i see this functionality has been added for yaml #856 and it could probably be added and edited through the menu.

I am also against a bazillion wonky plugins, but at least some custom options (e.g. for the editor) and the ability to provide these custom options ( by the developer, for the editor ) is pretty important in any CMS, even somewhere in between Wordpress and Drupal.

Seriously though, awesome project here.

@rixbeck

This comment has been minimized.

Show comment
Hide comment
@rixbeck

rixbeck Feb 28, 2014

Member

Hi Tolu,
I think that focusing for Developers is very important first in earlier lifecycle of a sw product. Developers can do later all needs that you mentioned too. If base of the product is strong, flexible and comfortable enough it should be generating many fork that could contains special needs. Bolt is very close to this.

On February 28, 2014 11:42:02 PM CET, Tolu Sonaike notifications@github.com wrote:

Thanks for the response, just what i was looking for.

We make sure the first two of those groups will be able to set up bolt
using FTP, SSH, composer or whatevers. These groups have no trouble
whatsoever using yml.

I guess we could consider Bolt Developer-centric then? Btw sorry for
the confusion, when i said "Developer" guard i was alluding to
"Developer first" behavior.

I guess in my mind the 3rd target audience , the editor, is what i am
considering a casual user. I see myself setting up a Bolt site for a
client who wants a simple CMS but id hate to hardcode custom data like
phone number, address, email,logo inside of the template because there
isn't any way to do this from the backoffice. But i see this
functionality has been added for yaml
#856 and it could probably be added
and edited through the menu.

I am also against a bazillion wonky plugins, but at least some custom
options (e.g. for the editor) and the ability to provide these custom
options ( by the developer, for the editor ) is pretty important in any
CMS, even if Bolt is sitting snuggly somewhere in between Wordpress and
Drupal.

Seriously though, awesome project here.


Reply to this email directly or view it on GitHub:
#954 (comment)

Sent from my Android device with K-9 Mail. Please excuse my brevity.

Member

rixbeck commented Feb 28, 2014

Hi Tolu,
I think that focusing for Developers is very important first in earlier lifecycle of a sw product. Developers can do later all needs that you mentioned too. If base of the product is strong, flexible and comfortable enough it should be generating many fork that could contains special needs. Bolt is very close to this.

On February 28, 2014 11:42:02 PM CET, Tolu Sonaike notifications@github.com wrote:

Thanks for the response, just what i was looking for.

We make sure the first two of those groups will be able to set up bolt
using FTP, SSH, composer or whatevers. These groups have no trouble
whatsoever using yml.

I guess we could consider Bolt Developer-centric then? Btw sorry for
the confusion, when i said "Developer" guard i was alluding to
"Developer first" behavior.

I guess in my mind the 3rd target audience , the editor, is what i am
considering a casual user. I see myself setting up a Bolt site for a
client who wants a simple CMS but id hate to hardcode custom data like
phone number, address, email,logo inside of the template because there
isn't any way to do this from the backoffice. But i see this
functionality has been added for yaml
#856 and it could probably be added
and edited through the menu.

I am also against a bazillion wonky plugins, but at least some custom
options (e.g. for the editor) and the ability to provide these custom
options ( by the developer, for the editor ) is pretty important in any
CMS, even if Bolt is sitting snuggly somewhere in between Wordpress and
Drupal.

Seriously though, awesome project here.


Reply to this email directly or view it on GitHub:
#954 (comment)

Sent from my Android device with K-9 Mail. Please excuse my brevity.

@tolusonaike

This comment has been minimized.

Show comment
Hide comment
@tolusonaike

tolusonaike Mar 1, 2014

I wouldn't consider something like basic Backoffice settings extensibility a special need though, I think its required. Especially if Bolt is trying to be somewhere between Wordpress and Drupal.

I do like the fact that Bolt is doing it right from the beginning, so they don't cause a concussion like Drupal 7 to Drupal 8.

tolusonaike commented Mar 1, 2014

I wouldn't consider something like basic Backoffice settings extensibility a special need though, I think its required. Especially if Bolt is trying to be somewhere between Wordpress and Drupal.

I do like the fact that Bolt is doing it right from the beginning, so they don't cause a concussion like Drupal 7 to Drupal 8.

@bobdenotter

This comment has been minimized.

Show comment
Hide comment
@bobdenotter

bobdenotter Mar 1, 2014

Member

A good example of this is the MenuEditor extension, by the way. It takes the menu.yml file, allows the user to drag'n'drop the changes, and writes it back to .yml. This is ideal, IMHO: people who prefer yml can use it, people who like dragging/dropping can use it, and it is still stored in a readable text-based format that can go into your versioning system. :-)

Member

bobdenotter commented Mar 1, 2014

A good example of this is the MenuEditor extension, by the way. It takes the menu.yml file, allows the user to drag'n'drop the changes, and writes it back to .yml. This is ideal, IMHO: people who prefer yml can use it, people who like dragging/dropping can use it, and it is still stored in a readable text-based format that can go into your versioning system. :-)

@tobias2k

This comment has been minimized.

Show comment
Hide comment
@tobias2k

tobias2k Mar 3, 2014

Contributor

Indeed.

YAML is the configuration file format of choice, because:

  1. It is simple
  2. A good PHP implementation exists
  3. It maps well onto PHP data structures, especially the kind we need in
    Bolt
  4. It is utterly human-readable
  5. It is text-based, so we get a few hundred (if not more) excellent
    mature tools for free to edit, manage, compare, search, version-control
    and otherwise process our configuration files.
  6. We can provide a reasonable UI in the form of an HTML textarea with a
    "Save" button.
  7. Easy to keep forward- and backwards-compatible
  8. Comment syntax means we can (and do) provide self-documenting
    configuration files

We could still make fancier UIs on top of that, or (I think @bobdenotter
would prefer that) find an existing structural web-based YAML editor and
hook that up with Bolt, but as it stands, I don't think the benefit
would outweigh the cost.

On Sat, Mar 01, 2014 at 04:37:01AM -0800, Bob den Otter wrote:

A good example of this is the MenuEditor extension, by the way. It takes the menu.yml file, allows the user to drag'n'drop the changes, and writes it back to .yml. This is ideal, IMHO: people who prefer yml can use it, people who like dragging/dropping can use it, and it is still stored in a readable text-based format that can go into your versioning system. :-)


Reply to this email directly or view it on GitHub:
#954 (comment)

Tobias Dammers - tobias@twokings.nl - 070-3457628 - www.twokings.nl
Maandag t/m donderdag van 9.00 tot 17.30
Voor dringende vragen, mail naar support@twokings.nl

Contributor

tobias2k commented Mar 3, 2014

Indeed.

YAML is the configuration file format of choice, because:

  1. It is simple
  2. A good PHP implementation exists
  3. It maps well onto PHP data structures, especially the kind we need in
    Bolt
  4. It is utterly human-readable
  5. It is text-based, so we get a few hundred (if not more) excellent
    mature tools for free to edit, manage, compare, search, version-control
    and otherwise process our configuration files.
  6. We can provide a reasonable UI in the form of an HTML textarea with a
    "Save" button.
  7. Easy to keep forward- and backwards-compatible
  8. Comment syntax means we can (and do) provide self-documenting
    configuration files

We could still make fancier UIs on top of that, or (I think @bobdenotter
would prefer that) find an existing structural web-based YAML editor and
hook that up with Bolt, but as it stands, I don't think the benefit
would outweigh the cost.

On Sat, Mar 01, 2014 at 04:37:01AM -0800, Bob den Otter wrote:

A good example of this is the MenuEditor extension, by the way. It takes the menu.yml file, allows the user to drag'n'drop the changes, and writes it back to .yml. This is ideal, IMHO: people who prefer yml can use it, people who like dragging/dropping can use it, and it is still stored in a readable text-based format that can go into your versioning system. :-)


Reply to this email directly or view it on GitHub:
#954 (comment)

Tobias Dammers - tobias@twokings.nl - 070-3457628 - www.twokings.nl
Maandag t/m donderdag van 9.00 tot 17.30
Voor dringende vragen, mail naar support@twokings.nl

@tolusonaike

This comment has been minimized.

Show comment
Hide comment
@tolusonaike

tolusonaike Mar 3, 2014

But i love YAML :-)

My main things where

  • UI for config files (Yes, YAML)
  • Ability to add custom config that are editable through the back office

Presumptions like:

  1. It is simple
  2. It is utterly human-readable

...scare me though :-) But yes, YAML is a great underlying configuration format

tolusonaike commented Mar 3, 2014

But i love YAML :-)

My main things where

  • UI for config files (Yes, YAML)
  • Ability to add custom config that are editable through the back office

Presumptions like:

  1. It is simple
  2. It is utterly human-readable

...scare me though :-) But yes, YAML is a great underlying configuration format

@tobias2k

This comment has been minimized.

Show comment
Hide comment
@tobias2k

tobias2k Mar 3, 2014

Contributor

On Mon, Mar 03, 2014 at 05:53:40AM -0800, Tolu Sonaike wrote:

But i love YAML :-)

My main things where

  • UI for config files (Yes, YAML)

I don't sense a lot of opposition here, it's more a matter of manpower
and cost vs. benefit.

  • Ability to add custom config that are editable through the back office

That would be nice, I guess. I don't see any principal show stoppers for
exposing the textual YAML editor we already have for other config files;
the only thing worth giving a thought here is security. You really don't
want to expose a text editor that can put arbitrary text files in
arbitrary locations, for a whole lot of reasons, so this would have to
be properly whitelisted and checked.

Presumptions like:

  1. It is simple
  2. It is utterly human-readable

...scare me though :-) But yes, YAML is a great underlying configuration format

Well, the subset we're using is. Of course YAML has dark corners...


Reply to this email directly or view it on GitHub:
#954 (comment)

Tobias Dammers - tobias@twokings.nl - 070-3457628 - www.twokings.nl
Maandag t/m donderdag van 9.00 tot 17.30
Voor dringende vragen, mail naar support@twokings.nl

Contributor

tobias2k commented Mar 3, 2014

On Mon, Mar 03, 2014 at 05:53:40AM -0800, Tolu Sonaike wrote:

But i love YAML :-)

My main things where

  • UI for config files (Yes, YAML)

I don't sense a lot of opposition here, it's more a matter of manpower
and cost vs. benefit.

  • Ability to add custom config that are editable through the back office

That would be nice, I guess. I don't see any principal show stoppers for
exposing the textual YAML editor we already have for other config files;
the only thing worth giving a thought here is security. You really don't
want to expose a text editor that can put arbitrary text files in
arbitrary locations, for a whole lot of reasons, so this would have to
be properly whitelisted and checked.

Presumptions like:

  1. It is simple
  2. It is utterly human-readable

...scare me though :-) But yes, YAML is a great underlying configuration format

Well, the subset we're using is. Of course YAML has dark corners...


Reply to this email directly or view it on GitHub:
#954 (comment)

Tobias Dammers - tobias@twokings.nl - 070-3457628 - www.twokings.nl
Maandag t/m donderdag van 9.00 tot 17.30
Voor dringende vragen, mail naar support@twokings.nl

@tolusonaike

This comment has been minimized.

Show comment
Hide comment
@tolusonaike

tolusonaike Mar 3, 2014

It is simple...for developers. Non developers (and even some developers) have an irrational fear of text configuration files. We developers forget that not everybody sees the blonde,brunnette,red heads http://www.youtube.com/watch?v=3vAnuBtyEYE

I think YAML is an optimal choice. I guess i am trying to make a case for prioritising UIs for config files (sometime in the future maybe)

tolusonaike commented Mar 3, 2014

It is simple...for developers. Non developers (and even some developers) have an irrational fear of text configuration files. We developers forget that not everybody sees the blonde,brunnette,red heads http://www.youtube.com/watch?v=3vAnuBtyEYE

I think YAML is an optimal choice. I guess i am trying to make a case for prioritising UIs for config files (sometime in the future maybe)

@GawainLynch

This comment has been minimized.

Show comment
Hide comment
@GawainLynch

GawainLynch Mar 3, 2014

Contributor

I'll reserve the redhead, if no one has objections... 👍

I too would like to see an easier approach for some things, but @tobias2k is correct, some of this stuff takes a lot of work for a questionable ratio of benefit and we don't want to open security holes, as much fun as they are for trolling your co-workers with.

I think Bob made a good point earlier about the parts of the backend that need raw YAML editing should not be exposed to end users anyway... An example being a management type doing this without telling anyone:
branding: name: MyCoolestCSM path: /blondes2myroom

...all of a sudden network admin are being yelled at by marketing as http://example.com/bolt/ no longer lets them log on and do work. :-)

Contributor

GawainLynch commented Mar 3, 2014

I'll reserve the redhead, if no one has objections... 👍

I too would like to see an easier approach for some things, but @tobias2k is correct, some of this stuff takes a lot of work for a questionable ratio of benefit and we don't want to open security holes, as much fun as they are for trolling your co-workers with.

I think Bob made a good point earlier about the parts of the backend that need raw YAML editing should not be exposed to end users anyway... An example being a management type doing this without telling anyone:
branding: name: MyCoolestCSM path: /blondes2myroom

...all of a sudden network admin are being yelled at by marketing as http://example.com/bolt/ no longer lets them log on and do work. :-)

@tobias2k

This comment has been minimized.

Show comment
Hide comment
@tobias2k

tobias2k Mar 3, 2014

Contributor

Well, I can see a use case for privileged editors changing content
types; I'm not sure how that would fit into the existing model though.
After all, it's fairly easy to wreak at least moderate havoc just by
editing that one file...

On Mon, Mar 03, 2014 at 06:53:38AM -0800, Gawain Lynch wrote:

I'll reserve the redhead, if no one has objections... 👍

I too would like to see an easier approach for some things, but @tobias2k is correct, some of this stuff takes a lot of work for a questionable ratio of benefit and we don't want to open security holes, as much fun as they are for trolling your co-workers with.

I think Bob made a good point earlier about the parts of the backend that need raw YAML editing should not be exposed to end users anyway... An example being a management type doing this without telling anyone:
branding: name: MyCoolestCSM path: /blondes2myroom

...all of a sudden network admin are being yelled at by marketing as http://example.com/bolt/ no longer lets them log on and do work. :-)


Reply to this email directly or view it on GitHub:
#954 (comment)

Tobias Dammers - tobias@twokings.nl - 070-3457628 - www.twokings.nl
Maandag t/m donderdag van 9.00 tot 17.30
Voor dringende vragen, mail naar support@twokings.nl

Contributor

tobias2k commented Mar 3, 2014

Well, I can see a use case for privileged editors changing content
types; I'm not sure how that would fit into the existing model though.
After all, it's fairly easy to wreak at least moderate havoc just by
editing that one file...

On Mon, Mar 03, 2014 at 06:53:38AM -0800, Gawain Lynch wrote:

I'll reserve the redhead, if no one has objections... 👍

I too would like to see an easier approach for some things, but @tobias2k is correct, some of this stuff takes a lot of work for a questionable ratio of benefit and we don't want to open security holes, as much fun as they are for trolling your co-workers with.

I think Bob made a good point earlier about the parts of the backend that need raw YAML editing should not be exposed to end users anyway... An example being a management type doing this without telling anyone:
branding: name: MyCoolestCSM path: /blondes2myroom

...all of a sudden network admin are being yelled at by marketing as http://example.com/bolt/ no longer lets them log on and do work. :-)


Reply to this email directly or view it on GitHub:
#954 (comment)

Tobias Dammers - tobias@twokings.nl - 070-3457628 - www.twokings.nl
Maandag t/m donderdag van 9.00 tot 17.30
Voor dringende vragen, mail naar support@twokings.nl

@tobias2k

This comment has been minimized.

Show comment
Hide comment
@tobias2k

tobias2k Oct 7, 2014

Contributor

Closing this issue, I think we're done discussing this one. Feel free to reopen if things are still unclear.

Contributor

tobias2k commented Oct 7, 2014

Closing this issue, I think we're done discussing this one. Feel free to reopen if things are still unclear.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment