Issue: Chapters revisited - columns

An issue to consider with developing a solution for columns or pushing the TOC onto multiple pages is that the TOC may have multiple levels, and those levels must be preserved if the break does not occur during level 0.

Before columns can be done effectively, content types need a preview-limit, or a configurable limit to the number of pages that appear without going to the list. Currently this value is hardcoded for each type. Once a limit is set, the column would break once the limit is reached. If the list type supports columns (as categories and books would), then the limit would have to be reached twice before no more entries can be shown.

The list-view should still show entries in a single column, but be paginated based on the normal paging options for those types. This is because for column-capable types, the list view still shows the full listings as other content types, including last-update and moderator controls. Breaking this view into columns could become cluttered.

I personally have a wiki that has one book with almost 300 chapters, and I agree the list is long (and uses unnecessary resources). Adding both column support and list support to books, as well as updating the other types to have configurable front-page limits, will greatly improve these features.

Imported to VW4 tracker. Notes: originally suggested for version 3.0.0.

In progress. The code for constructing chapter bits has been rewritten so that levels can be preserved across columns. Templates have been updated and appropriate settings added.

Some further improvements need to be made:

• The TOC needs to be removed from the page-text box and placed in a dedicated container. This will make it look similar to other content types and make the controls for it feel less ridiculous.
• Create a new table vw_chapterorder which contains a compiled list of all (nested) chapters in the correct order. This would allow paginated results with little computing power, will provide previous/next chapter links with much simpler logic, will get the sidebar block working again where the current chapter is at a higher position than the preview length, and will protect against coordinated DDoS attacks (although I doubt it would deny many pages but the books themselves, so the risk to security is low).

Table vw_chapterorder now exists, is populated by the upgrade script, and is managed appropriately by the DMs. Needed to modify the DB models in order to handle the UPDATE syntax required.

Once the new table is fully implemented in all locations with chapter lists, this issue can be closed.

Implemented in the next release.