Re: Subpages overwhelms the content

On Thu, Nov 1, 2012 at 1:55 AM, Jonathan Garbee <jonathan@garbee.me> wrote:

>  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,
>

Do you have an example of this? I'd like to debug.


> you must go to edit source.  If we just open then save would the content
> be brought over?
>

Generally semantic forms is *pretty *good about maintaining the bits that
don't fit into structured form fields between an open and a save. But I'd
like to test that to verify. :-)

>
> 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?
>

Unfortunately, it's a bit harder than that, apparently.  The magic part of
the "touch" process is when semantic forms looks at what templates are
*supposed
*to be on the page and then puts them there if they aren't yet. Semantic
forms, in my limited understanding, is layered pretty much just on top of
MediaWiki, which of course is layered on top of the database part. So you'd
need to do something far more intricate than just working directly with the
database. What exactly that would entail, I don't know.

>
> -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>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
>>>>
>>>
>>>
>>>
>>
>>
>
>