Page MenuHomePhabricator

SF & translate extension : "Save page" button does nothing (saves nothing)
Closed, ResolvedPublicBUG REPORT

Description

Author: nicolas

Description:
In a page containing a first part with a perfectly defined form (and its category, its fields, its everything), and a second part containing the <translate> blah blah </translate> managed by the Translate extension, editing it with "Edit with form", changing a value (dropdown) and clicking on "Save page" seems to post things, but does not save the values.
Moreover, the browser re-displays the same form, instead of returning to the page display.

Refreshing the page confirms *no* values were saved, neither those changed by a dropdown, nor the classical text fields.

Removing the <translate> markup immediately leads to a perfectly working form.

All this has been witnessed and confirmed by Yaron on such a setup :

  • Mediawiki 1.20.2 (I upgraded recently to 1.20.4 with no benefit)
  • Semantic Forms (Version 2.5.2)
  • Semantic MediaWiki (Version 1.8.0.4)
  • Translate (Version MLEB 2013.02)

I would love to help, debug and test, but my coding skills are way too rusty.
I will test any submitted patch.


Version: unspecified
Severity: normal

Details

Reference
bz47510

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 1:27 AM
bzimport set Reference to bz47510.

Hi, I would like to work on this to get better understanding of Semantic Forms and Translate extension of Mediawiki. I was not able to reproduce this error. I did not understand '''''''editing it with "Edit with form", changing a value (dropdown) and clicking on "Save page" seems to post things, but does not save the values'''''", part of the description. It would be great if you can share the contents of the page.

P.S. Currently I am using the latest versions all the extensions (translate, semantic forms and semantic mediawiki) and version 1.25(alpha) of mediawiki.

I was not able to reproduce this error.

Thanks for trying. What's the content you tried? :) Given "first part with a perfectly defined form", maybe this is about a page in Form namespace?

Hi, I tried with the following content in form ( it's a bit verbose, picked from http://scratchpad.referata.com/wiki/Main_Page ) :-

<noinclude>
This is the "Darktest" form.
To create a page with this form, enter the page name below;
if a page with that name already exists, you will be sent to a form to edit that page.


{{#forminput:form=Darktest}}

</noinclude><includeonly>
<div id="wikiPreview" style="display: none; padding-bottom: 25px; margin-bottom: 25px; border-bottom: 1px solid #AAAAAA;"></div>
{{{for template|Add User}}}
{| class="formtable"
! User: 
| {{{field|User}}}
|-
! Password: 
| {{{field|Password}}}
|-
! User Comment: 
| {{{field|User Comment}}}
|}
{{{end template}}}

'''Free text:'''

{{{standard input|free text|rows=10}}}


{{{standard input|summary}}}

{{{standard input|minor edit}}} {{{standard input|watch}}}

{{{standard input|save}}} {{{standard input|preview}}} {{{standard input|changes}}} {{{standard input|cancel}}}
</includeonly>

<translate>
This is test input
</translate>

The namespace of the page was "Form", (url during testing was http://127.0.0.1/core/index.php?title=Form:Darktest&action=edit)

I think things were working fine, the data was getting displayed correctly after submitting the form in the expected format.

Nemo_bis added a subscriber: Yaron_Koren.

I tried a form similar to what Darkdragon09 used and created a page with the form. However the page content was being displayed correctly when I added [[Page has default form::Test]] to the page and edited it using edit with form and there was no re-displaying of the edit form page either.

I didn't use a dropdown field though, so maybe that specific field causes this bug.

Hi, I have something similar but only with the <translate> and <!--T--> tags in conjonction. I don't know if it's the same problem so I've put the details in T113209.

Aklapper triaged this task as Low priority.Feb 4 2022, 8:07 PM
Aklapper changed the subtype of this task from "Task" to "Bug Report".
Yaron_Koren claimed this task.

Marking as "Resolved" - this specific issue seems to have been fixed a long time ago.