Page MenuHomePhabricator

Bug? Page_Forms: Free-text Invades Sections
Closed, DeclinedPublic

Description

In created pages, "Free text" areas are not marked off to keep them separate from Sections.

As a result, any free-text underneath a section will get loaded into that section's input-box on "Edit with form".

This applies to any text under a section: So, if you manually put a Category tag at the bottom of the page, when user goes to edit page with form, the Category tag will get loaded into the last section box, where the user might delete or alter it, thus removing the page from your intended Category.

The author says this isn't a bug-- i disagree. Page_Forms and native MW features should be compatible, not break each other. Page_Forms should not break a mediawiki page. Standard mediawiki features (like category tags) should not break page_forms.

By MW standards, when a page is normally rendered, category-tags at bottom of source are never included in last section. MW KNOWS they are NOT part of the last section. But your extension doesn't know they are not part of the last section.

Free-text invading the section should reasonably not happen. ''You offer free-text as a separate entity.'' Therefor, your extension should mark-off the free-text in some way. Or at least '''''ignore category tags!''''' Your extension should respect MW standards. Your extension breaks MW.

Possible fixes:

  • Best: extension sections should ignore category and any other wikitext that MediaWiki sections would also ignore.
  • Mark off free-text areas, so the Form knows they are separate from sections
  • Mark off the entire form region, so users can safely put text both above and below the form region, and the form will ignore it.

Event Timeline

Johnywhy created this task.Jun 22 2018, 4:41 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJun 22 2018, 4:41 PM
Johnywhy updated the task description. (Show Details)Jun 22 2018, 4:43 PM

Well, if the author says it is not a bug and you insist that it is, I would suggest you assign it not to the author (which is bad form anyway, usually tasks are claimed) but to yourself and provide a patch.

Johnywhy added a comment.EditedJun 22 2018, 6:32 PM

i'm not the maintainer. The author is the maintainer of the extension. Therefor, the author already has volunteered to maintain the extension. Being "maintainer" includes bug-fixes, doesn't it?

I removed the assignment.

Johnywhy removed Yaron_Koren as the assignee of this task.Jun 22 2018, 6:33 PM
Johnywhy updated the task description. (Show Details)
Johnywhy added a subscriber: Yaron_Koren.
Johnywhy updated the task description. (Show Details)Jun 22 2018, 6:37 PM

Thanks. Indeed, the author has volunteered to take care of the extension, but that usually means "as time permits" and does not mean that they are responsible for every bug and that nobody else is allowed to contribute. There are more than 100 bugs currently open on PF, so I would expect that any help is very much appreciated and for an edge case like yours the best way of getting it fixed may indeed be to do it yourself.

And fwiw, I have to agree with Yaron that while your issue may be annoying for you, the solution is not as clear-cut as it seems at first glance. You have to also consider other people's expectations and what is super-obvious for you is not at all what is wanted by others.

Some people are expecting (as in "have explicitly required in the past") to be able to set the category in the free text.
Free text areas are traditionally the "everything else" area, where everything is put that is not handled by the form.
The form region is already marked (the form is translated into a template call that is clearly delimited), but free text is a special case, that to a degree ignores form boundaries (similar to the submit and cancel buttons).

I think your best bet would really be to just include that template you want to avoid.

Johnywhy added a comment.EditedJun 23 2018, 12:22 AM

that usually means "as time permits" and does not mean that they are responsible for every bug

For sure, I understand.

Some people are expecting (as in "have explicitly required in the past") to be able to set the category in the free text.

That's exactly what I want too.

Free text areas are traditionally the "everything else" area, where everything is put that is not handled by the form.

Exactly, "not handled by the form" means the form should ignore it. But it doesn't ignore it.

The form region is already marked

Then free text should be outside of the form region, so it's ignored by the form.

free text is a special case, that to a degree ignores form boundaries

But it seems the issue isn't whether the free text is, or isn't, ignoring the form boundaries.

The issue is whether the form is, or isn't, ignoring the free text.

I realize I called this issue "Free-text Invades...", but maybe should be called "Form fails to ignore..."

I think your best bet would really be to just include that template you want to avoid.

For now, that's the only option.

Thx

Sorry for the long delay. This may have been fully addressed on the Page Forms talk page, but if not:

By MW standards, when a page is normally rendered, category-tags at bottom of source are never included in last section.

I don't know what this means. When editing sections, category tags are indeed included; and when the page is displayed, category tags aren't shown at all.

I also don't see how a part of the page could be "marked off".

I'm tempted to close this bug as invalid, but please let me know if you want to discuss it further.

Johnywhy added a comment.EditedJun 30 2018, 12:34 AM

When editing sections, category tags are indeed included

You totally correct.

I was misled, because i'm using an extension which removes the category tag from the source-editor.

Instead, it provides a category-picker widget.

Perhaps you can use the same technique these extensions use, to separate the category-tag from the rest of the page. Maybe they search the source for:

[[Category:...]]

Just guessing.

Aside from Categories, i think it's appropriate and expected behavior that your extension will mark-off, and keep separate, anything in the "free text". Your extension basically takes over the editing interface. Therefor, it's appropriate for your extension to add special tags to the wikitext to identify your regions. Your design is clearly intended to replace the default source editor, so users won't see your special tags. Eg:

<PF:FreeText>
Lorem ipsum dolor sit amet, epicurei percipitur assueverit est in. 
</PF>
Vvjjkkii renamed this task from Bug? Page_Forms: Free-text Invades Sections to 2faaaaaaaa.Jul 1 2018, 1:02 AM
Vvjjkkii triaged this task as High priority.
Vvjjkkii updated the task description. (Show Details)
Vvjjkkii removed a subscriber: Aklapper.

@Vvjjkkii what is the meaning of these nonsense edits and tags?

JJMC89 renamed this task from 2faaaaaaaa to Bug? Page_Forms: Free-text Invades Sections.Jul 1 2018, 3:07 AM
JJMC89 raised the priority of this task from High to Needs Triage.
JJMC89 updated the task description. (Show Details)
JJMC89 edited subscribers, added: Aklapper; removed: Vvjjkkii.

@Johnywhy - ah, the fact that you were using a category-tag-handling extension explains the issue.

No, Page Forms isn't intended to fully replace the standard editor - that's why, by default, PF adds an "edit with form" tab rather than replacing the existing "edit" tab. Given that, I don't think a "free text" wrapper tag makes sense to use, even though it's an interesting idea.

Aklapper closed this task as Declined.Jul 15 2018, 7:56 PM

Declining as per Yaron's last two comments.