Bug 1006691

Summary: Duplicate Pressgang Header When Using PressGang Next
Product: [Community] PressGang CCMS Reporter: Vikram Goyal <vigoyal>
Component: Web-UIAssignee: Lee Newson <lnewson>
Status: CLOSED CURRENTRELEASE QA Contact: Vikram Goyal <vigoyal>
Severity: low Docs Contact:
Priority: low    
Version: 1.1CC: lnewson, mcaspers
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-11-08 02:11:04 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
PressGang Duplicate Header none

Description Vikram Goyal 2013-09-11 06:21:18 UTC
Created attachment 796264 [details]
PressGang Duplicate Header

Steps to reproduce:

Open a book via Docbuilder.
Browse to a topic.
Click on "Edit this topic with PressGang CCMS Next"
You will see two Pressgang headers.

See attached screenshot.

Comment 1 Lee Newson 2013-09-11 06:53:29 UTC
Just want to add this disclaimer:

The User Script that adds this link isn't something that is actually part of PressGang and is just something I personally wrote when someone asked for it (remember the next UI is basically just a test version that is running on the production server, so we won't actually create something supported that links to it, like the normal editor links).

Anyways I'll take a look when I get a chance, for now you'll just have to open it in a new tab, or install the additional New Tabs User Script.

Comment 2 Matthew Casperson 2013-09-11 19:58:03 UTC
At this point PG next is not going anywhere, so I think we should look at making the editor links include next as a standard, so something like:

Edit this topic in <link>PressGang</link> or <link>PressGang Next</link>

Comment 3 Lee Newson 2013-09-12 03:14:42 UTC
I've fixed the root cause of this, which is that the publican settings on the docbuilder weren't reconfigured when it was updated.

The bit that was missing was to change "<xslparam name="ulink.target"/>" to "<xslparam name="ulink.target" select="_top" />" in /usr/share/publican/xsl/xhtml-common.xsl

Anyways we'll have to rebuild all the books for this fix to go live. As for Matt's comment, a separate RFE should be created for that.

Comment 4 Lee Newson 2013-09-12 03:38:24 UTC
Changing this bug back to ASSIGNED, as that parameter should have worked however upon testing, it isn't getting inserted anymore. I'll have to have a look at why the xsl transform is ignoring that parameter (this used to work with publican 3.1.5).

Comment 5 Lee Newson 2013-09-16 04:33:05 UTC
Found the problem and it was a config error on my part. This should now be fixed, however we'll have to rebuild all the books before it will be effective.