Closed Bug 677176 Opened 11 years ago Closed 11 years ago

Wiki should remove sections with null values, input by form-templates


(Websites ::, defect)

Not set


(Not tracked)



(Reporter: Debloper, Unassigned)



(1 file)

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20100101 Firefox/5.0
Build ID: 20110615151330

Steps to reproduce:

Enter user details on
For it won't accept null values for Background/Events - I put some data.
Later, removed of those fields & data with regular edits.

Actual results:

It leaves the empty "Background"/"Events" section hanging at the top. It also adds a "Remo Monthly Reports" section, that too is not positionable (but that makes another bug).

Expected results:

Wiki should gracefully hide the sections with null contents.
Rather, the template should be more flexible to deal with this issue.
I can't edit, the template page is locked.

I'm adding the diff that works on MediaWiki - and should work on mozWiki.
I'll give Lucy(Majeken) and Vineel a holler.
I can't edit, the template page is locked.

I'm adding the diff that works on MediaWiki - and should work on mozWiki.
I'll give Lucy(Majeken) and Vineel a holler.
Attachment #551417 - Flags: review?(majken)
Comment on attachment 551417 [details] [diff] [review]
DIFF for

Review requestee changed, let's get to the original template author.
Attachment #551417 - Flags: review?(majken) → review?(pierros)
Template should not be edited by regular users.

Semantic mediawiki Forms has the functionality to not accept forms with specific empty properties. (returning an error) Mediawiki in general has not this functionality. Thus the functionality we have right now is the optimal considering the technologies we are using.(and that we want users to complete those!)

Indeed though we need to hide the sections if empty.

I am making the edits requested (thanks!) and look out for more ways to optimize templates until we have portal up and running
Closed: 11 years ago
Resolution: --- → FIXED
0. Thanks for resolving the bug.

1. I understand the technical limitations - yeah, you're right :)

2. Until we move to the portal, can we not use User:<username>/ReMo page for ReMo specific details? In fact, in this way, ReMo page can handle much more detail than the userpage could(read 'should') - this adds one level obfuscation for the near-private information - or info not really required for user, but for ReMo. It also keeps the userpage more manually customizable.

3. I want to be involved with the portal website development. It would be great to have a lead: whom to contact, what to fork, where to start. [Like to talk in IRC, or will send a mail tomorrow :]
0. No problem :)

1. Indeed, unfortunately that is the best we can do :(

2. Moving everything in username/sthelse space is really difficult right now. Many tempaltes, categories, forms and properties rely on this and most people are used to it. Moreover, the mediawiki convention on User pages is the one we are using: Having everything on User:username

3.We are still in the early planning with no stage/dev parts ready to accept contributions. You may find some initial info here:

Attachment #551417 - Flags: review?(pierros)
You need to log in before you can comment on or make changes to this bug.