Major: support rootpages (README.md) and custom pagesort based on in-file metadata #26

Closed
wants to merge 22 commits into
from

Conversation

Projects
None yet
2 participants
@Martimiz
Contributor

Martimiz commented Mar 20, 2013

  • Add rootpages like README.md to the toplevel sidemenu (optionally disable)
  • Enable custom pagesort based on custom metadata in the files (optionally disable)
    Also enables the use of other metadata, like Title
  • Documentation for both features

Note: Both features also available in separate branches.

See also: https://groups.google.com/forum/#!searchin/silverstripe-dev/martimiz/silverstripe-dev/d8jTpkQhT88/JjwikBCxscwJ

Martimiz added some commits Feb 1, 2013

Enabling/disabling rootpages globally and/or per entity
This sets up the basic functionality for enabling or disabling the
display of rootpages: valid non-localized pages that live in an
entity's root
Setting up registration to allow rootpaths
Registration path will point to the entity root by default, and will
automatically configure the documentaition path as well as the optional
rootpath.

Registering the docs path is still possible for reasons of backwards
compatibility.
Inject rootpages into the sidemenu
Rootpages take their place in the toplevel sidemenu as if they are part
of the localized files
Find the requested page - localized or root
If the rootpage is selected, it needs to be displayed. The
DocumentationViewer::getPage and ::LocationExist() methods are adapted,
as well as DocumentationService::find_page() and ::find_page_recursive()
Update DocumentViewer test to comply with natcasesort
Using natcasesort on menu-items will sort case-insensitive, where in
the original natsort was case-sensitive, causing some confusion...
Set empty version to 'current'
On older manual or custom registrations the version may be set to ''
(empty). This should automatically be converted to current.
Added information about rootpages and permissions
Information about rootpages and how to enable/disable their display
globally or per entity/module.
Add property to enable/disable reading metadata from file
Meta data are key/value pairs wrapped in a HTML comment block at the
head of the file
If metadata enabled, read it from file and resort pages
Only resort if there is a chance of custom page sorting, avoiding
overhead when not.
Separate default pagesort for docs and rootfiles
Most cases you'd probably want the rootfiles (like README) to be
located at the bottom of the menu.
@chillu

This comment has been minimized.

Show comment
Hide comment
@chillu

chillu May 14, 2013

Member

Can we switch the metadata definition from pseudo-html comments to a more standard one? See https://github.com/fletcher/MultiMarkdown/wiki/MultiMarkdown-Syntax-Guide

Member

chillu commented May 14, 2013

Can we switch the metadata definition from pseudo-html comments to a more standard one? See https://github.com/fletcher/MultiMarkdown/wiki/MultiMarkdown-Syntax-Guide

@Martimiz

This comment has been minimized.

Show comment
Hide comment
@Martimiz

Martimiz May 14, 2013

Contributor

Sure, I suppose... As markdown they are standard I think, meant to hide content even on Github. The reason I did it this way is that I wanted them not to be displayed...

Would be nice if the docsviewer supported MultiMarkdown - I remember looking into it and thinking that would be too much for me :(

Contributor

Martimiz commented May 14, 2013

Sure, I suppose... As markdown they are standard I think, meant to hide content even on Github. The reason I did it this way is that I wanted them not to be displayed...

Would be nice if the docsviewer supported MultiMarkdown - I remember looking into it and thinking that would be too much for me :(

@chillu

This comment has been minimized.

Show comment
Hide comment
@chillu

chillu May 17, 2013

Member

Any update on this?

As a general remark, pull requests should never contain merge commits, it makes it much harder to rebase them. Simply rebase your pull request branch against the branch you branched off from. This changes the commit hashes, but that's OK for pull requests. See http://doc.silverstripe.org/framework/en/trunk/misc/contributing/code

If you have time, can you please squash the commits? It's probably easiest to git cherrypick them into a new branch, rather than deal with the merge commits. But only if you have time, I'm keen on getting this PR (with the changes to markdown metadata format) into the module ASAP.

Member

chillu commented May 17, 2013

Any update on this?

As a general remark, pull requests should never contain merge commits, it makes it much harder to rebase them. Simply rebase your pull request branch against the branch you branched off from. This changes the commit hashes, but that's OK for pull requests. See http://doc.silverstripe.org/framework/en/trunk/misc/contributing/code

If you have time, can you please squash the commits? It's probably easiest to git cherrypick them into a new branch, rather than deal with the merge commits. But only if you have time, I'm keen on getting this PR (with the changes to markdown metadata format) into the module ASAP.

@Martimiz Martimiz closed this Jun 27, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment