We are moving to Git Issues for bug tracking in future releases. During transition, content will be in both tools. If you'd like to file a new bug, please create an issue.

Bug 6880 - Author Affiliation information displays with raw HTML
Author Affiliation information displays with raw HTML
Status: RESOLVED DUPLICATE of bug 6080
Product: OCS
Classification: Unclassified
Component: User Interface
All All
: P3 normal
Assigned To: PKP Support
Depends on:
  Show dependency treegraph
Reported: 2011-09-09 15:24 PDT by James MacGregor
Modified: 2011-09-14 13:47 PDT (History)
1 user (show)

See Also:
Version Reported In:
Also Affects:

Prototype patch (887 bytes, patch)
2011-09-13 22:02 PDT, James MacGregor
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description James MacGregor 2011-09-09 15:24:39 PDT
The Author Affiliation field is TinyMCE-ified, and can accept HTML. However, wherever the affiliation is being displayed otherwise (eg. on the submission's Summary page; in the About the Author and Indexing Metadata reading tools), the fields raw HTML is also displayed. For example, if I add the following two testing lines as an author affiliation: 

1. Université de Montréal.
2. Université de Montréal

... the affiliation is subsequently displayed like so: 

1. Universit&eacute; de Montr&eacute;al.<br />2. Universit&amp;eacute; de Montr&amp;eacute;al

I don't personally know how to fix this; just picked up on it while messing around with the googleScholar.tpl file.  However, you can see this happening on our own conference web site: 


The only place it does seem to be working as expected is on the actual paper page itself (templates/paper/paper.tpl) (http://pkp.sfu.ca/ocs/pkp/index.php/pkp2011/pkp2011/paper/view/292 for the same article), which uses {$paper->getAuthorString()|escape} to print the author information rather than something like {author->getAffiliation|strip_tags|escape} or similar.
Comment 1 James MacGregor 2011-09-13 22:02:21 PDT
Created attachment 3639 [details]
Prototype patch

Crazy. I think I tracked this down to a change that was never reverted from http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=4122#c9. The following patch "fixes" the problem by just de-TinyMCE-ifying the two spots where the affiliation TinyMCE-enabled. Note that we've had a request to keep/make this field TinyMCE-ified (see Bug 6464), but I think we should hold off until this is done in a better way across the board. 

Michael (and possibly Matt, as the original commentator on the previous bug): any thoughts on the attached patch? I'm happy to commit this, but I'd like to get your opinion first.
Comment 2 James MacGregor 2011-09-14 11:57:07 PDT
One further point on this one: I just realized that if my patch is applied to a conference that already includes affiliation information, that information will still be improperly displayed, regardless of the fix -- that is, the raw HTML is still stored in the DB. So my patch only really fixes future affiliation entries, not current ones. So if my patch doesn't suit, is there any way to display raw HTML stored in the DB properly for those affiliations?
Comment 3 Michael Felczak 2011-09-14 12:36:02 PDT
James, this looks to me to be a specific instance of a more general problem with TinyMCE as per Bug 6080 (which I have yet to commit to stable).

With the fix for Bug 6080 applied, characters should be saved in the db using the character set and not converted to HTML entities.

However, all TinyMCE text entered prior to the fix will have already been saved in the db with the HTML entities.

As a result, all TinyMCE db data needs to be manually and systematically HTML decoded to replace existing HTML entities with their character set equivalents.

As a workaround, it may be possible to load an existing HTML-entitied field and resave it once the fix in Bug 6080 has been applied.

I'll commit it to stable so you can give it a test.
Comment 4 James MacGregor 2011-09-14 13:47:51 PDT
Thanks, Michael -- the fix for 6080 works. Closing now (although there's another related bug that I'll file separately).

*** This bug has been marked as a duplicate of bug 6080 ***