Page administration module

[dartar]

An interface to manage pages and perform several maintenance operations on wiki pages.

Status

beta (code cleanup needed)

Ref

 http://wikkawiki.org/PageAdminAction

Related tickets

• #25 User administration module
• #566 mass reversion handler

[DarTar]

(In [808]) Several modifications to support mass reversions (refs #566):

• Pages are searchable by last edit date in the pageadmin view
• Multiple pages can be selected (perhaps after searching by edit date range) and then be mass-reverted to each page's previous

version

• A new revert handler has been created that reverts a page to its previous version, and also supports multiple page reversions

[DarTar]

(In [809]) Renaming pageadmin to adminpages for consistency with adminusers action, refs #26

[DarTar]

(In [812]) Adminpages cleanup:

• Applying coding guidelines;
• Prefixing constant names to avoid name collision;
• Styling;
• phpdoc header update;

refs #26

[DarTar]

(In [813]) Admin modules:

• Adding todos in phpdoc header;
• Adding missing icons;
• Hiding features yet to be implemented;

refs #25 and #26

[DarTar]

(In [815]) Styling: line-height for filter fieldsets in admin modules, refs #25 and #26

[DarTar]

(In [834]) Adding default pages (AdminUsers and AdminPages) and removing redundant update of FormattingRules, refs #25 and #26 and #562

[DarTar]

XHTML validation: <label for="d"> referes to a non-existent ID

[BrianKoontz]

Suggestion: Add enhanced search functionality that permits searching pages by page content and category. Obviously, not of high priority for 1.1.6.4, just didn't want this idea to get lost...

[DarTar]

(In [854]) Installation of admin modules in 1.1.6.4: - creating new CategoryAdmin for default pages for admin modules; - creating new DatabaseInfo page as a default page for {{dbinfo}}; - setting ACL for AdminUsers, AdminPages and DatabaseInfo to admin-only; refs #25, #26 and #27

[BrianKoontz]

Enhancements for 1.1.6.4 complete. However, there is still work to be done on this, so a new ticket has been created for 1.1.7 (#626). Tests successful using revision 863.

[DarTar]

Brian, it's not completely clear to me how the last edit range filter works, is it possible to filter without filling in the complete timestamp? I tested with something like from 2008 ... to 2008 but the filtering didn't seem to work.

[BrianKoontz]

Replying to DarTar:

Brian, it's not completely clear to me how the last edit range filter works, is it possible to filter without filling in the complete timestamp? I tested with something like from 2008 ... to 2008 but the filtering didn't seem to work.

The time difference between 2008 and 2008 is zero. You'll need a somewhat bigger interval. If you want everything in 2008, then you'll need at least Jan 01 2008.

[DarTar]

(In [904]) Applying styling to edit range form and removing reference to undefined id causing XHTML error, refs #26

[DotMG]

DarTar said: ... removing reference to undefined id causing XHTML error

DarTar, <label> tags improve accessibility in the way that when you click on a label, the corresponding input element (<input>, <select>, <textarea>, ...) gets immediately the focus. For this to work, you need to:

• either add an id attribute for the destination tag, and reference it with a for= parameter on the <label> tag.
• either surround the input element with the label tag (snippet below).

I don't think removing the for="..." is the best solution here, it would break this functionality, leaving the label tag useful just for page structure. As ticket #251 will probably make label tags visually identifiable, I think we should try to make them all have the same functionality. I'd propose to restore the id="..." parameter on the destination field that should get the focus.

On the other hand, too short values for id attribute (here q and d) seem inappropriate for me, as these values should be unique for the page. There is probability that the site owner adds any poorly written javascript code that inserts another element with id attribute going to collision with these.

<label>
  Click on this text or on the input below.
  <br />
  <input name="input0014" />
</label>

[DarTar]

Mahefa, I just removed the reference because the id was not defined and for was probably meant to refer to a set of input fields in the page admin filter form, which is not allowed. I'm all for accessibility and I have been working on adding labels wherever possible in trunk (#388) but in this case it's tricky, in which input should we put the target id?

I agree on short vs. long id's, I think we should aim at least for two-letter id's (one letter variables are  recommended for indices).

[DotMG]

Replying to DarTar:

Mahefa, I just removed the reference because the id was not defined and for was probably meant to refer to a set of input fields in the page admin filter form, which is not allowed. ![...] but in this case it's tricky, in which input should we put the target id?

If the target refers to a set of input fields, I think it's natural that the first of them would get the focus. The first according to document structure, because the user will then probably use Tab key to move to the other fields.

[DarTar]

(In [1001]) Minor issues with adminpage action: XHTML validation (unescaped ampersands), layout consistency in mass reversion, links to revision handler. Added a new class to the stylesheet to display "cursor: help" when needed, refs #26 and #562