OK, I fixed it. Please try again and let me know if it doesn't work for some reason (you may need to explicitly reload the page first).

Hi Laurie,

Thanks for reporting this. We were indeed not aware of it. I'll look into it.

Hi Madhur,

BibBase doesn't currently support HTTPS, no. I noted that you are forcing ssl (https) for you page even when opening the URL using http. If this is indeed necessary, then no, at this point there is no solution for that. HTTPS support is planned but there is no timeline yet.

Do you really need encryption though? Publication pages do not typically contain confidential information of any kind, so the need for HTTPS for BibBase is very rare.

You're very welcome. Glad that works.

-- Christian

BibBase doesn't currently support HTTPS, but support is planned. If this is critical to you, I can see whether it can be prioritized. I noticed that there is also an HTTP version of your site, which works well (http://web.stanford.edu/group/fullergroup/cgi-bin/fullerlabsite/?page_id=301). Do you need HTTPS for your site or is most of the traffic going to come over HTTP? It's a little atypical for publication pages to use encryption (HTTPS), because there is nothing confidential about them. But your constraints might be slightly different, so please let me know.

Thanks,
-- Christian

Yes, that's exactly right. If you look into the developer console you'll see this error:

[blocked] The page at 'https://web.stanford.edu/group/fullergroup/cgi-bin...' was loaded over HTTPS, but ran insecure content from 'http://bibbase.org/show?bib=https%3A%2F%2Fweb.stan... this content should also be loaded over HTTPS.

Would embedding via PHP or CGI be an option. There are several benefits to those methods. This error would go away, but also you would wage better on SEO (search engine optimization) of your papers. It seems that you are already using cgi to render the page, so perhaps that method would be better suited? (see the second option for embedding on http://bibbase.org/help; you may be able to just use the CGI code within http://bibbase.org/help/bibbase_proxy2.cgi). Let me know if you need any help with that.

-- Christian

Thanks, Romeo :-)

Yes, that's correct on both accounts. Locations don't matter and paper don't get duplicated. Papers are uniquely identified on bibbase by their "bibbaseid" which is constructed from author last names, title with whitespace removed, and year. Sure, every once in a while someone published the same paper with the same title and coauthors in the same year, so then there is a hash-collision, but I think that's not very good practice, so I'm OK with that.

Hi Romeo,

yes, it does. In your case, you are looking for these two pages:
http://bibbase.org/network/keyword/pisis
http://bibbase.org/all/keyword/pisis

You need to make sure that each of the individual bib files are being used with bibbase as well -- that is the mechanism by which the database is being kept up to date. Every time someone visits a bibbase page that uses one of these bib files as source, the database will be refreshed. So this is *not* as solution when you simply want to merge bib files. In that case, you should just manually merge them and use them as usual with bibbase. This is specifically a solution for showing an aggregate page from several already existing pages.

In your case, it seems that the second bib file in the drive (pubs_sara) had not yet been used with bibbase, so I just opened it once (http://bibbase.org/show?bib=https://d1055d4f3efc35...) in order to get it into the database. It won't stay up to date with changes to that bib file though unless the file is being used on a publications page where it is being visited somewhat regularly.