Faculty Profile Pages in Drupal: How Universities Get Publication Lists onto the Website
A publication list reaches a faculty profile page in one of three ways. The academic types it in, someone imports a file, or the site reads it from the system where research output is already recorded. This article explains which option suits which institution, where publication data sits before it reaches the website, what Drupal handles and what it leaves to you, and how much the free ORCID service actually covers.
Faculty profile pages are among the most visited pages on a university website. Prospective students look up who teaches what. Journalists look for an expert. Researchers looking for collaborators read the publication list before anything else. Despite that traffic, these pages are usually the least maintained part of the site. The reason is rarely design. The reason is that nobody decided who is responsible for the information on the page.
A faculty profile page draws on more than one system
The page looks like a single page from the outside, but several very different kinds of information come together on it. Title, department, office location and institutional email are held on the HR side. Teaching assignments sit in the student system. The biography is written by the academic. Publications, grants and citation counts live in whatever system the institution uses to record research activity.
The only thing these four groups share is the page they appear on. How often they change, which system holds them and who is responsible for them are all different.
Why institutional information and publication records are managed separately
Institutional information changes slowly and is managed centrally. A title changes once every few years. A department affiliation may never change. Publication records only grow. A paper is accepted, a conference talk is delivered, a grant starts.
Institutions that squeeze both into a single form tend to end up in the same place. The central team has no capacity to enter publications, and the academic never opens the form because they cannot change their own title anyway. Within a year the page is one nobody touches.
Student-side information follows a different logic again, which we covered in Drupal student information system integration. There the institution produces the record. Here the researcher produces it, and that difference shapes every decision below.
Where publication records sit before they reach the website
The website is the last stop, not the source. Before a publication can appear on a profile page it has to exist somewhere else in a structured form. In most institutions that means one of two systems, and sometimes both.
Research information systems and repositories
Larger research universities run a current research information system, often alongside an institutional repository that holds the full text. These systems are built to collect publication metadata from external databases, remove duplicates and attach each record to the right person.
Oxford's own IT service pages describe exactly this arrangement, noting that when the research information system is suitably configured it feeds research information to other university systems, including public-facing profiles on departmental websites. That sentence describes the target state for most institutions. The website displays, the research system decides.
Faculty activity reporting systems
Other institutions, particularly in North America, collect the same information through a faculty activity reporting system used for annual reviews, promotion and tenure. The academic already has to enter their output there, which makes it the most complete record on campus.
Using it as the source for the website is attractive for that reason, but it comes with a caveat. These systems were built for internal review rather than publishing, so the data does not always arrive in a shape a public page can use, and the export usually needs work before it is presentable.
Three ways to get publications onto the website
Which option fits depends on how many academics are involved and on how settled the institution's existing systems already are.
Manual entry
The academic fills in a publications field on their own page. It is the fastest thing to set up and it works in small departments. The weakness is duplication. The same publication now sits in the research system and on the website, the two copies stop matching, and nobody can say which one is current.
File import
The academic exports their publication list as a BibTeX or RIS file and the site imports it. Every reference manager produces these formats, so there is nothing new for the researcher to learn. This is the sensible middle ground. It is not automatic, but it is far faster than retyping and the information arrives split into proper fields.
A live feed from the research system
The site connects to the institution's research system and reads publications from it. Done properly this gives the best result, because there is one record and the website simply shows it. In exchange you are building a connection between two systems and committing to maintain it.
Most large research universities abroad take this route. Oxford's arrangement described above is the clearest public example of it.
| Manual entry | File import | Live feed | |
|---|---|---|---|
| Setup effort | Low | Medium | High |
| Staying current | Depends on the person | Periodic | Continuous |
| Best suited to | Small departments | Mid-sized faculties | Institutions with a settled research system |
| Main risk | Two records that stop matching | Refresh gets forgotten | Gaps upstream become visible |
What Drupal gives you and what it leaves to you
One point is worth settling before the tooling. A research-focused Drupal distribution was recommended for years and is still named in comparison articles, but its older release is no longer maintained and the current offering is not covered by the Drupal security advisory policy. Harvard, where that distribution originated, has been migrating its sites off it onto a new Drupal platform, with the transition running through August 2025. It is worth checking the maintenance status of any named option against its own project page rather than against a list of recommendations.
How the citation style is set
A publication list is not a block of text. Author, title, journal, year and DOI have to be held in separate fields. The same publication may appear in short form on a department listing and in full on a profile page, and that is only possible if the fields were kept separate from the start.
On the Drupal side this is handled by the Bibliography & Citation module. Version 3.1.2, released on 15 July 2026, is a stable release covered by the Drupal security advisory policy, and 1,349 sites report using it. It imports BibTeX, RIS and EndNote files and recognises more than eight thousand citation styles. In practice that means you do not need development work to apply your institution's citation style, you select it in the settings.
Holding publication titles in more than one language is a separate question that changes the field structure, and we covered that side in multilingual management in Drupal.
How much the free ORCID service covers
ORCID gives researchers an identifier of their own. Showing that identifier on a profile page is now common, and some institutions want to go a step further and pull the publication list straight from the ORCID record.
There is a limit worth knowing before the project starts. According to ORCID's own documentation, the free service is read-only. You can read the public works on a researcher's ORCID record and display them on the site. You cannot add a publication from your own system to that record. Adding requires membership, and membership is paid. Knowing this before the project starts avoids a budget problem later.
It is also worth being realistic about ready-made modules. Drupal's ORCID module lets people sign in to the site with ORCID and reports eight sites using it. The separate module for pulling publications reports a single site and is not covered by the security advisory policy. Those numbers point to one conclusion: ORCID connections are not installed from a module, they are built for the institution.
Who will keep the page updated?
Once the technical work is finished one question remains. Who is allowed to change what on the page?
A three-tier arrangement works comfortably in most institutions. The academic edits their biography, research interests and photograph. Department administrators manage contact details and teaching links. Title and appointment information is changed by nobody, because it arrives from the institutional system.
If the publication list arrives automatically, that field has to be closed to editing. Otherwise an academic corrects something on the page, the next import removes the correction, and nobody trusts the system again.
How these tiers are built in Drupal is covered in our article on user roles and permissions.
What can be published on a public staff page?
Not everything on the page falls into the same category. Title, department and institutional email are professional contact details tied to a public-facing role, and they are expected to be public. Mobile numbers, personal email addresses and home addresses are personal data.
Under the GDPR and the UK GDPR, publishing professional contact details for such a role is normally straightforward, while personal contact details need a lawful basis and, in practice, consent that can be withdrawn. In the United States there is no single federal equivalent covering staff directories, so institutional policy and state law apply instead. FERPA is often cited here by mistake. It protects student education records, not faculty contact details.
The site-side answer is the same under either regime. Personal fields belong in their own group on the profile form, closed by default, opened by the academic if they choose. That way the record of consent sits inside the system rather than in somebody's inbox.
Where should you start?
The first step is not choosing software. It is answering four questions in writing. What will appear on the page? Which system will hold each piece of information? How often will the publication list update? Who can change what?
Once those four answers exist, the choice between manual entry, file import and a live feed usually makes itself. Projects that skip them tend to launch successfully and then watch the profile pages empty out over the following two semesters.
It is also worth setting expectations early. Drupal gives you a solid foundation for this work, not a finished product. Modelling the publication fields, configuring citation output and building the import is a project.
One practical suggestion. Rather than converting the whole institution at once, start with a single faculty whose publication records are already well kept, run it for one academic year and look at the result before committing further.
The Drupal platforms that the Drupal4edu team at Drupart builds for institutions such as Ozyegin University, Kadir Has University and Acibadem University are designed around this principle, where the site shows the information held in the institution's own systems rather than becoming another place the same records have to be maintained. You can read more about our approach on the Drupal in higher education page.
Frequently asked questions about faculty profile pages
Can a publication list update automatically?
Yes. If the institution's research system offers a usable connection, the site reads publications from it and the list updates on its own. The one condition is that the records upstream are kept in order, because an import moves existing information rather than completing it. Once an automatic import is in place the publications field should be closed to editing on the website, otherwise corrections made on the page are removed at the next refresh.
Should the website read from ORCID or from the institution's own system?
From the institution's own system, in most cases. ORCID records are maintained by individual researchers and coverage varies widely from person to person, so a page built on ORCID will look complete for some staff and sparse for others. A research information system or activity reporting system is kept up to date because reviews and reporting depend on it, which makes it the more complete record. ORCID works well as an identifier shown on the page and as a secondary source, rather than as the main one.
Is pulling a publication list from ORCID free?
Reading is free. ORCID's public service lets you read the public works on a researcher's record and display them on your site. The paid part is adding. If you want to push a publication from your institutional system into a researcher's ORCID record you need membership. For most university websites reading is enough, because the site's job is to show publications rather than to maintain the ORCID record.
Is there a ready-made Drupal module for publication lists?
For publication records and citation output, yes. The Bibliography & Citation module covers that need, its stable release is under the security advisory policy, and it imports BibTeX and RIS. For ORCID the picture is different. The available modules cover sign-in and connection only, and their reported usage sits in single and low double figures. Those numbers show that expecting a ready-made solution is not realistic. ORCID connections are built for the institution in practice.
Can a faculty member's mobile number be published on their page?
Only with their consent. Title, department and institutional email are professional contact details tied to a public-facing role and are normally expected to be published. A mobile number or personal email address is personal data, covered by the GDPR in the EU and UK and by institutional policy and state law in the United States. The practical approach is the same either way. Keep those fields in a separate group on the profile form, closed by default, and let the academic open them if they want to. Consent has to remain reversible.