sic_address is a new address extension that can either enhance an existing tt_address installation or easily be used to start a new address management from scratch.
Originally it was written in 2016 to replace extensions like nicos_directory, wt_directory or sp_directory and grew from there.
Meanwhile it is used in a good dozen of our projects and we thought it was getting to the point where it can be shared with others.
All required fields can be added dynamically like for example in mask/powermail. (incl. strings, images, dropdowns, rte text, mm-tables)
This can be done either from scratch or as an enhancement on top of tt_address.
There's an Export Module for exporting data.
And A Geolocation scheduler task that is retrieving GPS coordinates from Google Maps.
It offers 'List' and 'Single Address' display, as well as 'Adding' addresses in the frontend.
All sorts of list filters can be applied to the frontend (dropdowns, a-z picker, categories)
Half a dozen fluid examples exist for frontend templates (incl. nicos_directory and sp_directory)
Half a dozen code examples exist for data and/or table migration (incl. nicos_directory, tt_address and sp_directory)
First install and activate the extension as usual, then add the static template to any root page of your installation. Frontend output and the backend modules will only work on root pages with the static template included or their children.
Next configure the extension in the Extension manager. There's explanations for the available options.
Recommendations from us:
- You usually enable the developer Mode until you go Live. It lets you configure the database fields and data imports while working on the product, later you no longer need this module.
- Enable tt_address Mapping only on an installation you want to enhance that already works with it. If you start a project from scratch, tt_address is usually not required. (It can jumpstart you with a normalized set of address fields, so you only have to add fields you are still missing)
- You can try all the existing templates, but whether they work depends on how good the field names match. Try nicosdir for migrations from nicos_directory, spdir for migrations from sp_directory. Most of the others should deliver good results when the fields have common english names like 'street', 'company', 'city', etc.
- Best practise: Outsource the templates to fileadmin, pick the one looking best for you and change it according to your needs.
sic_address can seemlessly work on top of an exsiting installation already running a tt_address database in order to enhance it with new fields, fluid templates or other features. It won't alter or change tt_address itself nor its tables, but it's still recommended to add sic_address on a develpoment version of the website and not straight on a live system. In case something goes wrong - always have a backup ready!
- tt_address must already be version 3.0.0 or higher, since sic_address works with sys_category exclusively.
- If you upgraded from an older tt_address version, make sure to run upgrade scripts, update wizards and all suggestions from the database analyzer as available.
- Third party extensions requiring tt_address_group will no longer work properly then, you have to disable them or port them over to use sys_category.
- In the extension configuration of sic_address, make sure "tt_address Mapping" and "Developer Mode" are checked!
Once the prerequisites are done, please open the backend and execute these steps in order:
- Click the button "Import tt_address Field Definition".
- Click the button "Generate Model, TCA, l18n, DB".
When successfull, you should now get a list with all tt_address fields already enhanced by third party extensions and an empty line where you can start creating new fields as desired. tt_address fields got entered into the table "tx_sicaddress_domain_model_domainproperty" with the flag "external" set to 1. They are fully handled by sic_address now, but not shown in the list by design, as we don't want sic_address to change them.
Due to the self-modifying nature of the extension it'll create several files within its own folder. These are normally written the first time during installation and later again when the button "Generate Model, TCA, l18n, DB" is clicked in the backend module. So when you update the extension, these generated files naturally will disappear. This is no cause for alarm though, just open the backend module and click "Generate Model, TCA, l18n, DB" once to generate them anew. This procedure will often also apply updates coming with the new extension version, as it's the only way for the new features to move into the TCA or model files.
We may do that automatically in a future version of the extension.
This is a future enhancement currently still on our todo list. In all our Live usecases so far we usually display all detail in the list already and just shrink it with filters like here for example:
The detail plugin is currently used only to display a dedicated address e.g. on an imprint page.
Im Backend Modul den passenden Importer laufen lassen.
Nach Wunsch Felder hinzufügen, beschriften, typisieren
Generate Model Button drücken.
Reserviertes Feld für Lightbox, bei Bedarf anlegen!
Unter http://domain/vianovis.xml können entsprechende Daten generiert werden, sofern folgender Eintrag in realurl_conf.php gemacht wird:
'fileName' => array (
'index' => array(
'vianovis.xml' => array(
'keyValues' => array(
'type' => 24853077,
sachonListGesuchtesProdukt = Gesuchtes Produkt:
sachonListGesuchtesProdukt = Desired product: