PKP Bugzilla – Bug 6292
Form "name" element has been deprecated
Last modified: 2014-06-25 08:36:17 PDT
Form "name" element has been deprecated. It's currently in use all over the system. Either change the HTML standard we're working to, or grep & fix cases of <form name="...">.
Matt, this breaks most of the JS in OJS and OCS. You'll need to grep for document.[formName] and change all code that references it.
Yeah, that was a big oversight :P
Hi Matt, there are still leftover form names that were not converted to ids.
The refactored JS gets elements by id and is failing as a result. This includes things like Bug 6360.
Fixed GroupForm language selector; see https://github.com/pkp/ojs/blob/e120824354f60a4fb49e29e057b6d744982cb8de/templates/manager/groups/groupForm.tpl -- there are probably lots more of these.
Fixed templates/admin/journalSettings.tpl -- https://github.com/pkp/ojs/commit/68f935074742f4af7c6fe86647550cedf9e4f57a
Fixed a few stragglers:
Juan, as per comment #5 there are still leftover form names in OJS and maybe OCS as well.
This entry was opened against OMP, and we're all clear there. Maybe best to file against OJS instead so that it doesn't get lost.
Fixed form ID clash
Fix references to form 'name' attribute
Fixed deprecated form name attribute reference causing JS error on login page
Reassigning to OCS for a good look through to find any stragglers. Should investigate OHS as well.
This change broke our functional datacite and medra tests which we actively use to avoid regressions when committing new code. I fixed this. Just wanted to mention that Selenium uses IDs, XPath and CSS to locate elements in HTML. So when you change something in the markup you may have to analyze impact there. Most of the time proper grepping is enough to find the impact (as in this case).
The same grep also turned up a jQuery code snippet in lib/pkp/templates/common/header.tpl that references a form name. Maybe you want to have a look?
see https://github.com/pkp/pkp-lib/blob/master/templates/common/header.tpl, line 95
Fixed issues with form name/id changes in import/export plugins
Fixed form name/id bugs
Resolved remaining instances in OCS and OHS. Closing.
Form name/ID fixes
Reopening for IE fix: see http://pkp.sfu.ca/support/forum/viewtopic.php?f=28&t=3437&start=30#p38876 for details.
Bruno, do you mind checking IE compatibility?
(In reply to comment #21)
> Reopening for IE fix: see
> for details.
Tested with IE8 in a virtual windows xp machine, the language switcher works fine.
Needs feedback: what, if any, version of IE is not working?
Still doesn't work with 184.108.40.206 version
Garant, can you be more specific? What browser are you using, and what page isn't working?
Hi Alec! I'm Sorry, I came here from forum thread where we discussed the Static Page plugin. The language switch in that plugin doesn't work for a long time, after old upgrade (I don't remember from which version it appeared). In order to edit the second language I should change the web site's global language (from switch located in the right page side). Only in such way the static page plugin changes the editable page to corresponding language.
I'm using the Firefox 30
Garant, I've filed that separately as bug #8809; please try the patch there.
Ok, as soon as technician will patch the system - I will post feedback in your's provided thread. Thank you!