Simple enough bug, if you sort the Loans table by their return dates the table only displays items that have been returned. I'm guessing because the SQL query only includes Loans that actually have the return date meta value.

Bug was introduced in d762f82 as part of #35

The 'Start Date' column actually represents two different data values (combined for simplicity) of wp_lib_start_date, the date/time the item is scheduled to be loaned, and wp_lib_give_date, the date/time the item actually leaves the library. These two are differenciated because a loan scheduled by one librarian for one date may well be different to the librarian and date that the item actually ends up being passed to the member.

This does however introduced a complication, the table can't be sorting using a single meta value. Using the start date would produce an incorrect sort in instances when the start/give dates differ and using the give date would would cause loans without a give date not to appear, like the issue in #40.

Archiving would remove member from loaning options, rendering their entry as only useful for archival purposes. This would still retain their records and be an alternative to allowing loans/fines to exist after member deletion.

There is currently no way to prevent a Member from borrowing more than a set number of books. As this is likely part of most real libraries' policies it follows that it should be implemented within WP-Librarian. The loan limit would remove or grey-out Member's currently at the limit from the Member selection page. Forging a request or editing the HTML page to loan the item anyway would incur an error explaining the library's policy.

This could easily be implemented via:

• The addition of a setting 'Loan Limit', or, more appropriately, combining it with an existing loan related option
• The filtering of the members dropdown list
• An additional check before scheduling loans

Currently the pre-deletion check causes PHP errors every time it is run. I'm also unsure if it even works properly. Assessment of pre-deletion checks may well lead to changes in how it's handled by the AJAX action as well.

Currently there is no way for librarians to view information on when fine payments were made (the feature implemented in 3991a18).

A way of viewing a table of this information, similar to the loan renewing table, but displaying the date, librarian and payment amount of each fine payment. The renewing table is displayed below:

Using Dynatable queries with dropdown menu options for filtering by author, combined with the ease of Chosen, would make for some seriously useful filtering options.

As a more general note: Dynatable has all kinds of features which could probably be implemented to a greater degree within WP-Librarian.

http://www.dynatable.com/#querying

Currently a late item return at a past results in automatic fine suppression. Add the ability to choose if to fine the member when returning the item at a past date. A new API ability would allow for dynamic changing of displayed buttons (return with fine etc.) based on selected past date.

Might be wise to hold off on this until issue #18 is implemented. We'll see.

Because the wheel doesn't need re-inventing

Current handling relies on server generating relevant error, so without a serverside error there is no indication that the request has even been successful.

Add handling that first checks for notifications, then, if no notifications exist, calls the default error.

Library Roles are supposed to be independent of WordPress Roles, such that a Library Administrator can be only a WordPress Contributor. This allows for the Library to be kept somewhat separate of the WP installation so that someone can manage the Library without having to be given unnecessary access to the blog.

This is not however happening. In order to access the Settings page a user has to be both a Library Admin and a WP Admin. This is not a security vulnerability as the Library's permissions still hold: You cannot modify Library settings with the WP Admin Role. This is however annoying for any site's with Library Admin's who aren't all WP Admins as well.

Testing has shown this was not introduced in development and is present on all Wolf Tail releases.

In ef3f380 the hardcoded directory names (scripts/styles/lib/etc.) were replaced with constants. Allowing access of directory names to plugins, avoiding a hardcoded mess that would break everything if a change occurred.

The downside is this has not been fully implemented. Only the main class has been surveyed meaning other classes, helpers and possibly even JS code is still using hardcoded directory names.

Resolving this issue requires finding any continued uses of the hardcoded directory names and replacing them with the new constant.

The barcode length needed to trigger an autolookup of the item is currently hard coded into the script (currently 8). This should be fetched from user preferences so that it can be modified according to the user's preferences.

When editing items that do not have a media type set a PHP error occurs. This is owing to the code for handling item meta in admin-templates working off the assumption that all items have a media type and thus wp_get_object_terms will return an array of terms. A simple check would fix this.

Proposed definition of 3 sections to all Dash pages:

1. Header - Containing the metabox and any other header elements as they are devised
2. Actions - Buttons/fields for modifying the object being managed
3. Table - Optional table that displays Loan History/Connected Objects/etc.

These would be defined as three arrays (or passed as false) in every page returned by the server. Similar to the current header/form split used, but with each section within a separate div, rather than the form being within the header as it currently is.

PHP 5.3 (and older) do not support the use of ['herp', 'derp'] to declare arrays, as a shorthand of array('herp', 'derp'). Anyone using a host running PHP 5.3 or older will be unable to run WP-Librarian. While there may be other reasons WP-Librarian will not work on older PHP versions, this one would likely cause a lot of unnecessary confusion.

Issue is owing to pseudo URLs being generated in render_page() as part of the loop to render the form. The simplest solution would be move the functionality to its own function. A more cumbersome solution would involve changing the nature of forms themselves to simply be an element to be iterated over, similar to divs.

It's an unsightly mess that could most likely be greatly improved to be clearer and faster.

Currently the only settings page is one for slugs, there need to be other settings pages for every other public plugin setting!

Created in issue #17, when an item is renewed the displayed 'due date' is updated to reflect the new due date. An item due on the 15th, renewed until the 20th will be updated to display the due date as the 20th. A table will also appear on the management page for that loan, displaying all occasions when the item was renewed. Each renewing displays the updated due date.

This issue is that there is no part of the UI that displays the item's original due date. Not only is this unhelpful but potentially allows for malicious renewing of an item to hide a due date that would have resulted in a fine.

My thoughts on possible solutions all have pitfalls, so I have not implemented any of them. While it is unlikely that anyone has even noticed this repository, let alone read through the issues page, I'll leave it 'open to debate'.

• Change renewings table such that each row displays the item's previous due date, rather than its amended due date. The pro would be all information is displayed on the page. The con would be that it feels unintuitive to display an item's past due date on a listing that would intuitively display either what things have become or both past/future states.
• Change renewings table such that each row displays both the past and updated due date. The pro would be that this lacks the issue of feeling unintuitive by displaying something's past state. The con would be repeated data. As each new renewal makes a data cell of the past row redundant, or vice versa.
• Add 'Original Due Date' to loans meta/info box. This would avoid the issues of the above solutions at the cost of bloating an info box that already contains four timestamps and alot of other information. This is potentially an issue with the other information already there, which could be potentially be put elsewhere or in a new element. Until the loans metabox gets less bloated this solutions seems unrealistic.

Following on from #47, the core scripts (admin core, admin dashboard, meta core, etc.) are all pretty old. They slowly grew as more functionality was tagged on and as I learned more about JavaScript.

A look over all these scripts for readability, performance and other fixes will likely result in much better code.

Settings functionality is currently stretched across two classes, the template and the main class.

Using some of the new hooks in the template the functionality can be removed from the template.

The settings code in the main class potentially belongs in the settings class but I'm none too sure. It needs surveying first.

After all this is done the settings section class is riddled with useless comments and redundant functionality. It needs looking over.

Move cover image up so that the description starts a small gap below the meta rather than under the cover image. This issue existed before 1d7923e when the description was did not extend right of the item cover, post 1d7923e it now does not extend above the cover image.

Late night tea fuelled attempts to perform basic CSS were met with failure.

Mockup:

Replace handling of currency as a float with handling as an int (x100 then /100).

Forgot to create this issue a few months back.

As it turns out, there's no need to use post meta to store foreign keys and do meta lookups to get connected posts, as there's a damn table column for it: post_parent. As such, a major part of the entire plugin needs re-jigging to use this.

Alas, considering how major this is, everything else has to be put on hold while I switch things over to using post parenting instead. The upside is it'll probably mean less DB calls and less overall code.

Implement system similar to Tribe Events, whereby multiple and single post listings have separate permalinks, e.g. /library for items and /library/item for a single item.

Currently the item archive is held at /library/item, which is unintuitive.

wp_lib_do_delete_object and the pre-deletion filter need major work so the deletion of a Library object does not severely affect the Library's stability.

It is currently only possible to sort the items post table by title and by no columns for other post types. A simple modification to the post table class would allow for sorting by relevant fields.

When visiting the loans post table, the Dashboard menu item disappears. This does not occur on any other page.

For some time errors have not been correctly reported by Dashboard AJAX. Errors that result in malformed JSON are being reported as the server being down (Unable to contact $site_name The website may be down or you may be having connection issues). This is probably just a minor issue with wp_lib_send_ajax().

Reduce database queries and similar by using classes for Library Objects, with their relevant functions held inside those functions.

The classes currently in the helper folder are identical to the library classes. I would think of the helper classes as for classes that can be used between projects. Such as the Dev Kit's ISBNdb class.

While the settings class for registering settings sections could be made a helper that would be a separate issue.

I propose merging the helper classes directory into the library (lib) directory. When a class is actually re-usable between projects the helper folder and relevant main class method can be easily re-added.

In a "You may also be interested in" section.

The chart:
http://westonruter.github.io/ipa-chart/keyboard/

Currently all meta fields are displayed regardless of appropriateness. A simple JS implementation could be used to display only relevant media type dependant meta fields.

Clearing hidden fields on submission could also be considered.

Currently only the default basic jQuery datpicker styling is being used, the Mellon styles are not being applied. This is resulting in an unsightly datepicker.

WP-Librarian's scripts are a mess. A collection of small pieces of functionality that merged and connected together with no clear structure. Pretty much all of the scripts reflect some stage in my level of experience with JavaScript, creating a diverse range of methods to achieve their purpose.

This issue aims to deal primarily with restructuring the scripts into modules, with helpers where it would be silly to wrap unconnected functions up as a module. It is inevitable though that some scripts will end up being worked on during this process to some degree. Even if just to remove some of the more feckless comments (read: 'x.doY() // Does Y to X).

It just returns true.

Allow member fines to be paid off from the Member Management page on the Dashboard. The amount to be paid being a numeric value that would be subtracted from the member total, if both it is valid and would not result in an invalid (negative) member fine total.

Currently there is no way for a librarian to be made aware of an item's lateness or upcoming lateness. This means librarians have to regularly check the item listing to see what items are approaching lateness. Users that have provided an email address are also not notified if an item they have borrowed is soon due for return.

There are currently two ways in which users are authorised to view pages and perform actions: WordPress Capacities and WP Library Role
Consider the viability of merging the Library Role into WP capacities and access the effectiveness of the current function used for managing user capacities.

There are multiple helper functions which only serve to help other helper functions and all perform similar functionality. By moving the internal functions to a class and removing repeated elements the helper file should be able to be reduced greatly.

The Edit button seems to only work on occasion, on failure the default posts page is loaded (../wp-admin/edit.php). Unable to establish pattern of failure/success.

Allow Dash page elements to be selectively changed, rather than creating an entire page from scratch if multiple elements of the page will remain the same. An example is that moving from manage-item to resolve-loan requires re-rendering the Item Management Header. If, while creating the resolve-loan page, the function had known that the previous page was manage-item, it could have avoided creating the item-management header and simply sent back that the header shouldn't be changed (by setting the header section to true rather than an array or false.

Creating test data by hand is annoying. Create a development infrastructure that allows test items to be created and some accompanying test data to be parsed when needed.

There are numerous StackOverflow snippets used in the project and cited inline. A Creative Commons licence is generally assumed for SO responses, which is incompatible with GPL2. As such either of the following actions must be undertaken for each snippet:
A - Contact the snippet's creator and ask for their permission to use the snippet in the plugin. If the creator does not want their snippet used then B:

B - Remove the snippet and write your own damn code, punk.

Option A would be preferable.

Dates displayed on the Dashboard are currently formatted at the server, unnecessarily sending a abbr element to the client. A new Dash element type should be created, that formats a given unix timestamp at the client.

This will also necessitate local time being added to the vars included in wp_lib_vars

Implement ability to renew items on loan so that they can continue to remain with a member, avoiding need to 'return' item to then loan it straight after. This distinction would avoid a single extended loan being kept track of as two or more seperare loans, and would avoid the item being incorrectly noted as being returned and re-loaned.

Renewing functionality could be achieved by updating an item's due date, while adding loan meta to distinguish between regular loans and to keep track of the number of times an item has been loaned.

Further functionality could be implemented to limit the number of times an item can be loaned.

Add a custom post type of which a post is created for every notable event, logging the relevant WordPress user and any relevant objects modified by the user. This post type should be editable by noone and only visible to Library admins. Accessible through the Library Dashboard.

When updating WP-Librarian Slugs Settings, if all characters are stripped the setting is saved as a blank slug. Testing has shown this results in the plugin defaulting to the name of the custom post type (wp-lib-items).