Move out of Development into Appearance

[philsward]

General thoughts on moving the functionality into a place that is more accessible and makes a bit more sense, namely the Appearance area.

Since this deals with themes, Appearance is the first place I would go to look for it. Development or anywhere inside the configuration area would be my last guess had I not noticed the README.

That said, renaming the module to something that takes out the 'devel' namespace might be warranted also.

[klonos]

I would also be in favor of this, thinking that the word "devel" and it being under "development" might a) hinder tis discovery (although we do have the "Create subtheme" link in the Appearance page) and b) discourage some people from using it, thinking that it is a developer-only tool.

@docwilmot since the module has been decoupled from the devel module, and there's no official release for it yet, should we just call it "Subthemer"?

[docwilmot]

I'm thinking that it is unlikely that anyone would search for "subthemer" but likely to search for "Devel" and this module would be more discoverable by leaving the name. Furthermore it is a development tool, so I think it belongs in that category on the menu.

[philsward]

@docwilmot since it's viewed as a dev tool, I'm assuming it doesn't have permissions implemented to view/hide it from respective roles? (I didn't get around to checking)

[stpaultim]

I am still interested in merging this with the devel module someday, but as previously mentioned - that is really between the maintainers of the respective modules. I just think that they are for similar audiences and we could reduce the need to find and install two modules when they might work together better.

I agree that it is a development module and am fine where it appears in the menu structure. The functionality is already available under "appearance" when you view your list of themes - which I think is really nice.

Thanks.

[docwilmot]

Ping @jenlampton Devel maimtainer

[jenlampton]

and b) discourage some people from using it, thinking that it is a developer-only tool.

Well, it is a developer-only tool. Let's not forget that theme developers are developers!

I'd be happy to merge this with the devel module if others agree that would be a good place for it (I think it is!)

@docwilmot would you be willing to come on as a maintainer for devel, to continue maintaining the subthemer module?

[philsward]

Still not liking the devel requirement.

Themers are not always developers. It is not a dev tool, it is a theming tool.

You don't have to be a "developer" to copy/paste folders and files in the filesystem, nor edit a CSS file.

I have installed devel on maybe 2 out of 100 sites. I have custom themed 100 sites. I do not in any way, shape of form call myself or consider myself a developer.

To me, this is a tool for site builders. Developers are generally site builders but site builders aren't always developers.

[jenlampton]

You don't have to be a "developer" to copy/paste folders and files in the filesystem, nor edit a CSS file.

As soon as you edit one line of code (yes, even copy/pasting CSS) -- you are a developer. After copy/pasting 100s of lines of CSS code, you will find that you have a very marketable skill for web development :)

I have installed devel on maybe 2 out of 100 sites.

There are a lot of very useful tools in devel for theme developers! I could not create a custom theme without my faithful dpm() function -- just so I can see what the heck I'm supposed to be styling. Also the "devel" tab on nodes, I find that really useful for theme development too.

I have custom themed 100 sites. I do not in any way, shape of form call myself or consider myself a developer.

Well, you should! :) If you can create a theme, you are a developer. In the real (non-Drupal) world, this skill is called being a "front-end developer". Drupal "developers" like to look down on "themers" and classify them as being non-developers, but we don't do that here. All theme developers are developers for Backdrop!

[stpaultim]

@jenlampton beat me.

I primarily use the devel module to help me with my theming.

I install the devel module on pretty much every site I build, but for 90% of those sites I don't use it for anything other than the following two settings - which are themer specific.

By merging these modules, MOST us would only have to install a single module to get all the cool theming tools, rather than having to install two.

I'm not sure what the advantage is of NOT installing Devel, even if for only the one tool. But, I am pretty confident that once you have the devel module installed you will use it for more than just the create sub-theme feature.

It seems as if your primary objection is the name of the module - and I'm not sure why that is such a problem. I certainly consider writing css as developing and the devel module helps me write my css.

[stpaultim]

since it's viewed as a dev tool, I'm assuming it doesn't have permissions implemented to view/hide it from respective roles? (I didn't get around to checking)

I'm not sure why that assumption. I believe that all the devel tools have permissions like most other features. It looks like Devel Subthemer also has those same permissions and can be made available to whatever roles you choose.

[philsward]

Y'all may have some good points I'm just not familiar with. I'm open to checking devel out from a theming standpoint.

What about... Instead of making it a dependency on devel, leave it as a standalone but do a check for devel.

If devel isn't installed, the menu link is in appearance. If devel IS installed, the menu link shows up in the devel menu.

Just an idea.

Maybe another idea is to have it live in devel land but add links and menus in the appearance area over to the devel area? (make it easier to access from the theme area)

I'm getting outweighed here which is fine, but I'd hate to see this pidgin-holed to a specific use-case. I have a feeling it has potential to be used by more folks than just theme devs.

[olafgrabienski]

I'm also not using Devel, even if I build (develop) themes. I'd probably be okay to install Devel for the Subthemer, but would be more happy with a standalone module and a non develish name. No strong feelings however, just wanted to make clear that Phil isn't the only one who has a particular perception of Devel.

[docwilmot]

Must say didnt expect any resistance, I thought everyone used Devel! 😄 I'm happy to leave this as a standalone module for now and revisit the possibility of merging if its still a popular request in the future. I think as said before keeping the Devel name will at least make it more discoverable.

[philsward]

For the record, I'm good either way.

Whatever is decided will be great. 😁

[stpaultim]

I am also very surprised that this is an issue. I would have expected that anyone doing very basic theme development would be familiar with and regularly using the devel module. I consider the devel module to contain some essential tools for basic theming, which is why I advocated for adding this functionality there. I was trying to avoid a situation where two different modules would be required by everyone, when one should suffice.

If basic themers don't know that the devel module is intended for them, potentially because of the name, that is a larger problem. For me the goal is to get tools that I think are critical for even basic themers into their hands as easy as possible. I THOUGHT that this would be accomplished by adding this feature to devel.

It sounds like we either need to do a better job of educating themers on the value of the devel module, convincing themers that they are developers, or think about another way to deliver some of these features so that users will find them and use them. It might be an argument for including them in core (just when my opinion was moving in the other direction).

I suspect that renaming the devel module isn't very practical and might cause more confusion than it resolves.

NOTE: I consider themers to be developers, but I am using the term themers, because clearly that is how many of them perceive themselves in this discussion and I would like them to feel included in this discussion.

[philsward]

Based on @stpaultim comments, is it worth unbundling the theming portion from devel?

I guess the question would be: "how many people are only using devel for theming?" The best answer to that might come from telemetry some day which is worth a completely different discussion down the road. Food for thought.

On a side thought, those of us in the boat of not calling ourselves developers, this is how I view it: "I can change a tire, I can change the oil, I can replace an alternator, but I wouldn't ever call myself a mechanic." Just because I can manipulate some CSS or copy and paste some code, doesn't make me feel or believe I'm on par with someone who has more knowledge and experience. Maybe someday, but not today.

[jenlampton]

is it worth unbundling the theming portion from devel?

Separating theme-developer-tools from developer-tools makes no sense to me. Not only is it impractical (since most of those tools are the same tools) but it also reinforces the concept that theme developers are not "real" developers. Not only does that go against our values -- but in general we need less "us" vs "them" in the world.

Fun facts:

• When I was hired at Chapter Three, I applied for (and was given) a front-end developer position. And, one of my first tasks was integrating with the Flickr API.
• Nate was a front-end developer when he started working with Drupal.
• So many Drupal core developers were also once "only" front-end developers.

HTML / CSS / JS are the languages that are consistent across all web development platforms. Anyone that is new to Backdrop but has experience in "web development" will most likely already have these skills. Anyone who is a front-end developer is perfectly capable of doing anything a back-end developer can do. The only difference is where we choose to specialize. It's a very strange place to draw a line. It's all the same thing at the end -- we make pages with markup on them that browsers render :)

[olafgrabienski]

I agree that we shouldn't draw lines between 'only' front-end developers and 'real' backend developers. And I call myself anyway a web developer, even if I don't have programming skills (nor PHP neither JavaScript btw). So, that's not the point in my opinion.

Regarding the concrete discussion, it's just that I don't use Devel for the time being. I've tried it some time ago to enable Theme debug mode, and then I discovered it can also be enabled changing one line in a system configuration file. However, with new features like the Subthemer added to Devel (or, if my needs change), I'm open to use the module. On the other hand, I don't understand why it is promoted so strongly, as if it were the default tool for frontend-development. There are other independent modules like CSS Injector, which show that a useful frontend-dev tool doesn't have to be part of Devel. I see the advantages of integration, but I also see advantages of having a small independent module which just does its specific job.

That all said, I still don't have strong feelings regarding a decision. Still fine with both approaches.

[philsward]

It doesn't really matter what people think of themselves or call themselves. What matters is "what will make the most sense to most people".

I still believe this is a tool that should be shipped with core some day. If this goes in and devel doesn't, what then?

I guess where I'm coming from is that I would like to see big aspirations for bringing more theming elements into the GUI, including sub-theming. Elements that anyone can appreciate at almost any experience level. Moving to dev assumes a certain level of experience which is what I thought the goal was to move away from.

[philsward]

This is the targeted audience I think of when I made this suggestion.

https://forum.backdropcms.org/forum/review-webmaster-not-programer

[docwilmot]

Keeping as standalone for now.