Theme System - Missing Vital Functionality

[Tom Christian]

I have spent a lot of time experimenting with the plugin system in IPS4 and I think it's wonderful. Truly great. 

However, recently putting that aside and concentrating on the theme system, I strongly believe that it is lacking and must be reviewed before 4.0.0 is launched.

 

Inability to re-order theme settings

Unless I'm mistaken, there's no way of re-ordering theme settings. My themes will have a ton of settings and the inability to re-order them is laughable.

 

No way of finding the setting keys

Go to the "Edit" page of a theme and look at the settings. There's no way of seeing the setting key even with designer_mode/in_dev enabled. The only way is by trawling through pages of settings in the "Custom Settings" list (which requires designers mode to be enabled). I already created a topic regarding this two months ago but nothing has changed.

 

Localization

How do I implement and ship custom localization in my themes? From what I can tell, the only way is to manually add language strings to a language pack and export that and ship it my themes which is absurd. Why is there not something similar to the lang.php file like in the plugin system? 

 

Setting Limitations

Why is the theme setting system so limited? I have to build an entirely separate plugin with a single input field to ship with all of my themes just so I can make use of the validation callback functionality.

The theme setting system could be so much more powerful if it had the same freedom as the plugin / form helper system. I'm guessing the reasoning was that you want to make the theme settings system easy to implement for the less-experienced which is great but at the same time it's utterly killed huge amounts of potential for those of us that actually want to build new functionality.

 

Inability to add Javascript and Fonts

There is no official way of loading a Javascript file or making use of font-face in the theme system unless piggy backing the image include template syntax ( {image="myFeature.js"} ). I would like to see an implementation which doesn't re-invent the wheel. Why can't we use the excellent implementation used everywhere else in the suite (seen below) but tailored towards the theme system? 

<div class="myFeature" data-controller="plugins.myFeature"></div>

At the very least, just let us use a regular script call and deal with the consequences (which we can't currently as there's no template syntax to target the theme folder AFIK).

 

-------------------------------

 

I apologize if I've come across as rude but it completely bemuses me how the plugin system can be so excellent and the theme system so lacking. I feel the potential is there and huge leaps have been made from the IPB3 system but several improvements need to be made if this system is going to rival IPS' competitor offerings.

Thanks,

Tom.

 

 

[Tom Christian]

I've reported the first issue as a bug because from a theme development perspective, it practically renders the theme setting functionality useless. Maybe an IPS Staff member could comment whether it's possible to manually re-order setting keys from the database as I'm going to assume this won't be addressed until a future release of IPS4.

[WOFman]

I tried to experiment with the theme system and crashed my test forum. I had to re-install a new test forum.

[Tom Christian]

I tried to experiment with the theme system and crashed my test forum. I had to re-install a new test forum.

​You should submit a bug report regarding this then. This thread is focused on feedback.

[Mark]

These are some good ideas, we'll take a look into these  

[Flitterkill]

We brought up the font/js stuff in the alpha site and someone on staff was going to "think on it" - that's not meant as a dig; just to note it's been out there for awhile.

All we need really is a duplicate of the image system already present in the theming section. The functionality is already there. Dupe it twice. Fonts. JS/misc. Done! (Or conversely change it to a single add-ons pile to handle fonts, images and js, etc. and manage the rest internally)

Without this though and skin packs are almost certainly going to have to be more than just a single portable xml file unless as Tom pointed out above we start using the image section in an un-intended manner.

[Charles]

Actually the font/JS inclusion is the easiest suggestion of all those to implement  

[Cabola]

would be awesome with a js/jquery include ability, so if you're making a little side bar hook you could make it use a jquery feature and include it easily from a file!!

[Tom Christian]

would be awesome with a js/jquery include ability, so if you're making a little side bar hook you could make it use a jquery feature and include it easily from a file!!

​The plugin system allows Javascript / jQuery to be written and packaged within the hook.

[Mark]

Almost all of these have been implemented for Beta 6.

 

When managing your theme settings, you'll see them tabbed just as the end user will and can reorder them. This also provides an easy way to see all your settings and get the setting keys.

 

When in designer mode, you'll notice a lang.php file in the theme directory, just lie for applications and plugins, which you can use to define language strings to go with your theme. The "title" field when creating a setting will advise you to use this.

 

We want it to be really easy for designers to add theme settings even without programming experience. To manage this balance, I've made it so you can use the pre-defined field types just like now, or you can alternatively provide the PHP code to create a form field which will allow you to provide custom validation code, etc.

 

Also in beta 6, the concept of "images" has been renamed to "resources" and can be used for images, fonts, theme-specific javascript, etc. You'll still use it in the same way, except with {resource="file.ext"} rather than {image="file.ext"} and the files will be in a "resources" folder rather than an "images" folder.

[Tom Christian]

One word: awesome.

[Flitterkill]

Spectacular all around!

IP.Pages could maybe use some of that custom field type love as well (unless I'm missing that functionality somwhere...)

 

[BomAleold]

When managing your theme settings, you'll see them tabbed just as the end user will and can reorder them. This also provides an easy way to see all your settings and get the setting keys.

Is also available a preview of values on this list? (to have a rapid impact on colour for example)

​

[OsmanK]

Yes suggestions are quite nice. I think it would be better with a later version.

[Tom Christian]

Yes suggestions are quite nice. I think it would be better with a later version.

​Why would you want them in a later version?

As Mark already said, they'll mostly be in Beta 6.

[OsmanK]

You misunderstand me. I wanted to tell you anyway beta 6 version. 

[Tom Christian]

Three more ideas:

Theme Settings Usability

 

Ability to add setting headers

Like with plugins, the ability to have something that replicates addHeader('My Header'); would make tabs with many settings a lot more readable.

 

Ability to add setting descriptions

I understand that you want to keep settings compact and let the title describe the setting but some settings simply need further description. At the moment, I'm bypassing this limitation by creating settings manually with PHP but the ability to simply supply a "settingName_desc" in lang.php would be perfect.

[ehren.]

The "difference report" feature in 3.4.x is fundamental when upgrading themes, and seems to have been removed in 4.x. I mentioned this in a topic else where, but since this topic also deals with missing functionality, I figured I'd mention it here too.

I've upgraded from RC1 to RC3 with no knowledge on what html or css files require updates.