{5} Assigned, Active Tickets by Owner (Full Description) (16 matches)

The tag management interface is not coherent. Here are the problems:

1) There is a form above the main list of tags. It shows "Older", a search(?) box, and "Newer" but it is not clear to what these things refer. Clicking in the search box there does nothing.

2) Clicking on a tag, the user expects to view posts that are tagged with that specific tag. Instead, the tag link "activates" the tag phrase for modification or deletion. This is not intuitive at all.

Recommendation:

Doing things with AJAX calls is fine, but the interface needs to have some semblance to what people "are used to" in web interfaces. I recommend putting the tags into a table that has a checkbox for marking tags for deletion, and an input box where the tag's text can be changed.

Future improvements:

Allow for tags to be "merged" together. This is useful for typos, etc.

Check out admin/groups. The page needs a UI design and its backend implementation needs to be updated for the new ACL system.

Currently you can either simply type in the search filtering commands manually, without help, or you can press the 'buttons' underneath the search bar on the manage pages.

I would like to help build a system that throws out the buttons and replaces it with an auto-complete system.

It would work like so: When you click the search bar, your cursor is placed in it as per usual, and below the field, a box with the available filter commands drops down. This would contain stuff like author, date, content, state, type and so on. You can either use the arrow keys/mouse to select on, or start typing. As you type, the ones that aren't matching what you're typing will be filtered out.

Once you have a filter command, like for instance 'state:', another list drops down, namely with the values available for that command, like unpublished, deleted, published, draft and so on. Now you can select one of those.

This will make the system nearly infinitely extensible, fast and elegant to use while remaining relatively user-friendly.

I'll work on a design suggestion asap.

Refering to the manage page or manage entry section of the admin screen. When you are searching for something using the search bar, and then hit the 'X' clear button, then select another value, (draft, published, scheduled, entry or page), the search box updates to reading "Type and wait to search for any entry component status:published".

As a side note, when you hit the 'x' clear button, it should un-select that search values selected.

Often (mainly in WP-land) one will, after several years, have thousands of entries in their options table. Most of these options are left over from plugins long since deactivated.

The common opinion seems to be that, upon deactivation, a plugin should delete anything it added during its lifetime. For options and configuration data this is no major loss and can easily be re-created, should the user need.

While working on the plugin directory plugin, I was uncertain how far to take this approach. On deactivation, should it delete all plugin directory entries? That could be a lot of data (read: thousands of custom posts) to be lost accidentally.

After a discussion in IRC, it seems the best idea may be to add a 'delete data' checkbox when deactivating a plugin. This would sorta emulate the Drupal deactivate vs. uninstall functionality.

For bonus points, allowing the plugin to specify (somehow) that this box should or should not be present would eliminate some extra confusion and allow plugin authors ultimate control of what happens with their data.

$template should be set to the template currently in use. But when checking $template inside sidebar.php if the file is included using <?php $theme->display('sidebar'); ?> $template is set to sidebar. The same goes for all <?php $theme->display(); ?> includes, inside the included file $template is set to the page being included

This might not be a bug, if so please just close it.

Moved from GCode Issue #455

Reported by michael.twofish, Oct 20, 2007
What steps will reproduce the problem?
An AtomPub client can specify that an Atom entry is a draft by sending <app:control><app:draft>yes</app:draft></app:control>. Habari does not support currently this.

What is the expected output? What do you see instead?
The submitted entry should be marked draft and not published.

Please provide any additional information below.
Solution: Detect the app:control element in atom entries and honour the app:draft setting, where a value of 'yes' means the entry is a draft.

When you write a title or a tag, a letter of which has an accent or another diacritic (ex: "café"), Habari creates a slug without that letter (ex: "caf"). Also, "&" becomes "amp".

I would expect Habari to sanitize special characters, because European languages use a lot of them. I don't know if this also effects search engines optimisation.

I am not a linguist, but I think that most vowels have standard alternative spellings. Here is an incomplete list:

à, á, â -> a

å -> aa

ä, æ -> ae

è, é, ê, ë -> e

ì, í, î, ï -> i

ò, ó -> o

ø, ö -> oe

ù, ú -> u

ü -> ue