Textpattern Support Forum

Gocom wrote:

The selection buttons (none, range, all) could be replaced with something better. Keyboard navigation would be amazing for example. None and all could serve well as a checkbox placed to the table head row (would be ideal location imo) and range selects can be replaced with shift click (which isn’t hard to implement thanks to jQuery).

Isn’t that already partly implemented on the sections tab ? And unless I misunderstood what he said in the other thread, Bloke plans to remove the ‘all’ and ‘none’ buttons soon – and implemented that across all panes.

The go button gets pretty confusing to users. On these forums we have some reports where users have no idea how to use the multi-edit thing, which is unfortunate. That’s most likely due to the button, which doesn’t make clear that some of the actions take multiple steps. To make the thing somewhat clear, I would suggest showing that button on the second step. If no second step is needed, the action (e.g. delete) can be done on change.

Yeah, in combination with my suggestion upthread, that might help some people.

Better to wait what Bloke has in his sleeve. If he needs me, I’m here. Doesn’t make much sense to write something for the current structure if it gets changed.

During last night and this morning I sketched up some code for it. Needs some major cleaning up still and gotta find some sort of way to make its method members accessible from outside while keeping multiple instance support intact. Probably means removing some of the caching too.

What it does is:

• Adds shift click support for selecting ranges. Also has toggle for selecting all/none via a checkbox.
• Extends checkbox selecting to the row itself. Clicking any empty space on the row selects the checkbox (excluding any interactive control, i.e. link, input and takes bubbling into account).
• Tracks checkbox checks via change event, and adds highlight class to the checked row.
• Works with rows added via Ajax or on later events (derp caching).
• Supports multiple instances (i.e. doesn’t use IDs, does all targeting within single container).
• The current poweredit() function that hosts the multi-edit actions is implemented as objects attached directly to the <options>. This means that set HTML element(s) from the page can be attacked to a option (see below).

Bloke wrote:

One thing that’s always bugged me, btw, is that generating the multi-edit dropdown options in txplib_head are a mess. I would prefer a nicer system of adding the options which is extensible by plugins via callbacks. If that’s part of your vision then please do what you can. I’ll roll it out across the core once the dust has settled.

For example on the new Section’s panel the multi-edit markup with the new functionality looks like this;

<p class="multi-edit">

<select name="edit_method">
	<option value="" selected="selected">With selected...</option>
	<option value="changepage">Uses page</option>
	<option value="changecss">Uses style</option>
	<option value="changeonfrontpage">On front page</option>
	<option value="changesyndicate">Syndicate</option>
	<option value="changesearchable">Include in site search</option>
	<option value="delete">Delete</option>
</select>

<div class="multi-option" id="multi-option-changepage">
	<select name="page">
		<option value=""></option>
		<option value="default">default</option>
		<option value="error_404">error_404</option>
	</select>
</div>

<div class="multi-option" id="multi-option-changecss">
	<select name="css">
		<option value=""></option>
		<option value="bootstrap">bootstrap</option>
		<option value="default">default</option>
		<option value="formalize">formalize</option>
		<option value="styles.min">styles.min</option>
	</select>
</div>

<div class="multi-option" id="multi-option-changeonfrontpage">
	<input type="radio" id="on_front_page_0" name="on_front_page" value="0" class="radio" />
	<label for="on_front_page_0">No</label> 
	<input type="radio" id="on_front_page_1" name="on_front_page" value="1" class="radio active" checked="checked" />
	<label for="on_front_page_1">Yes</label>
</div>

<div class="multi-option" id="multi-option-changesyndicate">
	<input type="radio" id="syndicate_0" name="syndicate" value="0" class="radio" />
	<label for="syndicate_0">No</label> 
	<input type="radio" id="syndicate_1" name="syndicate" value="1" class="radio active" checked="checked" />
	<label for="syndicate_1">Yes</label>
</div>

<div class="multi-option" id="multi-option-changesearchable">
	<input type="radio" id="searchable_0" name="searchable" value="0" class="radio" />
	<label for="searchable_0">No</label> 
	<input type="radio" id="searchable_1" name="searchable" value="1" class="radio active" checked="checked" />
	<label for="searchable_1">Yes</label>
</div>

<input type="submit" value="Go" />
</p>

Obviously as it uses stored objects, it can work directly via JavaScript (or PHP wrapper of sorts) too. E.g. along the lines of:

$('form').txpMultiEditForm('addOption', {
	'label' : gTxt('delete'), 'value' : 'delete', 'html' : null
});

Well, or could once I get those methods to work outside their given context while keeping multiple instance support. Makes my brain hurt. txpMultiEditForm is rather long name, eh.

Great stuff. I’d been planning to find out what modernizeTextpattern was exactly, and it sounds exciting. I’ll stay out of this for the moment unless needed – I’m working on the installation pages section so that won’t mess with any of your plans.