none
Adding Google Custom Search Engine to my Website poses a baffling situation RRS feed

  • Question

  • I added Google Custom Search Engine to my Website following Google instructions and then tested (1) using F12 and Search Box showed up as expected (2) uploaded files and checked, Search area was distinctly visible but no Search box.

    Checked Page Source and found to my surprise that related code had changed during upload process. Repeated this by changing location of search box in master.dwt and multiple uploads but always same.

    What's baffling is that code remains intact on local server but changes on remote server. It's simply not logical.

    This was further supported by the following test -

    Checked using Super Preview online Beta; IE9 did not show Google Custom Search but Safari5 did show it.

    Why, can't imagine...

    All related screenshots and codes can be viewed at http://www.maanojrakhit.com/en/misc/google-custom-search-engine.html

    Thank you for your time and help.



    Thanks

    Sunday, November 11, 2012 9:43 AM

Answers

  • Further investigations by CloudFlare revealed that a different CloudFlare App was in conflict as described below:

    We identified the conflict. The Google Analytics app within our system checks for existing Google Analytics on your page, and removes that code to ensure that things don't get double counted. In this case it was also removing the custom search code as well. I've toggled off the Google Analytics app and the custom search now displays correctly. We're going to file an internal bug about this, but in the mean time I'd recommend leaving the GA app disabled so that the custom search shows/functions.

    Thus, the problem was finally resolved as shown by these images: here the bug was fixed (see image) and this was the bug (see image) that was fixed.

    PS: CloudFlare happens to be a valuable addition to any website (see details) and it was activated on my domain many months ago. I am glad that this entire exercise has helped identify an inherent bug which will soon be taken care of, and that will make CloudFlare even more valuable to my or any other user's website.

    Just in case, anyone would be interested in a briefly stated, comprehensive account of this entire issue at one place and also with supporting images and web-links, may want to pay a visit to http://maanojrakhit.com/en/misc/google-custom-search.html


    Thanks

    • Marked as answer by MR_2009 Thursday, November 15, 2012 3:29 PM
    Thursday, November 15, 2012 3:28 PM

All replies

  • Without seeing a COMPLETE page it is not possible to give more than a guess - "Do not track" configuration in IE 9 is preventing the code from running.
     
    This guess is based on the fact that, for me, Google Mail pages do not render in IE9 unless "Do not track" is turned off.
     
    Please give a link to a page with the Google search.
    (Why it is not affected locally I cannot say).
     

    Ron Symonds
    Microsoft MVP (Expression Web)

    www.rxs-enterprises.org/fp
    • Marked as answer by MR_2009 Sunday, November 11, 2012 11:29 AM
    • Unmarked as answer by MR_2009 Sunday, November 11, 2012 11:29 AM
    Sunday, November 11, 2012 10:15 AM
  • Sorry, I clicked the wrong button "marked as answer" and therefore, I had to" unmark" it again.

    Thank you very much for your kind answer.

    All pages at http://maanojrakhit.com are affected because I inserted the code in master.dwt and then applied it to all html pages. Also, verified that html pages were truly updated by selecting a few pages at random and going into code view.

    http://www.google.com/cse/tools/create_onthefly is the Google Custom Search page. There, I clicked at Customize your own search engine button after signing-in (though it appears that signing-in may not be mandatory).

    After going to http://www.google.com/cse/manage/create?Get+Started=Customize+Your+Own+Search+Engine, I went step by step, (1) setting up my search engine by filing-in required information, (2) trying it out, (3) getting the code.

    Thereafter, I inserted the javascript before the closing </head> tag in my master.dwt (local server) and placed the following tag <gcse:search></gcse:search> where I wanted both of the search box and the search results to render (below the drop-down menu).

    Thereafter, I selected a few pages at random and pressed F12 one by one for each page, went to the browser and was able to see the search box at the right place. Then I uploaded all pages to remote server and called my site and tried those pages, I could find the <div> area clearly visible but blank, i.e., without search box. It was same with other pages.

    That is when checked the source code behind the page on remote server (my website) and noticed that var cx = '018385689398275166537:cp-qiz2q1l8'; was missing and rest of the code did not look similar.

    Next, I tried Super Preview and the outcome was as mentioned in OP.

    I also moved the position of search box in master.dwt and repeated the whole process, though I wasn't necessarily expecting any thing out of it, and the outcome was same as before.

    Kindly let me know if I should provide some more information to assist you in helping me through this.

    Incidentally, I wasn't quite clear about "Do not track"...

    Thanks

    Sunday, November 11, 2012 11:55 AM
  • There is no trace of a DWT on any pages at http://maanojrakhit.com.
    A page based on a DWT would include HTML comments similar to
    <!-- #BeginEditable "content" -->   <!-- #EndEditable --> to indicate editable regions.  These are missing.
     
    Have you published using Optimisation to remove HTML comments?  This may have removed the Google code in the process.
     
    "Do not track" is a recent technology, partially supported by modern browsers such as IE9, IE10, Firefox (later versions), Safari and the latest version of Chrome. It is supposed to stop users being
    tracked accross the Internet by advertisers etc, though support for this is very hit and miss - mostly miss.
     

    Ron Symonds
    Microsoft MVP (Expression Web)

    www.rxs-enterprises.org/fp
    Sunday, November 11, 2012 1:11 PM
  • Thanks a lot!

    I had a rough idea that optimization removes unnecessary comments which probably speeds up page load.

    But I did not realize that it could remove all traces of a DWT from all pages of a website. Is it same as going to EW4 Format menu >> Dynamic Web Template >> Detach from Dynamic Web Template?

    I checked EW4 Site menu >> Site settings >> Publishing and found Optimize during publishing box unchecked.

    I also checked in EW4 a few pages by going to Code view and found all HTML comments were intact, not missing. But as you rightly said these comments are all missing from remote copy (I mean pages that reside on remote server). Any way to understand why would that be?

    Now, it is very true that I did an experiment over past one or two days which could have led to this mess. But even if that be the case, I would still wonder as to why HTML comments remained intact in my local copies and got eliminated from my remote copies?

    As for that experiment, howsoever stupid it may sound, over past two days I had been doing a Reformat HTML and Optimize HTML in Code view on DWT local copy after making any changes to it. Then, I saved it which in turn applied all those changes to all attached HTML pages.

    Having done so, HTML comments like <!-- #BeginEditable "content" -->   <!-- #EndEditable --> remained intact not only in the DWT but also in attached pages. But, it seems now, that uploading the DWT, styles, HTML pages to the remote server somehow removed those HTML comments in remote copies but leaving them intact in local copy. The cause behind it remains a mystery and if possible I would want to learn from you about the likely causes.

    Finally, I tried another Reformat HTML without doing Optimize HTML in Code view on DWT local copy, saved it which attached it to rest of the pages, and then uploaded the index.html and checked the source code behind it and found it was as before without those comments. It means I failed in undoing what I may have done unknowingly by Optimizing HTML in Code view of DWT local copy.  [P.S.: I cleared Cache, etc. in Firefox and IE before checking uploaded index file under this step]

    What would you suggest that I should do in such situation?

    Thank you again for helping me understand these technicalities that I had not understood before.

    P.S.:

    I never used Optimize HTML option under Tools menu.


    Thanks


    • Edited by MR_2009 Sunday, November 11, 2012 3:02 PM P.S. added in 2 places
    Sunday, November 11, 2012 2:54 PM
  • "I had a rough idea that optimization removes unnecessary comments which probably speeds up page load."
    By removing comments page load is faster - but the gain is usually so small (even with a dial-up modem) it is not worth the effort. Removing leading whitespace can make significant savings in page
    size (useful when paying by the MByte) but rarely makes the page render faster.
     "Is it same as going to EW4 Format menu >> Dynamic Web Template >> Detach from Dynamic Web Template?"
    It has the same effect but also removes all other HTML comments, except those required by FrontPage webbots such as Design Time Includes.
     "... why HTML comments remained intact in my local copies and got eliminated from my remote copies?"
    This would only happen if you published with optimisation turned on in Publishing settings.
     Go into Publishing Settings, Publish tab
    Check the "Optimise when publishing" checkbox
    Click Customise button and note the settings.
    Clear every checkbox and click OK
    Clear the "Optimise when publishing" checkbox
    Click OK
     
    Open a page for editing.
    Check that all required HTML comments are present (if there aren't any, add some), save and close the page.
    Locate the page in the File List, Right click on the page and choose "Publish Selected Files to .... "
    Check the online copy to see if the comments survived.
     

    Ron Symonds
    Microsoft MVP (Expression Web)

    www.rxs-enterprises.org/fp
    Sunday, November 11, 2012 4:39 PM
  • Thanks.

    I followed the steps.
    Checked the "Optimize when publishing" check-box
    Under Customize none of the boxes were checked. So, I saved it as default.
    Cleared the "Optimize when publishing" check-box
    Clicked OK

    Opened index.html, went to code view, found all comments present. Tried F12, Firefox showed Search box. View Page source. All HTML comments present.

    Uploaded index.html using FileZilla and cable broadband. Opened http://maanojrakhit.com/index.html. No Search box. View Page source. No HTML comments present.

    PS: Again, attached DWT to all files and then uploaded them using EW4 Publishing, and checked couple of uploaded pages, but no change in status.

    PS2: Downloaded Safari and installed it because EW4 Super Preview Online Beta had shown Search Box in Safari and I wanted to verify it. When I called my website on Safari it looked like any other browser IE, FF, Chrome. None showed Search box. On checking Source code in Safari I found the same thing, no comments but local copy has them and F12 based on local copy, too, has them. I don't know how comments are all disappearing after upload disregard vehicle used FileZilla or EW4 Publishing tool. Never had this problem over the years.


    Thanks



    • Edited by MR_2009 Sunday, November 11, 2012 6:02 PM PS2 added
    Sunday, November 11, 2012 5:19 PM
  • Uploaded index.html using FileZilla and cable broadband.

    Well, that should take EW's "Optimize HTML during publishing" function completely out of the equation, since you didn't use EW to publish.

    Frankly, I'm at a loss to explain this. I checked your site, and you are correct—searching the source for "<!--" finds zero instances. Since you are uploading using a 3rd-party FTP client, and EW clearly displays the comments when viewed locally, I don't see how this can possibly be attributed to EW. EW displays them in source, and when Previewed In Browser, displays the expected result.

    FTP is not transformative—it sends whatever is in the file, neither knowing nor caring what the file contains. Hmm... it just occurred to me; FTP does have two transfer modes—ASCII and binary. If memory serves, HTML should be transferred as ASCII. AFAIK, EW handles this correctly as a matter of course. Is it possible that FileZilla is transferring as binary, and that is somehow stripping the comments? (Admittedly, this is a wild-ass guess, but then, this shouldn't be happening, so... )

    cheers,
    scott


    Please remember to "Mark as Answer" the responses that resolved your issue. It is common courtesy to recognize those who have helped you, and it also makes it easier for visitors to find the resolution later.

    • Edited by paladyn Sunday, November 11, 2012 6:27 PM
    Sunday, November 11, 2012 6:26 PM
  • Thanks.

    I had also tried EW Publishing as mentioned in the same post (kindly see PS which reads as "Again, attached DWT to all files and then uploaded them using EW4 Publishing, and checked couple of uploaded pages, but no change in status").

    I also checked FileZilla transfer settings and they were on Auto. I changed it ASCII but that made no difference.

    As we had eliminated almost all visible factors I thought of two other obscure factors (a) CDN (b) Server, and tested on those.

    First I deactivated CloudFlare CDN for standby domain hindooraashtr.com and uploaded same set of files to another server and found that Search Box promptly showed up at http://hindooraashtrcom.fatcow.com/

    Next I deactivated CloudFlare CDN for primary domain maanojrakhit.com and checked the result, search box was still missing. That singled out the server for my primary domain as probably the culprit, and therefore, I started writing a tech support ticket. At the end I wanted to attach the screenshots of the same page as displayed by two different servers, one with and the other without the Search Box.

    As I hit http://maanojrakhit.com in browser address box it showed up the page with search box. Thus, I realized that it needed few minutes after deactivation of CloudFlare. That time was allowed to the other server because I was uploading the entire site for the first time which in itself took quite a bit of time.

    Now that the main issue stands resolved and I can see the search box on both servers, the question that stares at me is "what was the role of CDN CloudFlare in this whole game that robbed us of so much time collectively"?

    Anyhow, it was a good case for learning something new...

    Finally, thanking you both for helping me with this issue.


    Thanks

    Sunday, November 11, 2012 7:39 PM
  • I raised a ticket on CDN service provider CloudFlare, followed their suggestions, reported back the steps taken and their outcome, which further re-instated my concern that CloudFlare, indeed, had something to do with it but what we still do not know. Nevertheless, I intend to take this matter to its natural conclusion and pursue it further until resolved.

    It is no more EW4 issue but, it is possible that some people may still be curious, as I am, to know from where such issues may crop up, here is the link to the proceedings: https://support.cloudflare.com/requests/2311

    Happy learning...


    Thanks

    Tuesday, November 13, 2012 2:00 PM
  • Further investigations by CloudFlare revealed that a different CloudFlare App was in conflict as described below:

    We identified the conflict. The Google Analytics app within our system checks for existing Google Analytics on your page, and removes that code to ensure that things don't get double counted. In this case it was also removing the custom search code as well. I've toggled off the Google Analytics app and the custom search now displays correctly. We're going to file an internal bug about this, but in the mean time I'd recommend leaving the GA app disabled so that the custom search shows/functions.

    Thus, the problem was finally resolved as shown by these images: here the bug was fixed (see image) and this was the bug (see image) that was fixed.

    PS: CloudFlare happens to be a valuable addition to any website (see details) and it was activated on my domain many months ago. I am glad that this entire exercise has helped identify an inherent bug which will soon be taken care of, and that will make CloudFlare even more valuable to my or any other user's website.

    Just in case, anyone would be interested in a briefly stated, comprehensive account of this entire issue at one place and also with supporting images and web-links, may want to pay a visit to http://maanojrakhit.com/en/misc/google-custom-search.html


    Thanks

    • Marked as answer by MR_2009 Thursday, November 15, 2012 3:29 PM
    Thursday, November 15, 2012 3:28 PM