Issue Number | 4010 |
---|---|
Summary | [Summaries] Summary Frag Refs Not Working in Pub Preview |
Created | 2015-12-08 10:09:16 |
Issue Type | Bug |
Submitted By | Juthe, Robin (NIH/NCI) [E] |
Assigned To | Englisch, Volker (NIH/NCI) [C] |
Status | Closed |
Resolved | 2015-12-15 14:12:56 |
Resolution | Fixed |
Path | /home/bkline/backups/jira/ocecdr/issue.175253 |
Summary Fragment Refs are not working in Publish Preview. It appears this could be related to the Feline release, given the timing. A 404 "file or directory not found" error is displayed when you click on a link to another place in the summary.
Adding Volker and William.
Would you happen to have the CDR-ID handy?
I guess it's CDR62933, isn't it?
Here are a couple of examples:
CDR0000062933 - Childhood Hodgkin Lymphoma Treatment (HP)
CDR0000062890 - Genetics of Endocrine and Neuroendocrine Neoplasias
I made some changes to the program PublishPreview.py in
order for the fragment links to work again. I am surprised, though,
because I thought the changes to the HTML we're now receiving from
Gatekeeper was part of the NVCG release rather than the
Feline release.
Anyway, please take a look (CDR62902 on DEV includes fragment refs) on
DEV and let me know in case I've messed up other links with this
fix.
It seems to be working fine on DEV now. I didn't see any problems while testing.
Great! When you're saying "It works fine now" you're referring not just to the fragment link but also to other link types that are supposed to work on PP, right?
That was the results I got at first but I just went back to test and I am getting different results. For example, when PP first comes up and I click on the very first link in the TOC (•General Information About Small Intestine Cancer), nothing happens. However, when I go to the Changes Section and click on a similar link there that is supposed to go to the same section, it works and then now when I scroll up to the TOC again and click on the link that didn't work at first, it works now. Also, the references are supposed to work but then do not work right away, you need to choose open in new window before it will open. Generally, when you click on them, nothing happens. It is not the same behavior on PROD. (There are also no pop ups on PROD so not sure if that is what is causing this). I also, wanted to mention that I cannot test every possible link using this summary. For example, it appears there is no MediaLink in this summary. So, if you want me to do more thorough testing, then I will have to use other summary documents.
Thanks, William. That's very useful. I will take a look at the references tomorrow. I don't think the links in the TOC are related to this problem because those are created using JavaScript but I'll look at those as well tomorrow.
I did some more testing on both PROD and DEV and have my findings in the attached spreadsheet.
In your spreadsheet you're listing According to our
documentation, this should not be working for internal
SummaryFragRefs. This ticket has been created because these links aren't
working.
Did you mean to add that comment to the external SummaryFragRefs
instead?
I think both types of links (internal & external) should work, as should summary refs. See https://cdr.cancer.gov/cgi-bin/cdr/Filter.py?DocId=CDR0000773122&Filter=name:Documentation+Help+Screens+Filter. This was updated with the Curie release.
Regarding your comment Only works by choosing option to open in
another window:
What is your default browser for DEV? I do not see this prompt for IE or
FF. I'm certain this is a browser setting.
Regarding your comment Only works by choosing option to open in another window:
What is your default browser for DEV? I do not see this prompt for IE or FF. I'm certain this is a browser setting.
I am using IE to do all the tests.
It works for me on PROD using the same browser. I don't make any changes
to the settings when logged into DEV so should it matter what the
default settings are?
I don't make any changes to the settings when logged into DEV so should it matter what the default settings are?
Since the links are identical on both, DEV and PROD I can only assume that the way the browser was started would make the difference. On DEV you are using a different version of the CDR Loader that picks the browser based on your local defaults. Anyway, because you are able to open the links I'm not going to focus on this portion for right now.
This was updated with the Curie release.
Unfortunately, the deciding factor is not the CDR release but the HTML that we receive from Gatekeeper, i.e. the WCMS release. We certainly can adjust the links to fit our needs but we'll have to keep in mind we're not testing the links per se but a modified version of the link based on a number of assumptions.
I'll see if I'm able to satisfy that list again.
What should be our assumption for the host when it has not been
specified? Should it point to www.cancer.gov of be tier specific, i.e.
www-qa.cancer.gov, www-stage.cancer.gov, etc.?
I mentioned Curie only to point out that this list was created recently, post-NVCG.
What type of links are you referring to for the question about host assumptions? Don't SummaryRefs and SummaryFragmentRefs automatically go the summary or fragment on the same tier?
That is correct for the website but not for publish preview which is the reason why you submitted the ticket. A SummaryFragmentRef is currently written as
/types/small-intestine/hp/small-intestine-treatment-pdq/#link/_1
When you're on the website this path/fragment will be attached to the host in order to create the URL resulting in
://www.cancer.gov/types/small-intestine/hp/small-intestine-treatment-pdq/#link/_1 http
on PROD or on STAGE
://www-stage.cancer.gov/types/small-intestine/hp/small-intestine-treatment-pdq/#link/_1 http
The URL for the PP, however, is a program running on the CDR server and your resulting URL becomes something that doesn't exist:
://cdr.cancer.gov/types/small-intestine/hp/small-intestine-treatment-pdq/#link/_1 https
when it should be
/_1
#link
or://cdr-dev.cancer.gov/cgi-bin/cdr/PublishPreview.py?Session=guest&DocId=CDR0000062902&Version=cwd#link/_1 https
This can easily be resolved for the (internal) citation links and the internal SummaryFragmentRefs. It's also no problem for external links, because these already specify the hostname, i.e. PUBMED Abstract (http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?cmd=Retrieve&db=PubMed&list_uids=10651347&dopt=Abstract). For all other links it needs to be decided (a) if it's a link to a PDQ document (i.e. /publications/pdq/levels-evidence/treatment) and (b) if it should point to production or not.
For example, when PP first comes up and I click on the very first link in the TOC (•General Information About Small Intestine Cancer), nothing happens.
These TOC links are created with JavaScript. The PP program doesn't change these because the links don't exist as part of the HTML coming back from Gatekeeper. I believe the latest JavaScript changes have not yet been migrated to the DEV server, so that may be a reason why this isn't working in DEV or your browser didn't load all of the JS before you clicked.
However, when I go to the Changes Section and click on a similar link
The links of the Changes Section are SummaryFragmentRefs instead of TOC links. These are two different types of links and not similar. :-)
Also, the references are supposed to work
There was definitely a problem with the citation links but that's fixed now. However, the citation links are still not working on DEV and I believe - again - this may be related to some JS issue on DEV.
Is there a summary on DEV that includes an external SummaryFragRef that I could use to test?
Try CDR0000062745 it is external ref 62787#_93
I believe I have now addressed all of the link types reported in the document Supported Links in CDR Reports. The only different I've noticed in my initial testing were the ProtocolRefs. These do currently work due to a re-direct by Cancer.gov.
This is ready to review on DEV.
All the links appear to work correctly now. More testing may be needed but I tried nearly all the links and they appear to work fine.
I have verified the following links in PP on DEV:
CitationLink (internal links #cit/_NNN to Reference section)
ExternalRef
PUBMED Abstract link
SummaryRef (calling PublishPreview version of summary)
SummaryFragmentRef (both internal and external)
MediaLink (displays without caption and not true size)
However, MediaLinks should (and are) displaying the caption. What do you mean by "not true size"?
he only different I've noticed in my initial testing were the ProtocolRefs. These do currently work due to a re-direct by Cancer.gov.
The protocols refs are not working for me. It is re-directing me to "http://www-blue-dev.cancer.gov/clinicaltrials/NCT00532727" for example and that comes up IE cannot display the webpage. I assume that this may work in production since the redirect will take you directly to www.clinicaltrials.gov for closed trials and Cancer.gov for Active trials.
What do you mean by "not true size"?
Is that a question for me? If so I did not write the comment and don't know what it means. I would guess that the writer expected the image to display at the same size as the enlarged image on Cancer.gov. Something we never intended to simulate.
The protocols refs are not working for me. It is re-directing me to "http://www-blue-dev.cancer.gov/clinicaltrials/NCT00532727"
The link http://www-blue-dev.cancer.gov/clinicaltrials/NCT00532727
is the actual link in the document. The re-direction would point you
from www-blue-dev.cancer.gov to
clinicaltrials.gov.
This redirection is working for me even on DEV. Are you able to
copy/paste the URL into your browser?
Oh, sorry, I thought you wrote that. I copied that from the documentation that I linked to above (https://cdr.cancer.gov/cgi-bin/cdr/Filter.py?DocId=CDR0000773122&Filter=name:Documentation+Help+Screens+Filter) - it was last reviewed (not sure if this means "updated") on 1/6/16, so I thought maybe you added that when you were updating the ticket. 🙂
Yes, I did make some minor modifications to that document (i.e. adding the update date) but the remark related to the image size was already there.
I think the images are displaying as expected, the same size as on Cancer.gov. As on Cancer.gov, we can enlarge an image in PP, which opens it in a separate window (without the caption). Since this is operating in the same way as Cancer.gov, I'm not sure any parenthetical note is needed.
I updated the documentation to remove the note for the MediaLink.
The link http://www-blue-dev.cancer.gov/clinicaltrials/NCT00532727 is the actual link in the document. The re-direction would point you from www-blue-dev.cancer.gov to clinicaltrials.gov.
This redirection is working for me even on DEV. Are you able to copy/paste the URL into your browser?
The redirection works for me when working from home and connected to the CISCO VPN but it does not work while in the office and connecting via the site to site VPN even if I copy the URL and paste it into a browser. We may have to reconfigure the VPN tunnel to allow it to work. We have done such modifications in the past.
Thank you, William, for checking the links from home. I was wondering
if your problems resulted from some settings specific to your network
since everyone else over here couldn't reproduce the problem.
Glad to hear it's working.
The report has been saved to subversion:
R13649: PublishPreview.py
A ticket to copy the report to STAGE and PROD has been submitted as WEBTEAM-7860.
The WEBTEAM ticket has been completed.
Please verify that the Summary Frag Refs are working again and close
this ticket.
Summary Frag Refs are now working but I noticed a new minor problem with the appearance of external links. The icon indicating a link that is external to Cancer.gov is showing up on top of text. I will post a screenshot.
See ref 26 in the attached screenshot. Let me know if you prefer that I open a separate ticket for this.
That looks like a CSS or JavaScript issue and is not directly related
to the changes to the PublishPreview.
Let's add a new ticket for this and make it part of Darwin.
I'm unable to confirm what you're seeing, Robin. I'm using IE 11 and the icons look OK (see screenshot)
Apparently, the glitch was only temporary because the icons now look fine to me, too (I'm also using IE 11). Don't you love it when problems resolve themselves? 🙂
I will close this ticket since it's been verified on PROD. Thank you!
File Name | Posted | User |
---|---|---|
AvailableOnline.jpg | 2016-01-20 11:41:09 | Englisch, Volker (NIH/NCI) [C] |
Links Test on DEV and PROD.xlsx | 2015-12-16 12:22:22 | Osei-Poku, William (NIH/NCI) [C] |
screenshot-1.png | 2015-12-08 10:09:46 | Juthe, Robin (NIH/NCI) [E] |
screenshot-2.png | 2016-01-20 09:42:44 | Juthe, Robin (NIH/NCI) [E] |
Elapsed: 0:00:00.001671