Bug 6292 - Form "name" element has been deprecated
Form "name" element has been deprecated
Status: RESOLVED FIXED
Product: OJS
Classification: Unclassified
Component: User Interface
2.4.x
All All
: P3 normal
Assigned To: beghelli
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-12-07 16:35 PST by Alec Smecher
Modified: 2014-06-25 08:36 PDT (History)
4 users (show)

See Also:
Version Reported In:
Also Affects:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alec Smecher 2010-12-07 16:35:21 PST
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="...">.
Comment 1 Matthew Crider 2010-12-14 11:56:38 PST
NB: Make sure to change the validate JS in javascriptInit.tpl to use form IDs instead of form names (might want to do a general check for javascript that uses the name attribute)
Comment 3 Alec Smecher 2011-01-10 13:02:56 PST
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.
Comment 5 Michael Felczak 2011-01-21 14:48:21 PST
Hi Matt, there are still leftover form names that were not converted to ids.

See e.g.
templates/admin/journalSettings.tpl
templates/admin/settings.tpl
etc.

The refactored JS gets elements by id and is failing as a result. This includes things like Bug 6360.
Comment 6 Alec Smecher 2011-01-24 17:00:40 PST
Fixed GroupForm language selector; see https://github.com/pkp/ojs/blob/e120824354f60a4fb49e29e057b6d744982cb8de/templates/manager/groups/groupForm.tpl -- there are probably lots more of these.
Comment 7 Alec Smecher 2011-02-18 16:02:11 PST
Fixed templates/admin/journalSettings.tpl -- https://github.com/pkp/ojs/commit/68f935074742f4af7c6fe86647550cedf9e4f57a
Comment 8 Alec Smecher 2011-03-21 11:23:13 PDT
Fixed a few stragglers:
https://github.com/pkp/omp/commit/806efab6b0517b91b40049f67107e1cdd68772e7
Comment 9 Michael Felczak 2011-03-22 12:28:59 PDT
Juan, as per comment #5 there are still leftover form names in OJS and maybe OCS as well.
Comment 10 Alec Smecher 2011-03-22 13:06:14 PDT
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.
Comment 11 Alec Smecher 2011-07-19 09:40:03 PDT
Fixed form ID clash
https://github.com/pkp/harvester/commit/956c9ff3bac40fd7f4538df4105853264c219dec
Comment 12 Matthew Crider 2012-08-13 16:15:02 PDT
Fix references to form 'name' attribute
https://github.com/pkp/ojs/commit/5b87569a43f7585b78afaad45aa36a982005c484
Comment 13 Matthew Crider 2012-08-13 16:20:02 PDT
Fixed deprecated form name attribute reference causing JS error on login page
https://github.com/pkp/pkp-lib/commit/94973df66aa4ea2ec7cfa02750c148bdefe6f399
Comment 14 Matthew Crider 2012-08-13 16:59:40 PDT
Reassigning to OCS for a good look through to find any stragglers.  Should investigate OHS as well.
Comment 15 jerico 2012-09-25 05:38:08 PDT
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).
Comment 16 jerico 2012-09-25 05:49:01 PDT
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
Comment 17 Matthew Crider 2012-09-25 15:55:02 PDT
Fixed issues with form name/id changes in import/export plugins
https://github.com/pkp/ojs/commit/3053a0173b6f953bd4a6ac9b76349182855ab737
Comment 18 Alec Smecher 2012-11-22 10:50:02 PST
Fixed form name/id bugs
https://github.com/pkp/ocs/commit/a793d9991aa790cea5e80b0c1ee1798de4a6f462
Comment 19 Alec Smecher 2012-11-22 10:57:07 PST
Resolved remaining instances in OCS and OHS. Closing.
Comment 21 Alec Smecher 2013-05-23 12:16:53 PDT
Reopening for IE fix: see http://pkp.sfu.ca/support/forum/viewtopic.php?f=28&t=3437&start=30#p38876 for details.
Comment 22 Alec Smecher 2013-09-03 16:29:44 PDT
Bruno, do you mind checking IE compatibility?
Comment 23 beghelli 2013-12-04 14:24:43 PST
(In reply to comment #21)
> Reopening for IE fix: see
> http://pkp.sfu.ca/support/forum/viewtopic.php?f=28&t=3437&start=30#p38876
> for details.

Tested with IE8 in a virtual windows xp machine, the language switcher works fine.
Comment 24 Alec Smecher 2013-12-06 10:19:42 PST
Needs feedback: what, if any, version of IE is not working?
Comment 25 Garant 2014-06-18 05:22:35 PDT
Still doesn't work with 2.4.4.1 version
Comment 26 Alec Smecher 2014-06-18 06:01:21 PDT
Garant, can you be more specific? What browser are you using, and what page isn't working?
Comment 27 Garant 2014-06-18 06:14:22 PDT
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
Comment 28 Alec Smecher 2014-06-18 09:35:53 PDT
Garant, I've filed that separately as bug #8809; please try the patch there.
Comment 29 Garant 2014-06-18 09:42:26 PDT
Ok, as soon as technician will patch the system - I will post feedback in your's provided thread. Thank you!