Admin Side Theming! (r3149)

TheEric · 2009-07-25 06:11:19

No, what I’m saying is that if I’m going to insert something somewhere as a plugin-writer, I expect the markup to be the same from theme to theme. The differing markup is going to make it that much harder. You don’t need to restyle the HTML for every single theme (e.g., look at csszengarden.com.) With properly classed/id’d html, all that needs to be changed is the CSS. I think the direction it’s going is entirely wrong.

TheEric · 2009-08-03 04:56:30

Noticed: The more the things change, the more they’re the same.

jm · 2009-08-03 05:35:51

TheEric wrote:

No, what I’m saying is that if I’m going to insert something somewhere as a plugin-writer, I expect the markup to be the same from theme to theme.

The only way to have markup consistency in 4.2 is to create it yourself through pluggable_ui(). However, you’ll still have differing displays based on the theme, so plugin authors will need to be explicit about their styling for inserted elements. It’s another step:

4.0.x:

Inject JS into <node>

4.2.x:

Create the target HTML node
Inject JS into <node>

The differing markup is going to make it that much harder. You don’t need to restyle the HTML for every single theme (e.g., look at csszengarden.com.) With properly classed/id’d html, all that needs to be changed is the CSS.

I think pluggable_ui() provides some much needed admin hooks (thanks wet), but I wholeheartedly agree with you about the overall admin-side themes (which are distinct from pluggable_ui()).

wet · 2009-08-03 05:44:44

I can see no way to address this: The whole purpose of admin themes is to provide custom markup, so in theory you cannot rely on any constant markup if a theme author chooses to throw all conventions overboard. So all we (i.e. the community of TXP coders) can do is establish a set of conventions and stick to them. Period.

TheEric · 2009-08-03 06:12:46

Is there going to be any sort of standardized HTML in the admin, or are theme writers going to go willy nilly and use whatever HTML they feel like? From what it looks like there isn’t going to be any sort of standard and THAT is going to create a problem when trying to place items throughout the page. Let’s use an example from EBL Image Edit :

$("#list td:first img").attr('id','mainImg'); // Give our image an ID
$("#list td:first").attr('id','mainImgTD'); // name the table to make it easier to find.

The above jQuery looks for the first instance of a TD tag following #list and assigns the image found an ID so that further on, the script can manipulate it. It does the same with the TD cell in which it resides.

The above works because the code is standard between all TXP installations. If this code changes based upon theme, am I going to have to create varying fixes for those themes, or will I just have to tell users to figure it out themselves?

I think a standardized HTML markup is an absolute necessity for theme writers to base their themes on. Well thought out HTML can be changed to infinite variations through CSS.

jakob · 2009-08-03 07:48:12

The above works because the code is standard between all TXP installations. If this code changes based upon theme, am I going to have to create varying fixes for those themes, or will I just have to tell users to figure it out themselves?

Not really a solution but two things might minimise the ocurrence of problems:

Sufficient admin theme documentation with a pattern to follow for admin theme authors together with a notice urging admin theme authors to follow this pattern or risk incompatabilities with plugins.
Plugin authors could comment their code to say something like // if using a non-standard theme, change this jquery directive to match your theme so that one can edit the plugin as necessary to fit a theme (I do this for example with glz_custom_fields. very simple.). Maybe this could be stored in a string and placed at the top of the plugin code as an explicitly user-editable block…

wet · 2009-08-03 07:53:34

Frankly, I cannot find the method how a theme author would be able to modify the markup you mentioned with the way admin themes are implemented. What am I missing?

TheEric · 2009-08-03 14:12:26

Standard Markup that doesn’t change is a necessity. To change the look, you do NOT need to change the HTML. Just style it differently via CSS. It’s NOT complicated, eh?

wet · 2009-08-03 15:48:49

Let me rephrase: Admin-side themes do not and can not change the markup you mentioned because there simply is no way to do. Read the source.

TheEric · 2009-08-03 16:00:08

Remora

Classic

Different markup per theme.

wet · 2009-08-03 19:24:23

With the Classic theme, the image detail tab has this markup around the full-size image:

<table cellpadding="0" cellspacing="0" border="0" id="list" align="center" class="edit-pane">
<tr>	<td><img src="http://example.com/images/8.jpg?1238418503" height="375" width="500" alt="" title="8.jpg (500 × 375)" id="image-fullsize" /><br />

<form method="post" enctype="multipart/form-data" action="index.php">
[...]

Switching to Remora renders it this way:

<table cellpadding="0" cellspacing="0" border="0" id="list" align="center" class="edit-pane">
<tr>	<td><img src="http://example.com/images/8.jpg?1238418503" height="375" width="500" alt="" title="8.jpg (500 × 375)" id="image-fullsize" /><br />

<form method="post" enctype="multipart/form-data" action="index.php">
[...]

Every other theme using the theme engine would render it this way:

<table cellpadding="0" cellspacing="0" border="0" id="list" align="center" class="edit-pane">
<tr>	<td><img src="http://example.com/images/8.jpg?1238418503" height="375" width="500" alt="" title="8.jpg (500 × 375)" id="image-fullsize" /><br />

<form method="post" enctype="multipart/form-data" action="index.php">
[...]

All three exhibits work as intended with the sample plugin code given here (although I think it’s superfluous as Textpattern 4.2.0 identifies the full-size image with its own id to help plugin authors find a proper DOM hook):

$("#list td:first img").attr('id','mainImg'); // Give our image an ID
$("#list td:first").attr('id','mainImgTD'); // name the table to make it easier to find.

TheEric · 2009-08-03 20:57:31

Clarification

I’m glad it’s only the header and footer that can have theme dependent willy-nilly code (though I still think it’s stupid and that the switching code-class is a lot of wasted effort) I will still only support one theme.
I don’t currently have any plugins that currently make use of the header/footer, though ebl_quicknote was going to have a new message notification in the header. I’ll reexamine that and place it somewhere else as hopefully obvious.

All three exhibits work as intended with the sample plugin code given here (although I think it’s superfluous as Textpattern 4.2.0 identifies the full-size image with its own id to help plugin authors find a proper DOM hook):

Yah well, I asked multiple times before the release of 4.0.8 for an ID in those fields, and yet the simple act of adding the id was deemed superfluous and not added.

Textpattern CMS

Textpattern CMS support forum

#133 2009-07-25 06:11:19

Re: Admin Side Theming! (r3149)

#134 2009-08-03 04:56:30

Re: Admin Side Theming! (r3149)

#135 2009-08-03 05:35:51

Re: Admin Side Theming! (r3149)

4.0.x:

4.2.x:

#136 2009-08-03 05:44:44

Re: Admin Side Theming! (r3149)

#137 2009-08-03 06:12:46

Re: Admin Side Theming! (r3149)

#138 2009-08-03 07:48:12

Re: Admin Side Theming! (r3149)

#139 2009-08-03 07:53:34

Re: Admin Side Theming! (r3149)

#140 2009-08-03 14:12:26

Re: Admin Side Theming! (r3149)

#141 2009-08-03 15:48:49

Re: Admin Side Theming! (r3149)

#142 2009-08-03 16:00:08

Re: Admin Side Theming! (r3149)

#143 2009-08-03 19:24:23

Re: Admin Side Theming! (r3149)

#144 2009-08-03 20:57:31

Re: Admin Side Theming! (r3149)

Board footer