in2studyfinder for TYPO3

Prospective students expect a search engine, not a PDF brochure

Universities with 50 to 300 degree programs face a concrete problem: prospective students want to filter, not scroll. They search by degree type, department, study format and location, all at once. in2studyfinder by in2code solves exactly that within TYPO3. The extension was built specifically for higher education and maps the complex mix of bachelor’s, master’s and Diplom degrees, full-time, part-time, dual and part-time-while-working formats in a single filter form. More than 20 German-speaking universities run it in production.

For university web teams that have so far maintained their program information on static pages or with home-grown solutions, switching to in2studyfinder brings a significant efficiency gain. Instead of creating a separate subpage for every new program, editors maintain one record in the backend, and the extension generates the list view, detail page and filters automatically. For a university of applied sciences with 80 programs, that saves an estimated 40 hours of initial setup compared with a manually built page structure.

Typical use cases range from program directories to accreditation overviews

The standard scenario is the central program finder on the university homepage. Prospective students land on one page, select department, degree and study format, and immediately get a filtered list. One click leads to the detail page with the module plan, admission requirements, application deadlines and contact persons. At a university of applied sciences with 80 programs, this cut the number of page views needed to reach the desired information from an average of 6 to 2.

The second scenario is cross-campus search at universities with several locations. A university with campuses in three cities shows all programs in one view and lets visitors filter by campus. The location is maintained as a separate relation rather than as free text, which guarantees consistent filtering.

The third scenario is accreditation overviews for quality assurance. Universities have to document which programs are accredited and until when. in2studyfinder can map this metadata as custom fields and show it in the list view, which the accreditation office then uses as its working basis. An export of the program data as CSV or PDF also makes it easy to pass the information on to the German Accreditation Council (Akkreditierungsrat) or other external bodies.

Technical architecture built on Extbase records with configurable relations

in2studyfinder is an Extbase/Fluid extension by in2code, the TYPO3 service provider behind powermail and in2publish. Degree programs are stored as domain records in a dedicated table. Each record contains mandatory fields such as title, degree type, standard program duration, ECTS credits and department, plus optional fields for the admission grade cutoff (numerus clausus in Germany), tuition fees, accreditation status and application link.

Filtering in the frontend runs on AJAX requests, so the page doesn’t reload while visitors filter. That noticeably improves the user experience, especially on mobile devices. The filter configuration is controlled via TypoScript: which fields appear as filters, which sort order applies and how many results show per page.

The templates are Fluid-based and can be overridden in the sitepackage. The extension ships with default templates that work as a starting point for most universities. For universities with their own corporate design, we adapt the templates and integrate them into the existing sitepackage, so program pages fit seamlessly into the website.

Common problems involve data quality, performance and multilingual content

The biggest problem during rollout is data quality. At universities, program information often lives in three to five different systems: HIS/HISinOne, the departments’ own databases, PDF brochures and hand-maintained website copy. Before in2studyfinder can go live, these sources have to be consolidated. Gosign supports this process with a structured import template that the departments fill in and that we import into TYPO3 automatically.

The second problem is performance with large data volumes. Universities with more than 200 programs and complex relations (department, location, study format, language) can see latency in the AJAX filtering if the database queries aren’t optimized. Indexes on the relations and properly configured caching in TypoScript usually solve the problem completely. Warming up the cache after every data change also helps, so the first visitor after an update doesn’t hit a slow page.

The third problem is multilingual content. International universities with English-taught programs need a consistent translation of the filter forms, categories and detail pages. in2studyfinder uses the TYPO3 translation framework, but the fallback languages and translation overlays have to be configured carefully to match the university’s requirements. This matters most for programs offered in only one language (for example, a bachelor’s taught in German but a master’s taught in English): the fallback behavior has to be set up so that filtering works per language and never returns misleading results.

A fourth problem that Gosign sees regularly in university projects: program names that change over the years. The old German “Diplom” in computer science becomes a “B.Sc. Computer Science” but keeps the same detail URL. The extension has to be configured so that name changes don’t create broken links and old URLs redirect to the current page.

TYPO3 v12 and v13 are supported, v14 depends on in2code’s release plan

in2code maintains in2studyfinder actively and ships updates regularly. The 12.x series covers TYPO3 v12, and since September 2025 the 13.x series covers TYPO3 v13 (most recently 13.1.2 from August 2026). Since in2code is a commercial TYPO3 service provider with a long-term product strategy, a version for TYPO3 v14 can be expected, but it has not been released yet (as of September 2026). When upgrading from v10 or v11 to v12, the breaking changes mainly affect the TypoScript configuration (the new TypoScript parser in v12 no longer accepts a few rarely used constructs) and any custom ViewHelpers in the templates. The database structure stays stable, so a data migration is usually not necessary.