mindplay.dk

@ryan - I wanted to display the icons on the template admin page as well, since with a large number of templates, it's useful to have an overview of the icons you're currently using. Unfortunately, the ProcessTemplate::___execute() hook is not very useful: foreach($this->fuel('templates') as $template) { $notes = ''; if($template->flags & Template::flagSystem) { if(!$filterSystem && !$filterField) continue; $fieldset->collapsed = Inputfield::collapsedNo; $notes .= $this->_x('system', 'list-note') . ' '; } if($filterField && !$template->fieldgroup->has($filterField)) continue; if($template->useRoles) $notes .= ' ' . $this->_x('access', 'list-note'); if(!$template->filenameExists()) $notes .= ' ' . $this->_x('no-file', 'list-note'); $table->row(array( "{$template->name} " => "edit?id={$template->id}", $template->label, $template->getNumPages(), count($template->fieldgroup) . ($template->fieldgroup->name != $template->name ? " {$template->fieldgroup->name}" : ''), $notes )); } Perhaps another hook could be added, like ___addTemplateRow() or something: function ___getTemplateRow($table, $template, $notes) { return array( "{$template->name} " => "edit?id={$template->id}", $template->label, $template->getNumPages(), count($template->fieldgroup) . ($template->fieldgroup->name != $template->name ? " {$template->fieldgroup->name}" : ''), $notes ); } } I don't know if that's very versatile or clever - perhaps you can think of a better way to do this? I would hate to have to resort to something like parsing/searching the HTML snippet...

This is what I was referring to. But anyhow, I decided to go the more adventurous route and learn how to build an Inputfield-type - I haven't attempted to use my icon-selector with a Field on a Template yet, but my hope is that the icon-selector and preset color-picker would be useful for more than just the TemplateDecorator itself. To me, this is one of the most important values in ProcessWire: the idea of building small, reusable features - as opposed to large, self-contained concepts... I believe this is the core reason why platforms such as Drupal or WordPress need hundreds of similar modules for the same things, to satisfy everyone - when you build out an entire concept, it's set in stone, and it doesn't fit everyone's needs, so every shop-module (for example) addresses a slightly different set of needs. When we provide the building-block features instead of self-contained concepts, this enables the developer to rapidly apply those features to solution-specific concepts. The module-concept in most other CMS suffer (by design) from what I've been calling "conceptual lock-in" for some years now - PW doesn't suffer from this, and as such will hopefully see smaller numbers of more lightweight and generic modules, from which developers can design the concepts. (sorry for side-tracking, but I had to put that in writing!)

It just doesn't feel right somehow - throwing away the model and keeping the markup. It might work in this particular case, but it doesn't seem like a good long-term solution for modules where you might want to keep a form open to extension - once you've rendered the field, it's no longer mutable. Just feels like a work-around to me... The extra Inputfields would be useful for whatever you want to use them for, same as any other Inputfield - for example, you could add icons or preset color-pickers to your own templates, e.g. for front-end. Icons might be useful e.g. for menus on a site, or icons on download-links, etc. Mostly I'm just doing it as rehearsal - teaching myself more about PW... and it can't do any harm, so why not?

Regarding installation, I tried the following: public function ___install() { $this->default_icon = 'page.png'; $this->icon_adminRootPageID = 'config.png'; $this->icon_trashPageID = 'trash.png'; $this->icon_http404PageID = 'bug.png'; $this->show_template = true; } Didn't work. Any ideas? EDIT: figured it out public function ___install() { wire('modules')->saveModuleConfigData($this->className(), array( 'default_icon' => 'page.png', 'icon_adminRootPageID' => 'config.png', 'icon_trashPageID' => 'trash.png', 'icon_http404PageID' => 'bug.png', 'show_template' => true, )); }

Did some tweaks to the master branch today, and tagged version 1.0.3 - you may consider this the first "stable" release, if you please I also started a 1.0.4-dev branch, in which I've refactored the icon-selector into an Inputfield-type, which you can actually install and use without installing the TemplateDecorator, if you like. It works, but needs a better UI, probably a popup for the icon-selector, since it takes up a lot of space. (thoughts?) As mentioned, I also plan on refactoring the preset color-picker into an Inputfield-type - and when that's done, I will probably add support for the existing RGB color-picker, which I won't personally use for this, but it would be easy to support, so why not I also plan on getting some sleep tonight

I'm not sure I fully understand how this works yet, but now your icon selector is no longer part of the form - it's just being rendered and the markup gets inserted somewhere. Does that work? Will it still get processed properly, initialized with it's value and updated on POST and so forth?

Thanks for your input, Soma. For now, I decided to simply fork your theme and get rid of the icons - I did two commits on a fork here, one that removes the icons, and another that renders the lock/unlock icons in black. (note that there's also a "key" icon in PW PageList module, which does not appear to be in use??) I don't want my module to contain workarounds for any specific themes - if other themes add icons or something else, going down that path leads to increasing maintenance effort. I agree, separate icons for states that are already reflected by typography or opacity, not necessary. It would be nice to have icon choices for the "system" pages though - e.g. admin, trash, etc... although I suppose you could already turn on display of "system" templates and simply add the icons to them? So perhaps this is not needed at all. Might be nice if the installer configured those for you on install though - I looked into that, but I'm not sure how to configure a module at install... (is that possible?)

In an ideal world, I would agree - however, this has a number of drawbacks: Icon fonts are not widely available, and do not support colors. From my understanding, there's also a dependency on fairly new browsers. There may be licensing issues. But perhaps most importantly, creating or editing fonts is not something that most people know how to do - there are few, highly specialized designers that have the tools and talent to create fonts correctly this way. Bitmap icons, on the other hand, are widely available, and there are plenty of (free) tools to create and edit them, and it does not require hard-earned skills. By the way, bitmaps do scale down nicely in most browsers - monochromatic PNG compress extremely well, so you could accomplish something similar in terms of scalability, using higher-resolution PNGs. If I cared enough to find out, this would be the approach I would pursue

@Soma what do you think about adding custom icons for home, trash, hidden, unpublished, etc. to this module? This would complete the remaining icon logic from your admin-theme. For the default icons, I like the ones you're using because they're gray - so I could pull those in and make them the standard icons if you'd like. You could then retire the icon-functionality from the theme? Seems almost like functionality/logic - it's bordering on a "feature", perhaps more so than just look and feel. Perhaps this kind of thing is better left to modules than to themes? I'm asking your (and others) opinion here, not trying to dictate anything

Pushed up another update, integrating some of your suggestions - cleaned up some redundant hooks, made the CSS file global so the Page List Inputfield displays correctly, added lots of documentation. I decided to add @see annotations to every hooked method - this documents for every method which method in ProcessWire it's hooking. Seems really logical - enables those with an IDE to click through directly to the hooked method. Perhaps this should be considered "mandatory" practice when writing modules?

It also decorates the page editor - and all the decorations are template-specific. But yeah, either name would work I think I should wait and add it to the directory after the next PW release, since it works only with the dev-branch at the moment - it would raise too many questions if released now.

TemplateBadges is now TemplateDecorator. I've pushed up a new version with some new features - it now has a configuration screen where you can configure a default icon. I've included a "blank" and a simple "page" icon which are good choices for default icons. There is also an option to display the template name when editing a page. The tab is now called "Decorations", and has an added field for directions - if you add directions, they will display near the top of the "Content" tab, when editing a Page with that Template. The Github page is open to submission of issues - post'em if you got'em. Note that this was tested with the current dev-branch of PW, and works without modifications.

Looks like ryan is upgrading jQuery

I have no immediate plans to downgrade code to an older version of jQuery - I'm in no hurry, so I'll wait for PW to receive an upgrade. I'd rather not downgrade code now, and then have to upgrade it again when a newer version of jQuery is integrated. I think your theme is one of the only ones that have icons? That was one of the first reasons I liked it ... it's probably a quick fix for someone who doesn't want them, to remove the icons from the theme? - ideally, I guess the theme should provide an option? (or you could ship the current icon functionality, with the theme, as an optional plug-in)

I'm not sure what you mean, but I would accept a pull request

Absolutely - removing it was not at all what I was suggesting. It should be there for backwards compatibility. The Post class is solely for IDE reflection - it will never be loaded. It's declared as "extends Page" in order to also provide IDE reflection for inherited Page methods and properties.