Re: Subpages overwhelms the content

You have made perfect sense to me.  I also found this [1] bug report 
which is also about the subject as well.

Something I have noticed though is some of these pages when you go to 
edit them the content is not shown, you must go to edit source.  If we 
just open then save would the content be brought over?

If it is really just doing that is there no way to do a DB query of some 
kind to just set everything the way it needs to be for all articles?

-Garbee

[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=19348

On 10/31/2012 12:44 PM, Alex Komoroske wrote:
> I agree that this is sub-optimal.  Here's what's going on:
>
> We use semantic media wiki to set various properties on pages that 
> help us organize the information on them. This includes things like 
> the "Page Title" (as far as MediaWiki is concerned, the page title is 
> the entire URL string after "http://docs.webplaform.org/wiki/", so we 
> set our own property that's the human-readable title which we default 
> to the last bit of the URL). We also set some properties on pages that 
> allow us to create Semantic Media Wiki queries that list articles of a 
> certain type.
>
> This system will allow us to generate sub-page listings that have 
> short, human-convenient titles and only list the articles that are 
> direct children, not /every single descendant/ page. The 
> http://docs.webplatform.org/wiki/Template:API_Listing template 
> implements this; the page in question uses it.
>
> Unfortunately, due to the way the import happened, these all-important 
> properties aren't set on many pages. As soon as a  user makes any edit 
> to the page using the "Edit" button (as opposed to the "Edit source" 
> button), the pages will magically get the properties set correctly. 
> Literally, people could just click Edit, and then immediately click 
> save on an article and it would work (I call this operation--a save 
> without any substantive changes--a "touch", after the unix 
> command-line program). The problem is there are thousands of articles.
>
> For each page, before that happens, they wouldn't show up in the 
> queries designed to select articles for the "smart" sublisting tables. 
> That would mean that the smart sublisting tables would be incomplete, 
> and some existing content would be unreachable.
>
> In the mean-time, we have an option to use the "stupid" sublisting 
> functionality. This is because in my estimation it's better to have 
> sublisting tables that are overly comprehensive and annoying to read 
> than to have ones that simply fail to list many relevant articles. If 
> an article is not linked from anywhere, it's hard for search engines 
> to find and it means that users won't even know it's there to have any 
> chance of editing/improving it.  So if you look at the API_Listing 
> template (or just hit "Edit" on the page in question), you'll see that 
> the "Print all subpages rooted here" box is checked. This is what 
> generates the "stupid" sublist. The hope is that as many of the pages 
> naturally get touched or edited, we'll get to a place where we can 
> stop using the stupid sublist functionality and move to the smarter one.
>
> This is a lot of information. Am I making any sense?
>
> --Alex
>
> On Wed, Oct 31, 2012 at 8:01 PM, Jonathan Garbee <jonathan@garbee.me 
> <mailto:jonathan@garbee.me>> wrote:
>
>     Ok, I went to check the source of the page and it turns out that
>     the links *are* supposed to be just the item.  There is a bug [1]
>     in the system.  We are still left with the issue of display though...
>
>     -Garbee
>
>     [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=19793
>
>
>
>     On 10/31/2012 6:48 AM, Jonathan Garbee wrote:
>
>         I agree.  We need to trim down what is being displayed and
>         that is a great start.
>
>         Something else with this table, does anyone have any ideas how
>         we can organize it better than just a monolithic table?  It
>         seems quite intimidating.
>
>         -Garbee
>
>         On 10/29/2012 8:02 PM, blueflame wrote:
>
>             Example page: http://docs.webplatform.org/wiki/html/elements
>
>             I suggest that the enormous subpages section either be
>             collapsable or move to the end of the page. Also, for
>             easier digestion, the current page does not need to prefix
>             each subpage. Since the user is already on html/elements/,
>             it's repetition is not necessary. Thoughts?
>
>             -Derek
>
>
>
>
>
>