Add ability to pre-define classes and choose them from a drop-down

Greetings Todd,

Please take a look at this patch created by one of our developers. We found it quite useful and simple. In most cases clients want to be able to specify the desired class for certain block themselves. Since adding a class means changing CSS file there is no need to give them textfield where they can enter whatever they want. This also can become a reason of mistakes.

Instead, we propose to predefine classes and give a user friendly name for each class. Than a client can simply choose the desired class from a dropdown list.

Your thoughts?

ershov.andrey and ardas: Thanks for all your work. This kind of improvement has been on our roadmap for a long time, but due to the release of Skinr and its promise, we decided to work on other stuff.

That said, our original plan was to include selectable classes in the theme's .info file (much like Skinr does). Please check out the 6.x-2.x-dev branch of the module to see our work thus far.

Selectable classes is a feature we'd love to have, and I'd like to work with both of you to figure out the best way forward. Do you have some time to evaluate the .info method contained in the 6.x-2.x-dev branch?

Also, we found that handling subthemes was tricky. I'm pretty sure we made a lot of progress in that area, but it's not clear from my initial skimming of the patch whether your solution allows the inheritance of selectable classes from base themes.

I'm against this idea for the simple reason that it makes it more difficult to find a class when searching for one in your site's source code.

IE: If I name a block myself, I can find it again easily if I need to view its source code or the CSS file. If a machine names my classes, and I am forced to use that name, I may not easily remember it to find it in 500+ lines of CSS or HTML source.

If this is implemented, let the module pick a name for me if it likes, but allow me to change it in the block settings as it is now if I choose.

gregarios: Maybe I'm missing something, but I don't think ershov.andrey and ardas are proposing that the Block Class module choose a class name on behalf of the user. Rather, they seem to be suggesting what we've already started building into the 6.x-2.x branch of the module: Allowing the site maintainer to predefine certain available classes that can be chosen from a drop-down list.

Of course, the method employed in 6.x-2.x is a bit different than what ershov.andrey and ardas are suggesting. Our changes allow both predefined classes from a drop-down and a text field to add more classes on the fly. The predefined classes are found in the theme's .info file.

If you have some time, I'd love to hear anyone's feedback on these changes to the 6.x-2.x branch, which should satisfy everyone's needs.

I see... As long as custom classes are still possible with a text-field, them I'm fine with a selectable drop-down list. I guess I misunderstood the #1 & #2 comments. I kinda got fuzzy after seeing "Since adding a class means changing CSS file there is no need to give them textfield where they can enter whatever they want." (-;

Not sure if this is really on topic, but if we at least had the ability of giving a human-readable name to a created block, rather than being stuck with block-block-1, it would be a great help.

msypes: The naming of blocks has nothing to do with this module. That's all handled by the Block module (block.module) in Drupal core.

The naming convention used for blocks is actually rather intuitive once you understand it: block-MODULE_NAME-DELTA. Custom blocks, which are created by the block module, are therefore named block-block-X, where X is the number of the block. Blocks created by the User module are named block-user-X, blocks created by the Twitter module are named block-twitter-X, and so on.

Guys,

Since, we did lots of websites for different clients from various countries I can tell you about our experience with this issue. All clients want to have a simple drop down list on the block configuration page to be able to switch between different styles. They don't want to have it as a textfield since they don't know what to enter. They need a human friendly names of their classes. On the other hand we don't give them permissions to change skinr classes and any other skinr settings since they afraid of big amount of different fields and many nested fieldsets.

So, we came to the following decision:

1. We need just one field to switch class for the block on the block configuration page.
2. This field must be controlled by its own permission (don't mix with other permissions in order not to give superfluous rights to the client)
3. This field must be a drop down list with human readable names (may be even multiple list to choose several classes)
4. Developers must have an ability to setup classes and their names from within admin area (to quickly install Drupal build for the website), no changes in the code.
5. Sometimes we don't use skinr because clients require maximum performance and they provide their own HTML which is better to use directly without any other heavy modules like skinr.

This is why we proposed this solution.
So, why not to keep skinr integration but still have our idea implemented for situations like I described? Let's think together.

Thanks.

Just want to add that block_class functionality is not only for developers but for client admins (which are usualy site editors) also. This is why we think it must be very simple and clear for non technical people.

P.S. We have problems teaching clients to use Drupal core block and menu admin pages. When they see skinr fields they have panic :)

I'm moving this request to the 2.x-dev branch, which long ago started moving in this direction. It's languished for awhile, though, so hopefully we can revive it.

Todd,

I would like to propose you our help in maintaining this module.
ershov.andrey and me work in Ardas Group Inc (www.ardas.dp.ua) and have been working with Drupal for about 5 years.

Block Class module is used in all our web sites, we included it into our own Drupal build and it is quite important for us now.

If you agree to add us as maintainers we can guarantee not to do anything without your approval.

Todd?

Subscribing, interested in the development of this.

ardas: Are you still interested in working on the 6.x-2.x (and perhaps 7.x-2.x) version of this module that includes these changes?

Hi Todd,

Our clients again suffer from having no way to flexibly change styles since they don't know which styles to set... they want to just choose them from drop down list with user friendly names... so we are back to this problem. I saw a few other requests similar to this and ready to implement this feature in 7.x-2.x.

I also think it is a good idea to make either multiselect or a set of checkboxes (in most cases we don't have much classes).

A configuration form will be available to developers (low level permission) and block configuration form is available to site managers/editors (Administer blocks) as always so site managers can't manage classes since this will require attention of developers/themers.

Your thoughts?

Putting this to 7.x. The 6.x branch won't see many more updates I predict...

Ardas, I also like the idea. The available classes should be listed in the theme's .info file (as it needs css support), and perhaps we need an alter hook, so others can add more classes.

I think we should stick with a select though. Checkboxes will only wreck havoc, so you would need a setting, etc.

this is one awesome idea.
it would be great if a user can define multiple dropdowns. that would allow some stuff like
"color", "font", "widget-style" so a user can style a block with some classes the admin defines

I have a working sandbox module called "Block Class Select" which allows administrators to predefine classes for end users configuring blocks to have access to.

https://drupal.org/sandbox/jeni_dc/1899728

Included in the module is an administrative page to define the classes, permissions for defining available classes and assigning classes to blocks, as well as an additional permission to allow individuals to add classes in the default Block Class textfield.

This allows someone building the site (me), to predefine classes that a client or end user can assign, since they wouldn't normally have access to, or understand, CSS. The use of an additional permission to enter classes into the default textfield also allows me (or other site admins) to add one-off classes or other classes easily into the default textfield, without the other users messing with them.

My module is dependent on Block Class and I developed it against 7.x-1.2, so it hasn't been tested at all against the latest 2.0 release which recently came out. (Not good planning on my part!) But I do plan to test against the 2.0 release and make any necessary changes to make sure it works.

I just thought I'd mention it here since given the amount of time this issue has been open as well as #268557: Predefining available classes. I was planning to apply for full project access soon for this module, but would like some feedback from the Block Class maintainers on this.

Hi guys,

Thanks very much to everyone for crusading on this issue and for all the great work.

I'm sorry for getting back to this issue so late, but it actually took me a while to go through the issue queue.

It would seem indeed like a great feature and I would be glad to try to help moving this forward.

To quickly roll back on what was discussed up to this point and from what I understood, please allow me to sum up some of the major aspects:

Storage: Where would the pre-defined classes be stored?

• In a special theme file, in this case .info, see #16:
  

  The available classes should be listed in the theme's .info file (as it needs css support), and perhaps we need an alter hook, so others can add more classes.

  [But we might want to add to that the ability to read/parse classes from a CSS file (provided a path is configured, for example).]

• In the database (not specifically defined), for example in a configuration variable, see #8, point 4:
  

  4. Developers must have an ability to setup classes and their names from within admin area (to quickly install Drupal build for the website), no changes in the code.

Widget/Selection/Labels: How could the classes be selected (including by a client admin user)?

In terms of widget, I would assume the field could be a multiple select dropdown list, which could be further enhanced with something like Chosen, Multiselect, Improved Multi Select, jQuery selectBox, Autocomplete Deluxe, etc...
If we wanted to support a very large amount of CSS classes to be displayed, we could potentially consider using some kind of AJAX autocomplete, for example.

Another aspect of the discussion was around the ability to specify human readable labels for certain classes, see #8, point 3:

3. This field must be a drop down list with human readable names (may be even multiple list to choose several classes)

Moving forward: How could something concrete result from these discussions?

I have taken a closer look at @jeni_dc's sandbox module Block Class Select and it appears it could be a very good starting point to move this feature request forward since it actually seems to fulfill all the requirements from the issue summary or #8.

The only feature that's not already provided by Block Class Select from the requirements summed up above in this comment, is the ability to define classes in a file [Storage], pulling the classes from a special theme file, .info or CSS file, for example.
Otherwise it would seem to achieve all other requests that have been made in this ticket so far.

In short, to answer the questions above for Block Class Select:

• Where would the pre-defined classes be stored?
  In the database, in a configuration variable that is set through an admin settings form.
• How could the classes be selected (including by a client admin user)?
  Ability to provide human readable labels per class, displayed in a multi-value dropdown select. Adds an additional dropdown so the text field is still available and overrides the css_class class when settings are saved (fields are synced, for the user).

 
Therefore, at this point, I would like to suggest the following approaches:

1. Merging Block Class Select with Block Class:
   We discuss potentially integrating this feature to the Block Class module, in which case more work would be needed in this issue and in Block Class Select issue tracker.
   For example, we could add a checkbox on the Block Class Select Settings form page to enable or disable the Block Class Select widget. It could be disabled by default when the Block Class module is enabled, which would be a rather unobtrusive way to add this feature.
    
2. Not merging Block Class Select with Block Class:
   After discussion, if it is decided not to merge this feature in Block Class, we could update project's page to provide a link to Block Class Select and let users know Block Class could integrate and be extended with this interesting functionality. Another link to this issue could bring users to the reason why this feature is not part of the module. In this case, we could probably consider this issue settled.

 
If the first approach was to be chosen, we could certainly consider building on top of these new features to provide the ability to read from a predefined CSS file (all classes would be parsed from a custom CSS file and could be displayed with JS/frontend autocomplete with one of the modules mentioned above, for example) or a specific theme file, such as from theme's .info file (skinr style).

I would greatly appreciate if you could please give me some feedback on what you would think would potentially be the most appropriate way this issue could move forward?

Personally, I couldn't necessarily find reasons why the second approach should be chosen (cons) and would be favorable to see this feature integrated to Block Class (first approach), main reasons being (pros):

• [Performance] No overhead on front-end class display process, changes would only impact the back-end and more particularly the options and select displayed on block configuration forms.
• [User Experience] It seems to be a rich feature to provide as an extension of the module to enhance user experience, in particular for client admins.
• [Contrib] Most of the initial code could already be provided by Block Class Select.

Overall, the impact on the module would be low while providing a rich new feature.
 

Please let me know if I forgot, missed or overlooked any other potential solution or aspects/requirements mentioned in previous comments, I would greatly appreciate to hear any suggestions, ideas or recommendations for a suitable approach.

Feel free to let me know if you would have any questions, comments or concerns on any aspects of this comment, I would surely be glad to provide more information or explain in more details.

Special thanks to @jeni_dc for the follow-up, great contribution of the Block Class Select module and all the hard work!
Thanks very much in advance to everyone for your questions, feedbacks, testings, reviews, ideas and comments.
Cheers!

Thanks, @DYdave! Glad that my module can help! Going forward here's a bit of background and some thoughts on moving on.

I'd be fine with either merging Block Class Select (BCS) into Block Class (BC), or leaving it as a second module. Here are my thoughts on both approaches:

1. Merging
   If this was merged I would want this as a secondary module to be enabled instead of just a checkbox on the BC settings page. In my own usage I don't need Block Class Select very often, but I use Block Class a lot. I guess it's just the way I end up building my sites, so others mileage may vary. It just makes more sense to me to not even think about BCS. So the way I see it if I can leave off one module on my site so be it. But if BCS could be implemented better as a part of BC, then I'm all for it.
2. Not merging
   To me this makes it easier to roll out additional features to BCS while leaving BC untouched. My thoughts on additional features for this included more options for customisation of the block form (location, as a vertical tab, etc) and multiple groupings of classes (For example, three selects: one for font colour, one for background color and one for border style). This would allow for people to use the existing functionality now, while additional features are being worked on. Then maybe down the line they get merged.

The history of me writing BCS was that I thought I could use it for a site I was working on at the time, and actually only discovered this thread when I was thinking of submitting BCS for approval as my first contrib module. But then someone informed me of Block Class Styles, which looked like it did the same thing so I stopped working on BCS.

I only recently installed Block Class Styles and it seems to do everything BCS does, and more, so in the end I'm actually not sure if BCS needs to be around at all! There were a few errors with BC 2.0, but I think as of today they have been fixed.

BCS does have the additional permissions which Block Class Styles doesn't have, but then again those permissions could end up a part of that module, or BC.

I really like the Block Class module, as well as Node Class and I just created a patch for it here https://drupal.org/node/2229045
I ported that patch to Block Class since I believe it'd be really helpful here too.

I didn't change anything around the way data is stored. And by default everything should work exactly the same, so jeni_bc, you don't really have to choose to use one or the other. It's just a variable_set which is changing the UI. That's about it.
The other modules like Block Class Styles are doing a lot. I feel like they're doing too much. I like Block Class because it's really lightweight, and works as expected out of the box.

I don't have a label|key setup, I don't load classes from some css file or anything like that. I'm just using pre-existing values, or a pre-defined list of classes.
I feel that'd be a great improvement to block_class without adding tons of extra code/tables/etc.
Loading classes from a CSS file, or storing key|values data are really specific use-cases, and really should belong to an other module which could be called "Advanced Block Class" for example.

What do you think?

+1, nice patch -- I found this after finding your patch for node_class and both are very useful additions. It needs to be reviewed by 2 people before it can get committed, if someone is interested in using this improvement please review here.
Works as advertised for me.

Should change patch to modify the block_class_admin_form() function (added #state) and remove the .js file.

+  $form['block_class_predefined_values'] = array(
+    '#type' => 'textarea',
+    '#title' => t('Predefined values'),
+    '#default_value' => variable_get('block_class_predefined_values', ''),
+    '#description' => t("Enter a list of classes separated by a space, comma, or line-break."),
+    '#states' => array(
+      'visible' => array(
+        ':input[name="block_class_source"]' => array('value' => 'predefined'),
+      ),
+    ),
+  );

Class names could be defined in the (sub)theme .info file

Hi guys,

Thanks a LOT to everyone for following-up on this issue and I sincerely apologize for the delay of this reply.

Rolling back to #20:

Thanks a lot @jeni_dc for your great and very nice comment!
I'm so sorry for answering so late, but yeah.... I think you had the situation very well clarified already at that point.

I only recently installed Block Class Styles and it seems to do everything BCS does, and more, so in the end I'm actually not sure if BCS needs to be around at all!

Indeed, this is most likely going to be the suggested solution on which we're going to settle for this feature request.
Since your last comment, so much time has gone by and the features of Block Class Styles have been growing as well as its user base, strengthening its identity, thus putting more and more distance with Block Class.
It looks like Block Class Select has completely been absorbed by Block Class Styles, which now also provides more features.

@Stanto and patch #21:
Thanks a lot for your contribution and submitting this great patch.

I have tested the patch and made a few changes, among which the one from #25 and moved the block_class_admin_form to its block_class.admin.inc file.
Please find attached to this comment an updated version of the patch from #21, against block_class-7.x-2.x at d4c1d8c.
File attached as: block_class-predefined_classes_dropdown-665012-27.patch.

I feel that'd be a great improvement to block_class without adding tons of extra code/tables/etc.

My feelings are really conflicted on this patch and feature.....

On one side, I believe it would be a great addition to the Block Class Styles module, especially with the autocomplete feature, which I think doesn't exist yet. In other words: doesn't necessarily belong in the Block Class module.

On the other side, I would kind of agree that this version is rather "light" in terms of the impact on the existing code:
We'd be mostly adding stuffs to the backend (site building process) which wouldn't impact front end display in production.
We'd be adding 2 menu items, 1 admin config page and 3 system variables.
So yeah... I would agree on the careful changes made by this patch.

However, I think a lot of users, mostly themers, like the fact that block_class is such a simple, straightforward and lightweight module. On top of that, I would also be concerned with the overlap of this patch with the Block Class Styles module....

I don't know.... I'm very divided on this, very open to a dialog and others' opinions.

How about we give the new patch a bit more time and see users feedback?!
If enough interest is shown for this feature and no particularly critical objections are made, I guess we could perhaps consider having it added to the module.
Thanks again @Stanto for the idea and contribution.

Feel free to let me know at anytime if you would have any further issues, questions, objections, suggestions or concerns on any aspects of this comment or attached patch, I would certainly try answering as soon as possible and providing more information.

Thanks again very much to everyone for your testing/reporting, comments and participation in this module's issue tracker.
Cheers!

The 3 year old patch in #27 does not apply to the latest 7.x-2.x dev
snapshot and may be too old to reroll, but I went ahead and tagged the issue accordingly.

Checking patch block_class.admin.inc...
Checking patch block_class.install...
Checking patch block_class.module...
error: while searching for:
 */

/**
 * Implements hook_permission().
 */
function block_class_permission() {

error: patch failed: block_class.module:11
error: block_class.module: patch does not apply