Ticket #26 (closed enhancement: fixed)

Opened 9 years ago

Last modified 6 years ago

Page administration module

Reported by: dartar Owned by: DarTar
Priority: normal Milestone: 1.1.6.4
Component: administration Version: 1.1.6.3
Severity: normal Keywords: 1.1.7-ported
Cc: BrianKoontz

Description (last modified by DarTar) (diff)

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

Change History

  Changed 7 years ago by DarTar

  • owner changed from unassigned to DarTar
  • status changed from new to assigned
  • description modified (diff)

  Changed 7 years ago by DarTar

  • status changed from assigned to new
  • milestone changed from 1.1.8 to 1.1.6.4

  Changed 7 years ago by DarTar

  • cc BrianKoontz added
  • status changed from new to assigned
  • version changed from 1.1.6.0 to 1.1.6.3
  • description modified (diff)

(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

  Changed 7 years ago by DarTar

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

  Changed 7 years ago by DarTar

(In [812]) Adminpages cleanup:

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

refs #26

  Changed 7 years ago by DarTar

(In [813]) Admin modules:

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

refs #25 and #26

  Changed 7 years ago by DarTar

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

  Changed 7 years ago by DarTar

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

  Changed 7 years ago by DarTar

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

  Changed 7 years ago by 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...

  Changed 7 years ago by 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

  Changed 7 years ago by BrianKoontz

  • status changed from assigned to closed
  • resolution set to fixed

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.

follow-up: ↓ 14   Changed 7 years ago by 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.

in reply to: ↑ 13   Changed 7 years ago by 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.

  Changed 7 years ago by DarTar

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

  Changed 7 years ago by 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>

follow-up: ↓ 18   Changed 7 years ago by 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).

in reply to: ↑ 17   Changed 7 years ago by 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.

  Changed 7 years ago by 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

  Changed 6 years ago by DarTar

  • keywords 1.1.7-ported added
Note: See TracTickets for help on using tickets.