Upgrading from 2.3 to 3.0 

This page takes an installation of academic_persons 2.3 straight to 3.0, without the step to 2.4. Version 3.0 drops TYPO3 12, changes the shape of the settings file and rebuilds the public detail view. From 2.4 it takes over the content elements that stay hidden until a site includes the page TSconfig of their components. The page leaves out the 2.4 states that 3.0 replaces: version 1.x of environment_state_manager, see Important: New required dependency fgtclb/environment-state-manager, and the settings file in the shape of 2.4, see Feature: A validator flag that locks the frontend editor only and Important: Address postcode and street number accept text, which the page migrates once, to the shape of 3.0. Work through the sections in order. Skip a step that does not apply to the installation.

Before you start 

Version 3.0 runs on TYPO3 13.4 from 13.4.35 on and on TYPO3 14.3 from 14.3.7 on, with PHP 8.2 or later.

academic_persons 3.0 needs these packages. Upgrade them first or in the same deployment, in this order:

  • fgtclb/environment-state-manager 2.x, new since 2.4, which this extension and academic_base 3.0 require. It is declared in composer.json as ^2.0.1 and in ext_emconf.php as 2.0.1-2.99.99. Composer installs it on its own. A classic installation installs environment_state_manager 2.x before it activates academic_base 3.0 or this extension.
  • fgtclb/academic-base 3.0, the same release as this extension.

The extensions that require this one follow it in the same deployment, where installed: academic_persons_edit, academic_contacts4pages and academic_persons_sync. Where academic_persons_edit is installed, its upgrade chapter is due in the same deployment, because its editor is replaced and one of its wizards repairs the profile images of this extension.

These changes have to ship in the same deployment as the update:

  • The contract rows the database update cannot convert are corrected first, see Update the database.
  • A site without a site set includes the page TSconfig of the components, or the content elements are no longer offered, see Make the content elements selectable.
  • Project code that extends a class, implements an interface or overrides a method of this extension whose signature changed follows it, or it fails with a fatal error, see Adapt your code.

The module paths on this page are those of TYPO3 13, where the upgrade runs.

Update TYPO3 first 

Update TYPO3 to 13.4.35 or later while the site still runs 2.3, which supports TYPO3 13.4. Version 3.0 no longer installs on TYPO3 12, and Composer and the Extension Manager refuse it next to an older patch release of TYPO3 13.

Stay on TYPO3 13 until the upgrade is complete. The content element wizard academicPersons_MigrateListTypeToCTypeContentElements of this extension reads the column tt_content.list_type , which TYPO3 14 removes, so it only runs on TYPO3 13. The same holds for the content element wizards of academic_jobs, academic_persons_edit and academic_projects when the installation also has them. Move to TYPO3 14.3.7 or later once they have run.

See Breaking: Removed TYPO3 v12 support and Important: TYPO3 13.4.35 or 14.3.7 is required.

Update the package 

composer require -W \
    'fgtclb/academic-base':'~3.0.0' \
    'fgtclb/academic-persons':'~3.0.0'
Copied!

On a classic installation, install environment_state_manager 2.x from the TER in Admin Tools > Extensions first, because neither academic_base 3.0 nor this extension can be activated without it. Then update academic_base, academic_persons and the extensions that require it there, in this order. Run the commands of this page with typo3/sysext/core/bin/typo3 instead of vendor/bin/typo3 .

vendor/bin/typo3 cache:flush
Copied!

Update the database 

Three of the changes cannot be applied to every database as it is. Check them before the update:

  • The contract columns organisational_unit , function_type and location become NOT NULL . The change fails on PostgreSQL and on MySQL in strict mode while a row holds NULL , which a contract saved with an empty relation by 2.3 does. Update those rows to 0 first, Important: Contract relation columns are NOT NULL now has the statements.
  • The year columns of the timeline entries become unsigned. Correct a negative year first, which nothing of the extension ever wrote. See Important: The timeline year fields are constrained.
  • The contract column publish is removed. Do not accept its removal yet, The contract field "publish" decides whether its values are carried over first.
vendor/bin/typo3 extension:setup
Copied!

Or apply the changes in Admin Tools > Maintenance > Analyze Database Structure.

Versions 2.4 and 3.0 change these tables, and the comparison also applies the changes of the index definitions TYPO3 13.4.35 and 14.3.7 bring:

  • The contract table gets the column organisational_unit_sorting , which an upgrade wizard of the next step fills.
  • The nine record tables of this extension are workspace aware now and get the columns t3ver_oid , t3ver_wsid , t3ver_state and t3ver_stage with an index. Until they exist, the backend record lists of the extension and the frontend rendering of a translated profile fail with a database error. On SQLite, check afterwards that the nine tables really carry the four columns, the command line path of TYPO3 adds only the index there. See Breaking: Person records are workspace aware.
  • tx_academicpersons_domain_model_function_type and tx_academicpersons_domain_model_organisational_unit get a slug column, which an upgrade wizard of the next step fills.
  • The three contract relation columns and the three year columns change as described above.
  • tx_academicpersons_domain_model_address gets an index on import_identifier , see Feature: Import identifiers are shown, searchable and can be looked up.

The analyzer offers tx_academicpersons_domain_model_contract.publish for removal. It never drops a column on its own.

Run the upgrade wizards 

Run the wizards in this order, after the database update, and on TYPO3 13:

  1. academicPersons_MigrateListTypeToCTypeContentElements, Migrate "EXT:academic_persons" from list elements to content elements (list_type => CType), only if it is still offered.
  2. academicPersons_seedContractOrganisationalUnitSorting, Seed the contract sort order of academic organisational units.
  3. academicPersons_fillFilterSlugs, Generate the URL segments of academic function types and organisational units.
  4. academicPersonsEdit_repairLocalizedProfileImages, Repair the profile image relations of academic profiles, of academic_persons_edit, where that extension is installed.
vendor/bin/typo3 upgrade:run academicPersons_MigrateListTypeToCTypeContentElements
vendor/bin/typo3 upgrade:run academicPersons_seedContractOrganisationalUnitSorting
vendor/bin/typo3 upgrade:run academicPersons_fillFilterSlugs
Copied!

A wizard that TYPO3 recorded as done is offered again once it is marked undone. TYPO3 13 marks a wizard undone with vendor/bin/typo3 upgrade:mark:undone <identifier>. The two repeatable wizards of this step are never recorded as done.

academicPersons_MigrateProfileAutoCreateExtensionsConfiguration shipped with 2.3 already. An installation that ran it there has nothing more to do.

The content element wizard 

academicPersons_MigrateListTypeToCTypeContentElements shipped with 2.x already and moves content elements stored as list with a list_type of this extension onto their own CType . An installation that ran it there has nothing more to do. TYPO3 14 no longer has tt_content.list_type , so the wizard has to run on TYPO3 13, before the core update. Run it by its identifier and not with a bare vendor/bin/typo3 upgrade:run : the wizard is not repeatable, and a run on TYPO3 14 that finds nothing records it as done although it migrated nothing. Replace own TypoScript, TSconfig or SQL that matches on list_type with a condition on CType . See Breaking: Extbase plugins require CType on TYPO3 v14.

The sort order of the organisational unit contracts 

A contract is an inline child of its profile and of its organisational unit, and both relations wrote the same sorting column in 2.3, so saving an organisational unit rearranged the contracts of every profile that owns one of them. The unit relation has a column of its own now, which the database update adds and the wizard Seed the contract sort order of academic organisational units, academicPersons_seedContractOrganisationalUnitSorting, fills with the order the unit forms show today. Without it every contract carries 0 in the new column until an editor saves its unit. Profiles keep ordering their contracts by sorting , so the frontend is not affected either way. See Important: An organisational unit sorts its contracts on its own.

academic_partners and academic_contacts4pages ship the same repair for their own tables, as academicPartners_seedPartnershipRoleSorting and academicContact4pages_seedContactSecondarySorting. Run them in this step where those extensions are installed.

The URL segments of the filter records 

The wizard Generate the URL segments of academic function types and organisational units, academicPersons_fillFilterSlugs, is new in 3.0. It gives every live function type and organisational unit without a slug the one a backend save would generate from its name, and leaves a slug that is set alone. The filters of the profile list read the slug, so a list filtered by a function type reads /persons/function/professor, see Filtered lists. Without it a filter keeps working as a query argument. See Feature: A filter form and speaking URLs for the visitor list.

The wizard is repeatable. It is offered again whenever a record has no slug, for example after an import of a project wrote one without it.

The profile images of translations 

The profile image is translatable now. A translation follows the image of the default language until it gets an image of its own. The image relations that academic_persons_edit wrote before 3.0 do not always fit that, and its repeatable wizard academicPersonsEdit_repairLocalizedProfileImages repairs them through the DataHandler, without deleting a file. Run it where that extension is installed and profiles have images, before editors use the new editor of a multilingual site. Its upgrade chapter describes the wizard. See Breaking: The profile image translates.

Code that read the image of a translation through the record of the default language resolves the reference of the translation now.

The contract field "publish" 

The contract toggle Show this contract online? is removed with its column publish . No view of the extension has ever read it, so the visibility of every contract stays as it is. See Breaking: The contract field "publish" has been removed.

Only a project whose own code gave the flag a meaning, and left contracts out that were not published, carries it over to the visibility of the contract. The wizard academicPersons_migrateContractPublishToHidden does that, and it ships unregistered, because on every other installation it would hide all contracts. Register it in the Configuration/Services.yaml of the site package, flush the caches, run it, flush the frontend caches, and remove the registration again. Important: The contract publish wizard has to be registered by hand has the registration and the order.

Then let the database analyzer drop the column. Once it is dropped, nothing can be migrated any more.

Adapt the configuration 

The upgrade check 

The console command academic:upgrade:check of academic_base reads the stored configuration of the installation and reports what no longer reaches the academic extensions. For this extension it reports a TypoScript record or an import of a file that is gone, two fields of the settings that write one column, and a site that still depends on the set fgtclb/academic-persons-default or fgtclb/academic-persons-standalone, which keep working as aliases of fgtclb/academic-persons. Run it on the staging copy right after the package update, and again once the steps of this section are done:

vendor/bin/typo3 academic:upgrade:check
Copied!

With the extension key and a site it also finds the template overrides of the site whose file is gone, and copies that are identical to the shipped file:

vendor/bin/typo3 academic:upgrade:check academic_persons --site=<site identifier>
Copied!

Each finding, and what to do about it, is described in the upgrade check of academic_base.

Make the content elements selectable 

The site sets and static templates are cut per content element since 2.4, and the six content elements are hidden for the whole installation until the page TSconfig of their component brings them back. See Breaking: Site sets and static templates have been restructured for the complete change.

  • Without a site set: add Academic Persons: All components (academic_persons) in the page record of every site root, tab Resources, field Include static Page TSconfig (from extensions), or the entries of the single content elements a site should offer, see Include static page TSconfig. This entry did not exist in 2.3. Without it the content elements are no longer offered in the backend.
  • With a site set: nothing to do. The sets fgtclb/academic-persons-default and fgtclb/academic-persons-standalone keep their names and deliver the page TSconfig of all six content elements. A site may name the aggregate fgtclb/academic-persons or single component sets instead.

Use one mechanism per site, never a site set and a static template together, see Do not combine both.

Until a component is included, an existing content element of it keeps rendering and keeps its type: academic_base shows the stored type in the field Type followed by (not enabled on this page), and saving keeps it. The warning of the 2.4 changelog entry that saving such a record rewrites its type describes the state before a fix that academic_base 2.4 carries as well, see its changelog entry. A content element that a page TSconfig of your own already turned into another type is not repaired. Correct it by hand from its record history.

The Person Contact Card offers the field Detail Page, which the page TSconfig of 2.3 disabled. To keep it hidden, see Important: The profile card offers the detail page.

Static templates and imports 

A sys_template record keeps working without a change. Both values its field Include TypoScript sets on the tab Advanced Options can store, EXT:academic_persons/Configuration/TypoScript/Default and EXT:academic_persons/Configuration/TypoScript/Standalone, still resolve. Only their labels changed, to Academic Persons: Shared plugin settings and Academic Persons: Standalone page.

An @import of a shipped file in a site package has to be checked. These files were removed:

An @import of a missing file fails silently and shows up as missing configuration. The breaking change entry linked above has the table of old and new paths.

Grouping and sorting of the profile list 

The defaults of plugin.tx_academicpersons.demand.groupBy and plugin.tx_academicpersons.demand.sortBy are the same with and without a site set now, lastNameAlpha and lastName.

  • A site without a site set now groups a profile list by the first letter of the last name unless it sets demand.groupBy itself. Set the constant to an empty value to keep an ungrouped list.
  • A site on a site set now sorts a profile list by last name unless it sets demand.sortBy itself. The value title the sets shipped up to 2.3 was rejected by the extension, so these lists had no ordering at all.

The settings file 

A site package that ships its own Configuration/AcademicPersons/Settings.yaml has to be migrated. The file is built from four maps now, profile , special , contracts and documentSections , and the top-level keys validations and profileInformationsTypes of 2.3 are gone. See Breaking: Section-based AcademicPersons settings.

A file that still ships the old keys keeps working for now. They are mapped onto the new maps at runtime, with a warning in the log, until version 4.0. The migration command prints the maps that replace them:

vendor/bin/typo3 academic:persons:settings:migrate
Copied!

It never writes the file, and it exits with 1 while a package ships an old key. Paste the printed maps into the site package in place of the old keys, review them and flush all caches. Read the notes the command prints: a changed type or fieldName of a timeline type is not applied, a timeline type of a project needs its own column in a TCA override of the profile table. See Feature: Legacy settings overlay and migration command and Migrating a pre-3.0 override.

The settings files are merged recursively now. A key the override leaves out is inherited from academic_persons, at every level, where leaving it out removed it before. An entry that is to be gone is set to ~ , a flag list that is to be empty to [] . Compare the override with the shipped file key by key, --delta prints the keys a copied map leaves out:

vendor/bin/typo3 academic:persons:settings:migrate --delta
Copied!

See Breaking: Settings files merge recursively and Feature: Settings overrides are reported and shrunk.

The shipped defaults changed as well: the gender of a profile and the start date of a contract are required, the website, the publications link and the links of the timeline entries carry the url flag, the type of an email address or a phone number is no longer required, and the postcode and the street number of an address lose the number flag, so they are stored as entered. Change them in the override where the installation wants the old behaviour, Profile sections documents every key.

TCA overrides of the person tables 

The settings set required and readOnly of a column after every TCA override of a site package now, not before. A site package that sets either of them on a configured column in Configuration/TCA/Overrides loses that value. Move the lock or the requirement into the settings file. See Breaking: Settings apply after the TCA overrides.

A site package that names a FlexForm data structure of this extension by path checks the path. Core12/ is gone, SelectedProfiles.xml and SelectedContracts.xml are directly in Configuration/FlexForms/ now, List.xml and Detail.xml have a Core13/ and a Core14/ variant. See Important: FlexForm paths change for the plugin structures.

Extension configuration 

Two options are new, profile.feuser.telephoneNumberType and profile.feuser.faxNumberType. They decide which phone number type the telephone and fax numbers of a frontend user are imported as, and default to business. The next synchronization run writes business where an imported record still carries the type phone or fax and the installation does not offer it. Set the options in Admin Tools > Settings > Extension Configuration to type the imported numbers differently. See Feature: Configurable frontend user phone number types.

Check the lists demand.allowedSortByValues, demand.allowedGroupByValues, types.emailAddressTypes, types.phoneNumberTypes and types.physicalAddressTypes for an entry without a value, such as =Private. Such an entry is ignored now, and a record stored with it shows its type as an invalid value in the backend until it is saved with another one. See Important: Empty configured values are ignored.

Routing 

A site configuration that imports more than one of the route enhancer files List.yaml, ListAndDetail.yaml and Detail.yaml has to limit each enhancer to the pages that carry its plugin with limitToPages . Otherwise the enhancer imported first takes the URLs of the others, and the detail page answers 404. See Important: Route enhancers have to be limited to their pages and Route enhancers.

Labels 

Profile synchronization 

academic:createprofiles and academic:updateprofiles process hidden profiles and disabled frontend users as well now, and ignore the start and end time of profiles and frontend users and the frontend user groups of profiles. They update the data of such a profile and leave its visibility alone. A profile that was kept out of the synchronization by hiding it, or by disabling its frontend user, is overwritten by the next run.

Before the first run, set Disable profile sync ( skip_sync ) on every profile that must not be synchronized. See Breaking: Profile synchronization now includes hidden profiles and users and Important: Profile synchronization ignores the visibility window.

academic:createprofiles also creates a profile for a disabled frontend user, and for one outside its start and end time, that has none yet. Exclude the page of such frontend users with --exclude-pids , or delete the profiles created for them.

Both commands refuse a value of --include-pids or --exclude-pids with a part that is not a page uid, and exit with code 2. Check the arguments of scheduler tasks and scripts. See Important: Profile create and update commands refuse wrong page lists.

academic:updateprofiles stores new records next to their profile or contract instead of on the page of the frontend user. Moving the records an earlier run stored there is optional, Important: Updated profiles keep new records on their page has the queries that find them.

Adapt templates and assets 

An override keeps its own copy and does not receive a change of the shipped file. The upgrade check with the extension key and a site finds overrides of files that are gone, and copies that are identical to the shipped file, see The upgrade check. Compare every other override with the shipped file of 3.0 and take the changes over. Overriding templates describes how the overrides are set up. Every template translates its labels with the extension name AcademicPersons now, which moves the path of a label override, see Labels. The paths below are relative to Resources/Private/:

File What changed Entry
Templates/Profile/Detail.html Rewritten. It dispatches the configured elements to the partials below Partials/Profile/PublicProfile/. An override keeps rendering its own copy and loses the configurable layout. Feature: Configurable public profile
Partials/Profile/DataHeader.html Deleted. A template that still renders it fails at render time. Partials/Profile/Header.html and Partials/Profile/SectionHeader.html are no longer rendered by the detail view. Breaking: The partials of the detail view change
Partials/Profile/Header.html, Partials/Profile/SectionHeader.html Take the class of the heading as the argument class in place of positionClass. Breaking: Header partials take a class argument
Partials/Profile/Item.html, Partials/Profile/List/ItemList.html Built from small partials below Partials/Profile/Item/ and Partials/Profile/List/. A copy of the two files does not reach the small ones, and a copy of the contract partial reads detailLink in place of detailUri. The name leaves out empty parts. Important: The profile item and list are built from partials, Important: Profile names leave out empty parts
Partials/Profile/Contract/Field.html Renders the organisational unit and the title of the location, a tel: target without spaces, and the office hours as HTML. Important: Contract rows render the location, the unit and dialable phones, Important: List items render office hours as HTML
Partials/Profile/List/AlphabetPagination.html, Templates/Profile/List.html Letters without profiles are disabled, and a list with a manual selection renders no letter navigation. Important: Letters without profiles are disabled in the letter navigation, Important: No letter navigation for a manual selection

The profile image 

The profile card and the detail view render the image as a <picture> through the image partial of academic_base, and a card of a profile without an image shows a placeholder. Adjust CSS that selected the image as a direct child. Set plugin.tx_academicpersons.image.placeholder.default to an empty value to keep such cards without an image. A view whose partial root paths are replaced as a whole adds -1 = EXT:academic_base/Resources/Private/Partials/ . See Breaking: Profile images render as a responsive picture and Profile image.

Classes and styles 

The templates carry the speaking ace-* classes the academic extensions share, in place of the classes of the Bootstrap card, the list group and the pagination. Only the grid classes, the button classes and visually-hidden of Bootstrap stay. Move the selectors of the site stylesheet to the new classes, the chapter Styling shows the markup of every view. See Breaking: Profile templates carry speaking classes.

The extension ships no stylesheet, as in 2.3. Only the development versions of 3.0 shipped one for the profile views. The detail view needs two rules of the site to work: one that hides the expand or the collapse glyph of a fold-out entry by its aria-expanded state, and one that makes the navigation of the left column sticky. The stylesheet of the development instances is an example, see An example and Breaking: The profile views ship no stylesheet.

The detail view loads the module @fgtclb/academic-persons/frontend/profile.js. A site that brings a script of its own switches it off with plugin.tx_academicpersons.assets.js , see Feature: The script of the public profile can be switched off.

Icons 

Every icon of this extension is renamed, without an alias. The record icons are tx-academicpersons-record-* now, the content element icon persons_icon has three successors tx-academicpersons-plugin-*, and the icon files of 2.3 below Resources/Public/Icons/ are deleted. An old identifier renders TYPO3's default-not-found placeholder. Replace the identifiers in templates, TSconfig, TCA, PHP and CSS of the site package, and move a replacement icon to the new identifier. See Breaking: Renamed icons and a frontend icon registry.

Adapt your code 

Check the result 

  • The upgrade check exits with 0, without and with the extension key, see The upgrade check.
  • vendor/bin/typo3 academic:persons:settings:migrate exits with 0, and the log carries no warning about legacy settings.
  • The new content element wizard offers the content elements on the pages of every site that should have them, under the titles of 3.0, see Important: Content elements have new titles and descriptions, and an existing persons content element opens in the backend with its own type.
  • The backend record lists of the extension open, and a translated profile renders in the frontend.
  • A profile list groups and sorts its profiles as intended, and a list filtered by a function type or an organisational unit shows the slug in the URL.
  • An organisational unit form lists its contracts in the order it showed before the update.
  • The detail page is hidden in menus. A request of it without a profile ends with the "page not found" handling of the site, see Important: The profile detail answers "not found" without a profile.
  • Where organisational units are translated, no contract shows twice on a profile. Important: Localizing an organisational unit leaves contracts alone has the query that lists the contracts an earlier localization created.
  • A translated profile shows an image in every language, and a timeline entry shows its year in the frontend and in the backend form.
  • The detail view folds its entries in and out, and the site stylesheet reaches the lists, the card and the detail view.
  • A run of academic:updateprofiles exits with 0, and a profile with Disable profile sync set stays unchanged.