search

e107inc / e107

e107 Bootstrap CMS (Content Management System) v2 with PHP, MySQL, HTML5, jQuery and Twitter Bootstrap. Issue Discussion Room: https://gitter.im/e107inc/e107
https://e107.org
GNU General Public License v3.0
321 stars 213 forks source link

Bootstrap Color Picker! #1267

Open septor opened 8 years ago

septor commented 8 years ago

We have a datepicker (that works basically as well as I do). Why not a color picker too?

Here's one that looks pretty swell: https://github.com/mjolnic/bootstrap-colorpicker/

xoxo

Moc commented 8 years ago

Personally I doubt that this is a plugin which will be used by many plugins (let alone in core).

I feel that it should therefore not be included in core but instead up to the plugin developers to implement it into their own plugin, which should be easy (if not, then THAT is what needs to change :)

septor commented 8 years ago

I personally have 2 plugins that could benefit from this right now, and a few that I have planned that would benefit from it. I can think of instances where it would come in handy for theme developers as well. Example:

You create a theme with customizable elements, which would (maybe?) require you to create a plugin as well that allows the user to pick the colors they want to use. Maybe you want to limit them to Bootstrap colors (success, danger, warning). How amazing would it be if you could allow them to just pick whatever colors they want without having to leave the area?

For now, a textbox works where users just enter the hexcodes, but that's not very user friendly and I can't see a point in including this into each of my plugins and having to worry about conflicts popping up because it's called 50 times.

Moc commented 8 years ago

Hmm, you've convinced me. Listed as enhancement :)

septor commented 8 years ago

I'd normally agree that adding more bloat to the core is a bad idea, but I think this is a broad enough thing that more than just the 6 people that use my plugins will get benefit out of it.

LaocheXe commented 8 years ago

Not only is it broad enough but also look at other CMS's out, most popular one is WordPress and they have a method to edit the theme without editing the core files, and not only that but plugins that can even enhance that - to add more customization to the theme.

You take Simple Forum Machine - they have it so you can edit the theme files threw the admin area and have a screen (iframe) up top so you can see your changes live.

However this could be a simple easy plugin with a theme that allows that type of customization to be done and look for values for the theme through site pref's.

willem010 commented 8 years ago

if it's optional.. yeah.. could come in handy. but please keep it optional. maybe create a plugin for this?

Moc commented 8 years ago

There are great functionalities already present for theme options/customisation. Unfortunately they are not used at the moment in any theme, nor are they documented.

I'm working on a theme which uses these functionalities.

willem010 commented 8 years ago

cool. keep us posted. (Y)

septor commented 8 years ago

Firstly, I think this is going in a tangent. I'm not concerned about the complexity of theme creation. I used it as an example to point out the broadness and usefulness of this request.

@willem010 An optional form type? Aren't they all? I think you misunderstand what I'm asking for.

You can allow people to enter a date in a textbox, or you can use the datepicker. Both achieve the same thing but one allows the user an easier way to send the data.

This has no relevance to the end user (you). If you are using a plugin chances are the creator of a plugin gave you the option to use the datepicker over the textbox because it was easier. Plus, the data you can send is now limited to what the datepicker pushes and not what you could enter into a textbox.

A colorpicker form type would allow for me to ask you to enter a color you want something to be and you be able to select it from a dropdown component instead of researching a hexcode to enter. It requires no more effort on my part, and now makes using my plugin for you a lot easier.

willem010 commented 8 years ago

@septor maybe i do get you wrong. All i'm trying to say is, there are a lots of scripts in a default install, half of which isn't really used. (i didnt check last version, so it might be better on later versions ;) ) this can be an issue on sites with huge numbers of visitors.. where every bit counts. i'm not against new functions. i just want to keep the option of a clean site without clutter. that's all.

Moc commented 8 years ago

Well all the css and js that is not used on a particular page, should not be called on that page. This counts for all added scripts such as the datepicker. Those should never be included by default on all pages but only there were necessary/used (e.g. $frm->datepicker).

If this does happen then it should be fixed.

septor commented 8 years ago

The inclusion of a colorpicker won't affect your current e107 installation unless one of your current plugins, or a plugin you install in the future, utilizes the colorpicker.

It will only ever be called if it's requested. As @Moc said, things should only be called if they are needed.

CaMer0n commented 8 years ago

@septor, can't you just include the js and css in your plugin and then use the input ID as the selector? (datestamps are used extensively throughout the core, color selection not at all, unless I've forgotten something).

septor commented 8 years ago

@CaMer0n Sorry it took so long to reply, I forgot about this!

Yeah, I could. But for reasons mentioned above I don't see the point in adding it to each plugin I want to use it on. It could cause conflicts or make me have to work harder to check if it's already loaded.

I think I'm going to just throw together a quick plugin that loads the required file, then just add an if/else clause to my stuff and if said plugin is installed utilize the colorpicker otherwise use a textbox. Anyone interested in this can follow the progress here: https://github.com/septor/bootstrap-colorpicker

I'm going to close this since it's probably not going to make it into the core!

lonalore commented 8 years ago

Well, (in my opinion) the best solution would be if it were possible to define new field types by third-party plugins, then these field types were available from the core e107::getForm(). So, in my opinion, e107 should provide a solution for the expansion of the methods in e_form class, e.g. with addon file (e_fields or e_form).

@CaMer0n This would be feasible?

rica-carv commented 7 years ago

I also personally agree that the colorpicker should be a core field option, for admin ui, since i'm currently having a hard time on making on work on the admin menu manager ui.... Right now the admin fields are too much "rigid", and lacking flexibility, something the old one was...

CaMer0n commented 7 years ago

type=method should provide all the flexibility you would need to make this work.