Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
Hi to all
Wasn't there a hint about an integration for websites in another tread?
means that there was a PHP code for showing f. e own references in the CV site?
I did not found anything in the help files or the in the forum.
> Wasn't there a hint about an integration for websites in another tread?
Yes, please see my forum post from 2007-07-09 18:47 (currently the last one) in this thread:
And here are two real-world examples:
I've now committed the files that are required to make the include feature work:
For further help, please see the notes at the top of the 'show.js' script.
Note that the include feature may still have some display problems for the new GUI features that were added recently to the refbase SVN "bleeding-edge" version.
Let us know if you run into problems.
I did not try the java script still now, becaus I do not use Java Script for that website.
I am using a PHP/SQL Sript to display the items.
Thank`s for your answer
> I did not try the java script still now, becaus I do not use Java
> Script for that website. I am using a PHP/SQL Sript to display the
That's fine, of course.
I.e., you can call the 'show.php' script with this URL parameter & value:
to omit the visible header & footer from the returned HTML page. refbase will still serve a full HTML page, though.
To only get the HTML block with the formatted citations (and not the full HTML page), you could also include this URL parameter & value:
within the 'show.php' URL. This will then output only a partial document structure containing solely the search results.
for future reference, there's now a new page in the refbase wiki which describes how to include refbase results into other sites:
In addition, there's also a new wiki page on the refbase OpenSearch service which may be of interest to folks who want to process data from a refbase server and/or integrate them into their own mashups:
I noticed that you linked to our people publication page for an example of the AJAX methd. I actually just switched to the fetchDataFromURL
approach - seems to give a quicker loading time for the user as the page loads progressively, unlike the AJAX approach which doesn't show anything until all refs have been retrieved.
I am happy for you to link to us for the other method though if you like.
Just to follow up on using the fetchDataFromURL method. It turns out that you need to use html url encoded characters if you are passing regex syntax for the author field.
For example, instead of:
Jones, *A[ [:punct:]]*B
you need to use:
This is not required when calling show.php directly, but it is when calling it via fetchDataFromURL.
Hope this helps someone else.
I was just thinking about things regarding the integration of results into our people publication pages. We all have lots of reports, science newsletters and other items that we don't necessarily want to have displayed in our institution's list of publications. Not sure if it is possible or not with the existing setup, but it would be great to be able to add these sorts of pubs to the database, but only display them in people publications pages, rather than through the main refbase interface.
Any thoughts on the best way to implement this? My simple hack would be to add a new field - maybe - 'display_main' set to 'yes' or 'no' and pass a variable from people publication pages to show all, no matter what this is set at, but through the main refbase, only display those set to 'yes'.
This seems somewhat related to the ' contributionIDCheckBox' checkbox, but not quite the same and I think different enough to warrant consideration.
Do you think this might be a useful feature for all refbase users?
> We all have lots of reports, science newsletters and
> other items that we don't necessarily want to have displayed in our institution's
> list of publications.
If the treatment of a specific type is homogeneous, you don't need to use the contributionID.
For a list of publications that is integrated into a website, you can merely refine your query. Include a 'type=' argument for show.php. To limit the display of these more, you might find it useful to make use of the 'library search' feature more extensively & to define your library as the set of types that you want to include by default.
If your treatment of types is not homogeneous, the contributionID is fairly useful & I use this to enable/disable PDF visibility & for generating a list of institutional publications.
> Do you think this might be a useful feature for all refbase users?
I believe the existing facilities may suit your needs already. If not, please let us know what is lacking.
I think I didn't explain fully - I am actually wanting to hide certain types from the main refbase interface, but display all types in our list of publications integrated into our website. Staff obviously have published many reports etc in their previous jobs. They would like to be able to have all these available from their publication lists, but it is not necessarily appropriate that these are visible through the main refbase interface (which is really just meant to show pubs by our institution). I haven't been using the contributionID thus far, but if I used this as the selector to determine whether or not a publication should be displayed through the main refbase interface, I would need to modify the sql query in search.php, or am I missing some already built-in functionality?
> They would like to be able to have all these available
> from their publication lists, but it is not necessarily appropriate that these
> are visible through the main refbase interface (which is really just meant to
> show pubs by our institution).
What do you mean by "the main refbase interface?" refbase is a database & I would think it would be desirable for advanced search, etc. be able to find all references.
It may be that the default search should not be an advanced search, capable of finding everything in the database. To achieve this, I'd use the library_search functionality. Define $librarySearchPattern and format your webpages to prefer a librarySearch over a full database search. Possibly add the library_search constraints to any "quick search" at your site too.
> We all have lots of reports, science newsletters and other items
> that we don't necessarily want to have displayed in our
> institution's list of publications. Not sure if it is possible or
> not with the existing setup, but it would be great to be able to add
> these sorts of pubs to the database, but only display them in people
> publications pages, rather than through the main refbase interface.
I think that the main refbase interface should displays all its database contents, if not, how would you be able to manage invisible records?
That said, it is of course possible to change the internal logic so that only the database admin sees ALL records, or that an additional URL parameter would be required to display all records. However, I think it's better to see it the other way 'round: have your main refbase interface always display all records, and *always* use customized outputs (i.e. tailored 'show.php' queries) for all personal or institutional publication lists. I.e. the main refbase interface would *not* be used to display your institute's publication lists.
Institutional publication lists could then be assembled via the 'contribution_id' field. And queries for personal publication lists could make use of the user-specific 'selected' field where users would select those publications that should be included in their publication list. Here's an example query:
(more examples at http://bibliographies.refbase.net/ )
So, maybe the best solution would be to whip up a little custom script to handle the display of publication lists. The script could include a variant of the Quick Search form. refbase results would be fetched in the background (via a tailored 'show.php' URL) and results would be displayed by the same custom script (i.e. no redirection to the main refbase interface). This setup would give you a lot of flexibility and you wouldn't need to mess with the main refbase scripts.
Alternatively, if you really want to offer most of refbase's functionality for people to browse your institute's (and only these) publications, you could also duplicate your refbase script directory to another directory (but have it still connect to the same refbase database). Then customize the scripts in that directory so that searches would be restricted to your institute's publications only. For this "public" refbase interface you could hide unnecessary search pages (like Advanced search), and adopt 'search.php' (e.g. after line 550) so that the condition in '$librarySearchPattern' is added to the WHERE clause of *every* SQL '$query'. Users from internal IP addresses could be redirected to the other/original refbase script interface which would offer the full functionality as usual.
However, one would still need to adopt the refbase search suggestions so that they get also restricted to your institute's publications only.
Things might get easier when there's support for record-specific permissions. Also, there isn't yet a universal 'buildWHEREclause()' function (I had plans to implement this but didn't manage before the release of refbase-0.9.5). A global function that assembles all WHERE clauses would make modifications like yours (and, later, implementation of a plugin mechanism) much easier.
I might be stretching the scope of this thread now, but in relation to hiding reports, newsletters etc from the main interface, I have also been thinking about the best way to control access to PDFs. As you know, I am using a hack to control via IP address, rather than requiring our staff to login to access them. This is to ensure we are not breaking journal copyright. However, with reports, newsletters, dissertations, etc we own the copyright and it would be great to offer the PDF of these up to everyone. I am thinking about adding yet another field - 'own_copyright'. If this is set to 'yes', then the PDF will be available to all users. If 'no', then it will be restricted to IP address, or logged in users.
Again, any thoughts on whether you'd like to integrate something like this for everyone?
> I am thinking about adding yet
> another field - 'own_copyright'. If this is set to 'yes', then the PDF will
> be available to all users. If 'no', then it will be restricted to IP address,
> or logged in users.
You can use the $fileVisibilityException for this. I personally use contribution_id to show what files have been created by my institution & make all of these visible.
Thanks, I had forgotten about $fileVisibilityException. However, am I correct in assuming that you can only specify one file type? I would like to specify thesis, report, and newsletter (a type_name I am going to add to the 'types' table.
> However, am I correct in assuming that you can only specify one file type?
No. It uses regex, so you should be able to use '|' as an "or" between the multipe types that you enumerate.
> I have also been thinking about the best way to
> control access to PDFs.
Rick already mentioned variable '$fileVisibilityException' in file 'initialize/ini.inc.php'. Currently, this variable only supports one field and its accompanying matching pattern (formulated as a perl-style regular expression). So if you want to show PDFs based on the 'thesis' field (being non-empty) AND the 'type' field (matching "report" or "newsletter"), then variable '$fileVisibilityException' cannot be used as is.
However, if you're going to add "newsletter" as a new type to table 'types', you could as well add a dedicated "thesis" type (note that you should still make proper use of the 'thesis' field to have refbase work correctly). Then, you could use:
$fileVisibilityException = array("type", "/(newsletter|report|thesis)/");
which would cause refbase to always display any PDFs for records of type newsletter, report or thesis.
Another solution would be to tag all records whose PDFs should be displayed publicly with a particular keyword or note (e.g. in the 'keywords', 'area' or 'notes' field), and then use this keyword or note for matching. As an example, for records with public PDFs, you could put this copyright notice into the 'notes' field:
Copyright by UMCES (University of Maryland Center for Environmental Science)
$fileVisibilityException = array("notes", "/Copyright by UMCES/");
While this would require "manual tagging" of articles, it's certainly the more flexible solution. And, if you really want to make all PDFs from all reports, newsletters & dissertations freely available, then you could even have a nightly cron job that would perform the "tagging" via a batch search & replace action.
I haven't tested it but these SQL commands should do the trick:
UPDATE refs SET notes = "Copyright by UMCES (University of Maryland Center for Environmental Science)" WHERE type RLIKE "(newsletter|report|thesis)" AND (notes IS NULL OR notes = "");
UPDATE refs SET notes = CONCAT(notes, "; Copyright by UMCES (University of Maryland Center for Environmental Science)") WHERE type RLIKE "(newsletter|report|thesis)" AND notes NOT RLIKE "Copyright by UMCES";
Great thoughts, thank you!
I went with adding "author copyright" to the notes field as I agree this seems the most flexible option and since I have really only added a few thesis to the database so far, it was quick to add the tagging.