Form-based editing test

[Garrett 214]

I have made an initial version of the form interface for editing game pages. See Development:Forms for some sample pages to experiment with.

 

This is an initial version to demonstrate the viability of this approach. Let me know of any errors in the settings, e.g. dropdowns missing values that should be supported (or vice versa) or multi-instance templates not having the correct minimum/maximum use limit. The form layout is done with standard wiki tables, so any spacing issues etc. can be adjusted as needed.

 

The biggest change is that form editing works around all form content being contained within templates. Any text not used in a template parameter gets relocated to the bottom of the page (shown in the "debugging area" when editing with the form). The updated templates have notes sections etc. so information can be added in the usual places while now actually residing within the associated templates.

 

Another change is that pages edited with the form have empty template parameters and template whitespace removed (there is no option to disable this), so manual editing is not as easy to read as it was before.

 

This form introduces some new templates such as Patchbox. These templates provide a layout specific to that type of information and supply additional semantic data for the wiki. In the case of Patchbox, the Issues fixed/unresolved sections would link to the Patches section when it exists (this is implemented already but isn't visible in the examples due to using the development namespace).

 

Template features that rely on property checks (GOG.com and Steam Cloud rows, WSGF infobox icon, etc.) don't work in this namespace after a page has been saved.

 

Unfortunately, due to the way forms work each template can only be used in one place on the form (but multiple times in that place). This form uses redirects for several templates to get around this limitation (listed in the "Redirected templates" section).

 

This form currently has an issue where some page sections are shown when empty. This would be resolved with some template adjustments (most of which are already present). EDIT: form editing from section links on the page isn't present yet.

 

Anyway, let me know what you think.

 

EDIT: I have moved the sample pages to my user space (I didn't realise the Development: namespace had restricted editing). Feel free to tinker with the pages.

[Blackbird 54]

Holy moly this is amazing piece of work. I was always thinking if such thing is possible since PCGW pages are all just pre-defined templates, but never saw such thing in workable state. Good job!

I assume old "Source editor" would still work right? Kinda like wikia has visual editor and old one.

[Mars icecream 57]

Source editor should certainly always be accessible. I find it easier and simpler to use when doing minor changes.

 

Visual editor has been the default setting on Wikipedia since 2015 and editing in text "will always be an option":

 

Even after the eventual anticipated full-feature release of VisualEditor, experienced editors still may prefer editing wikitext because they find it faster and more precise. Editing articles purely in wikitext is and will remain an option that the Wikimedia Foundation has no plans to remove. Even editors who enable VisualEditor will have the wikitext option available from the toolbar for each page and section.

[Garrett 214]

Yes, manual editing would be available as always. Game pages would have tabs at the top for each type of editing (this is already used for company pages). Form-based editing would be the default for game pages (like it is now for Company pages).

 

WYSIWYG form editing would be possible once it is supported by Page Foms (this is listed on the planned features list for this extension).

[Suicide machine 53]

I guess it'd be nice for it to take 100% of designated space. Also if there is issue with columns being equally wide, it'd be nice to specify them as well, but see what happens after you set it to 100% width.

[Garrett 214]

I have mostly fixed the width issues (it was using a class that enforced a maximum width). Text box width isn't entirely consistent because the form types don't directly support auto/percentage width (from what I can see) so this would have to be set via CSS.