I've recently came across the OroCRM and really like the idea of the extra tab menu for jumping to each fieldset. It's basically one large form but you can jump to each part of it.

Would be great if something similar will be added to Contao. It's quite often a pain using a large form (i.e. settings or user groups)

OT: OroCRM and their plattform are based on Symfony and are looking very promising. Maybe a good source finding inspiration for Contao moving to the Symfony framework.

Aus dem aktuellen Barrierefreiheit-Test, den Heiko Kunert und ich mit der aktuellsten Contao 4-Version durchgeführt haben:

In der Dateiverwaltung haben die Icons für Ordner (folderC.svg) und Dateien (z.B. iconPLAIN.svg) keine Alternativtexte. Dadurch wird Screenreadern der Dateiname vorgelesen. Es wäre gut, wenn hier die korrekten Alternativtexte vergeben werden, damit sehbehinderte und blinde Nutzer auch wissen, ob sie einen Ordner oder eine Datei vor sich haben (und bei letzterem welcher Typ).

Aus dem aktuellen Barrierefreiheit-Test, den Heiko Kunert und ich mit der aktuellsten Contao 4-Version durchgeführt haben:

Im Standard-Uploader sollten Fehlermeldungen oder wichtige Meldungen wie „Die Datei ... wurde hochgeladen“ auch für Screenreader erkennbar hervorgehoben werden.

Siehe Lösungsvorschlag für Fehlermeldungen/wichtige Meldungen im Ticket contao/core-bundle#770

Contao 3 introduced the dymanic parent table feature for content elements. For backwards compatibility an empty ptable column of tl_content is threated as tl_article, so additional conditions to check this were included in the core.

I think Contao 4 would be a good point to drop this backward compatibility. 3rd party extensions would have to set the ptable always.

An migration script (from Cto 3 to 4) could change any empty ptable value of tl_content to tl_article.

Aus dem aktuellen Barrierefreiheit-Test, den Heiko Kunert und ich mit der aktuellsten Contao 4-Version durchgeführt haben:

Die Icons zum Aufklappen/Zuklappen sind nicht mit passenden Alternativtexten versehen. Dadurch wird Nutzern von Screenreadern nur der Name der Datei vorgelesen.

Dabei wäre es idealerweise so, dass nicht nur einfach "Knoten öffnen" oder "Knoten schließen" ausgegeben wird, sondern jeweils der Name des nachfolgenden Knoten mitbenannt wird. Sonst ist es für sehbehinderte und blinde Nutzer schwieriger zu verstehen, welchen Knoten sie gleich öffnen/schließen werden. Sehende Nutzer können diese Information automatisch erfassen, da sie sehen, dass der Knoten z.B. vor der Seite X oder vorm Ordner Y steht. Sehbehinderte und blinde Nutzer würden hingegen sehr davon profitieren, wenn diese Information unmittelbar im Alternnativtext der Knotenfunktion ausgegeben wird. Der Alternativtext könnte dann z.B. "Knoten für Seite X öffnen" oder "Knoten für Ordner Y schließen" heißen.

Deliver the newsletter at a specified date, time.

You can now send a newsletter immediately, instantly.

It would be useful to define the date and time of the newsletter.
Plan your mailing in advance.

Beim Tabellen-Wizard gibt es die Buttons mit denen man Spalten duplizieren/verschieben/löschen und Reihen duplizieren/verschieben/löschen kann. Leider wurde nur den Buttons jeweils ein title-Attribut zugewiesen, während die Symbole darin keinen Alternativtext haben. Wie schon in anderen Tickets erläutert, wird das title-Attribut vielen Screenreader-Nutzern nicht ausgegeben. Daher sollte der Alternativtext bei den Symbolen umbedingt gesetzt werden.

Bitte ergänzt die Alternativtexte bei den Symbolen für Screenreader-Nutzer (kann der identische Text sein, wie das title-Attribut auf dem umhüllenden Button).

Aus dem aktuellen Barrierefreiheit-Test, den Heiko Kunert und ich mit der aktuellsten Contao 4-Version durchgeführt haben:

Hier die Vorschläge für einige grundlegende Landmarks im Contao-Backend, damit es für sehbehinderte und blinde Nutzer via Screenreader besser erfassbar wird:

• <ul id="tmenu" role="navigation" aria-label="Service-Navigation">
• <nav id="tl_navigation" role="navigation" aria-label="Navigation">
• <div id="main" role="main" aria-label="Hauptbereich">

Über die genauen Benennungen könnten wir sicher noch sprechen. :)

This is a accumulative ticket collecting all the features/todo's for future versions of Contao to better support HTTP/2 to get the best out of it. The list is not final, I'll just keep updating it, every time something comes to my mind.

• Must be able to disable concatenation of files in the page layout.
• Add support for server hints (server push) using either Link: <https://domain.tld/asset.jpg>; rel=prefetch headers or <link rel="prefetch" href="https://domain.tld/asset.jpg"> <head> tags. Also think about other strategies like preload etc.

I had a pb with a customer who wanted to use the 2055 year for something.
i did some search , and find an issue with dates > 2038
and it seems it can be resolved using the DateTime class (php5.2 /5.3)
(i looked at System.php and parseDate function) maybe it could be usefull to rewrite this one ?

did you get this bug also ?

thanks

Für das Erstellen bzw. Modifizieren von Backend-Themes wäre es hilfreich, wenn sämtliche Icons im Backend ergänzend eine gemeinsame Klasse wie z.B. tl_icon hätten. Nur als kleine Anregung :)

In den Listenansichten können assistive Technologien wie Screenreader bei den Funktionsicons nicht ausgeben, welchen Status der Datensatz bei umschaltbaren Funktionen hat. Das betrifft:

• Veröffentlichen/Nicht veröffentlichen
• Hervorheben/Zurücksetzen

Die Nutzer könnten zwar in die Einstellungen des Datensatzes wechseln und dort den jeweiligen Zustand herausfinden, aber das ist insbesondere für Screenreader-Nutzer ein sehr großer Aufwand und völlig unpraktibel, wenn sie ordentlich redaktionell arbeiten wollen. Versucht einfach mal selbst in einer Liste mit z.B. mehreren hundert Seiten/Unterseiten herauszufinden, welche Seiten noch unveröffentlicht sind, wenn ihr das nur tun könnt, indem ihr jede einzelne Seite/Unterseite erst bearbeitet und euch dort bis zum Abschnitt (per Tastatur) durchangelt, an dem - am Ende - gesagt wird, ob die Seite veröffentlicht/unveröffentlicht ist. Es ist schon ein ordentlicher Aufwand, das auf einer großen Seite über die Icons auf der Listenansicht herauszufinden, aber wenn die Redakteure zusätzlich noch in die Details gehen jeder Seite gehen müssten, wird es undurchführbar.

Hallo,

ich würde es prima finden, wenn die Option "Filtern", die bei vielen BE-Modulen zur Verfügung steht, um eine negierte Auswahl erweitert werden könnte.
Ein Beispiel beim Modul Mitglieder: Ich möchte mir alle Mitglieder anzeigen lassen, deren "Land" nicht "Deutschland" ist.

Beste Grüße
Benny

--- Originally created by scheuch on May 25th, 2010, at 02:56pm (ID 2033)

The manual lists some include inserttags which can be used on the following levels:

• Content elements
• Forms
• Modules
• Articles

The first three of these are individual data types, whereas the article is itself a collection of content elements. But Contao also includes other content element collections like news, events etc. for which no inserttag exisits.

I would like to see such an inserttag for other collection types as well, especially for news. It would be especially handy for newsletters (as already mentioned way back in contao/core#1510). It seems (from that old ticket) that there used to be such an inserttag, but I cannot find any reference to it other than that.
Also, the new tag would help to standardize this particular subset of tags (as previously done for the link inserttags).

[RFC] Locale formats

For several days I now read on the topic of Locales in regards to our current handling and the Symfony way. I'm writing down here what I found so we're all up to date and to solve confusion once and for all. Loosely related to contao/core-bundle#190 and contao/core-bundle#171.

Background

In computing, a locale is a set of parameters that defines the user's language, country and any special variant preferences that the user wants to see in their user interface.

https://en.wikipedia.org/wiki/Locale

This is probably familiar to everyone of us.

Locale formats

These two formats are relevant for our case.

1. IETF Language Tag, specified in BCP 47, (aka RFC 5646, RFC 4646, RFC 3066, RFC 1766).
   Used in:
   • HTTP Accept-Language header
   • XML & HTML documents (e.g. <html lang="">)
2. Locale ID, according to the International Components for Unicode (ICU).
   Used in:
   • PHP Intl extension
   • Symfony Intl component, a replacement layer for the PHP intl extension
   • Recommended format for the Symfony Translation component
   • Returned by Symfony Request::getLanguages() (after parsing the HTTP Accept-Language header)

Transifex uses a Locale ID to represent regional languages (e.g. zh_TW) but a Language Tag to represent language scripts (e.g. zh-Hant) :-(

Differences between Language Tag and Locale ID

As far as I understand, there is no major difference for our use case.

• A Language Tag uses a dash (-) as delimiter between language, script and region.
• A Locale ID uses an underscore (_) as delimiter between language, script and country.
• In a Locale ID, the third subtag is always a country (according to ISO 3166) whereas in a Language Tag it can also be an UN M.49 region code.

A Locale ID also does allow to specify more details on locales like the currency, calendar or collation. However, they are (currently) not relevant for our case.

Structure of Language Tag and Locale ID

Apart from the differences noted above, both Language Tag and Locale ID are very similar in their format:

1. The language subtag specified using a two- or three-letter lowercase code (using ISO 639-1 or ISO 639-2).
2. An optional script subtag (specified in ISO 15924)
   (Examples: Latn = Latin, Cyrl = Cyrillic, Hans = Chinese Simplified, Hant = Chinese Traditional)
3. The country or region subtag, commonly using a two letter ISO 3166 country code.

Best practice is to add subtags only if they add relevant information. As an example, it's not recommended to write en-Latn because english is almost always written in latin characters.

Situation in Contao

Just so that everyone is on the same track, I'm quickly writing down the current Contao approach:

• A page language (tl_page.language) is a Language Tag. It can either be two characters ISO 639-1 code (de, en) or a five characters language and country (de-DE, de-CH, en-US).
• Contrary, language files are using Locale ID. The folder name can either be two characters ISO 639-1 code (de, en) or a five character language and country (de_DE, de_CH, en_US).
• The languages list (system/config/languages.php) is also using Locale ID, which means the same applies for member and user language (tl_member.language / tl_user.language).

The writing of both formats is case sensitive. The $GLOBALS['TL_LANGUAGE'] variable is inherited from the page language and therefore is a Language Tag.

As our language folders are a Locale ID, we're converting the representation everywhere where we try to match a page language to a language folder (str_replace('-', '_', $lang)). Because we're relying on Transifex, the package format is somewhat predefined.

Situation in Symfony

Translation

The Translation component accepts numerous formats for the translation files (see [1], [2]). It simply tries to find a file with the given locale.

However, loading fallbacks (zh for zh_CN) only works when using a Locale ID with underscore (see [1]). It does, however, not support three level fallbacks (loads zh_Hant but not zh when locale is zh_Hant_TW).

Request

The request has methods for setLocale and getLocale. They are NOT related to the _locale attribute (see HttpKernel). On a call to setLocale, the property is forwarded to the PHP Intl subsystem if available.

The good news is: the PHP Intl component does happily accept both dash (-) or underscore (_) as delimiter and correctly detects country, script and region.

Intl

The Symfony Intl component provides fallback information if PHP Intl is not available. Same as PHP Intl, it uses Locale IDs (see [1]). I have not tested it, but I doubt it will work with Language Tags.

HttpKernel / Magic

The HttpKernel component contains some dependency injection magic in regards to locale handling. There are two listeners in place:

1. The LocaleListener triggers on kernel.request (priority 16) and calls Request::setLocale if a _locale attribute is found in the current request (see [1]).
2. The TranslatorListener triggers on kernel.request (priority 10) and sets the locale for the default translator from Request::getLocale (see [1]).

Problems

Frontend

In our current implementation (Contao 4.0.0-beta1), the request _locale attribute is parsed from the route path, which means it will be a Language Tag according to the setting in tl_page.language. If zh-TW is set as the page language, the Translator would not find the zh_TW language pack (and it would not load zh either).

If routes do not contain locales (contao.prefix_locale is false), the fallback language will be used for the Symfony Translator. Contao will use the best-matching language from Accept-Language header to find an appropriate page, and use that language then.

Backend

Backend paths do not contain language information. For Symfony Translation, the fallback language (en) will always be used. Contao will use the best-matching language from Accept-Language header.
After a user login, the user's language (tl_user.language) will be used to load Contao languages.

Conclusion

For Symfony, it does not matter what Locale format you use, because it's just a framework. As long as your routes and translation files do match, the Translator will happily load what your URL contains.

The current Contao implementation is not really compatible with Symfony Translation though. It would only be possible to load translations by using Language Code files (messages.de-CH.xliff), which is neither the recommended way nor the default in Contao or supported by Transifex.

Solutions

TBD

Tools

• https://github.com/lunetics/LocaleBundle is the recommended solution for Symfony CMF to load and store the locale information.
• https://github.com/sonata-project/SonataIntlBundle provides several twig/template helpers for locale, country labels, or date and time formatting

Aus dem aktuellen Barrierefreiheit-Test, den Heiko Kunert und ich mit der aktuellsten Contao 4-Version durchgeführt haben:

Sehbehinderte und blinde Nutzer würden erheblich davon profitieren, wenn in Contao die Icon-Beschriftungen spezifischer wären. Wenn man z.B. in der Seitenstruktur ist, lautet der Alternativtext für alle Bearbeiten-Icons identisch „Seite bearbeiten“. Besser wäre, wenn der Alternativtext jeweils noch den Namen der Seite enthält, also „Seite X bearbeiten“ oder „Seite Y bearbeiten“ (bitte Seitenname, nicht nur ID).

Das gilt für sämtliche Funktions-Icons (Bearbeiten, Einstellungen bearbeiten, Duplizieren, Verschieben, Löschen etc.)

Ebenso bei Artikeln, News, Events, Dateiverwaltung etc.
Wenn es nicht für alle Bereiche machbar sein sollte, wäre es gut, es zumindest bei möglichst vielen Bereichen zur Verbesserung der Usability einzufügen.

Hallo Leo,

ich würde mir eine Erweiterung des Moduls Nachrichtenliste wünschen, sodass man im FE eine Auswahlbox (Kategorien) hat, welche Nachrichten man sich anzeigen lassen möchte.

Begründung dafür ist einfach. Ich unterscheide im BE mit mehreren Archiven, möchte aber im FE nur eine Newsseite haben. Nun sollte der Besucher auch nur Teile anzeigen lassen können, z.B. eine spezielle Kategorie. Hierfür könnte man die Namen der BE News-Archive verwenden.

Ich hoffe ich habe mich ein wenig verständlich ausgedrückt.

Gruß
Stefan

Related issues: contao/core#2301

--- Originally created by AgentK on July 13th, 2010, at 09:38pm (ID 2295)

Hallo,

bin vor kurzem auf Contao umgestiegen, da Contao von Haus aus eine Kalender-Funktion mitbringt.

Bisher läuft alles Super. Ich benötige nur eine Ausgabe, die sich mit dem Kalender nicht erzeugen lässt.

Natürlich habe ich hier im Forum danach gesucht und bin auch fündig geworden. Alle Einträge kommen aus den letzten Jahr oder davor. Nur habe ich nirgends eine Lösung gefunden.

Es geht mir hier nicht um einen Belegungsplan sondern um eine Jahresansicht in der ich sehen kann an welchem Tag Termine sind. Es sollte ungefähr wie im Anhang dargestellt aussehen.

Da es eigentlich nur eine Ausgabe des Minikalenders für alle 12 Monate ist, dachte ich mir das es doch um einiges einfacher währe es direkt im Kalender von Contao zu integrieren. Nun bin ich leider Anfänger mit Contao, und frage mich ob es nicht ein guter Zusatz für ein Update wär oder ob jemand hier im Forum nicht vielleicht eine kleine Erweiterung dafür schreiben könnte.

Ich kann mir vorstellen das viele an so einer Funktion interessiert wären. Darum startet ich auch gleich hier eine Umfrage wer an einer Jahresansicht des Kalenders, wie im Anhang oder ähnlich, interesse hätte.

Gruß

Download the attachments

--- Originally created by huseldusel on March 24th, 2011, at 10:56am (ID 2955)

If you have defined one ore more custom sections, but you want to delete all of them, the last one cannot be deleted by clicking on the delete button (×). Instead, you have to remove the text within the "ID" input field in order to delete that custom sections, which seems a little counter intuitive.

This is a rough concept:

• SearchInterface
  • index(DocumentInterface $doc)
  • indexLazy(DocumentInterface $doc)
  • triggerLazyIndex()
  • search(QueryInterface $query)
  • etc.
• DocumentInterface
  • getUrl()
  • getContent()
  • getProtected()
  • etc.

Every Controller or Page type decides on its own whether to index something or not and does that by calling either $this->search->index() for immediate indexing or $this->search->indexLazy() for adding the content to the service and do a bulk insert when triggerLazyIndex() is called.
The AddToSearchIndexListener executes $this->search->triggerLazyIndex().

Advantages to the current implementation:

• We get rid of one more "legacy" class (Search).
• The Search service can easily replaced by Elasticsearch and Co. All they need to do is implement our SearchInterface.
• It's possible to add content by different content providers for the same url.
• In theory, rebuilding the index can be sub requests instead of real requests.

It would be nice if we can edit the predefined image-sizes via lightbox from a content element. So we dont have to switch for a quick change.

Maybe a small icon, after the select fields.

Gibt es eine Möglichkeit bei dem Modul Nachrichtenleser eine Art Navigation in der Form |< < 12345 > >| oder ähnlich zu integrieren, damit man die Nachrichten im Volltext "lesen und durchblättern" kann?

--- Originally created by anonymous on December 9th, 2008, at 03:38pm (ID 331)

Wenn man z.B. in einer Seite vom Typ „Interne Weiterleitung“ auf den „Auswahl ändern“-Button klickt, öffnet sich ein Modalfenster. Es gibt damit für Screenreader gleich mehrere Probleme:

1. Technisch gesehen ist das Modalfenster einfach ein Teil der schon geöffneten Seite und befindet sich im Quellcode ganz am Ende. Nach dem Klick auf den Button ist es für Screenreader-Nutzer nicht klar, dass sich irgendwo ein Modalfenster geöffnet hat und wie sie hinkommen. Es wäre gut, wenn Contao automatisch nach dem Klick auf den „Auswahl ändern“-Button den Fokus auf den Rahmen des Modalfensters legt.
   Ergänzend sollte das Modalfenster eine passende Seitenregion + ARIA-Label haben:
   <div class="simple-modal" id="simple-modal" role="region" aria-labelledby="simple-modal-title">...<h1 id="simple-modal-title">Weiterleitungsseite</h1>...</div>

2. Das Suchfeld im Modalfenster hat kein Label. Es wäre gut, wenn das Label (ggf. mit der Klasse "invisible") ergänzt wird.

3. Die Radioboxen haben keine Labels. Es wäre gut, wenn die Seitennamen die jeweils passenden Labels zugewiesen bekommen. Falls das zuviel Stress mit dem Backend macht, sollten die Radioboxen zumindest die entsprechenden aria-label="" Attribute (als Inhalt jeweils der Seitenname) erhalten, so dass sie klar zuordenbar sind.

4. Es ist für Screenreader-Nutzer sehr irritierend, dass die visuellen „Schließen“- und „Anwenden“-Buttons technisch gesehen einfache Links sind. Das ist semantisch unpassend und für Screenreader-Nutzer so nicht zu erwarten. Es wäre sehr gut, wenn das auch technisch echte <button> wären.

The newsletter system works as follows: a single contact list by newsletter.

Thus, the following contact [email protected] wishes to subscribe to the newsletter 1 and 2.

In the Backoffice, we have the list of newsletter with - every time - a list of subscribers separately. Same subscriber can be found twice in two different newsletter.

The problem is that it's not easy to manage when you have multiple subscribers. We must think about going in different newsletter to delete / deactivate. This greatly increases the risk of error / omission (assuming that we delete manually).

So my idea would be: create a single list of contacts for all newsletter. In the Backoffice, click on a contact, we all indicate that it is subscriber newsletter 1 or 2 ; 1 and 2 : etc. .... With, of course, possible to change subscription preferences.

If you need more info ...

Short description

If you change the timezone from e.g. Europe/Vienna (UTC+1) to Europe/London (UTC) and then edit an event, the event date will be one day (and one hour, which is correct) in the past of the original date.

Reproduction

• set the timezone to Europe/Vienna
• create a new event, set the start date to 2015-11-12 and the start time (and end time) to 08:00, save and close
• go to the system settings and set the timezone to Europe/London
• go to the calendar - the overview will display the event's date correctly as [2015-11-12 07:00]
• edit the event - now the start date will be 2015-11-11 for some reason (start time will be 07:00 which is correct)

This does not happen in the other direction, i.e., if you

• set the timezone to Europe/London
• create a new event with the start date 2015-11-12 and start/end time 08:00
• set the timezone to Europe/Vienna
• edit the event again

the start date will still be 2015-11-12 and the start/end time will be 09:00.

Aus dem aktuellen Barrierefreiheit-Test, den Heiko Kunert und ich mit der aktuellsten Contao 4-Version durchgeführt haben:

Screenreader-Nutzer haben erhebliche Probleme mit den Elementen, die für sehende Nutzer aussehen als wären es SELECT-Elemente, dies aber real gar nicht sind. Ein Beispiel hierfür ist beim Bearbeiten eines Inhaltselements das erste Feld "Typ". Es simuliert optisch ein SELECT-Element, aber tatsächlich ist es ein Link, gefolgt von einem leeren B (für sehende Nutzer der Pfeil nach unten/oben), gefolgt von einem ungelabelten Input-Feld und dann einer elendig langen Liste (in der die rein visuellen Gruppenüberschriften für Screenreader auch nicht von den anderen Listenpunkten unterscheidbar sind).

Dieses Konstrukt stellt für Screenreader-Nutzer ein extrem großes Problem dar. Ich habe vor kurzem beim Deutschen Blinden- und Sehbehindertenverband eine große Schulung speziell für stark sehbehinderte / blinde Redakteure/-innen gemacht. An diesem Punkt scheiterten sie alle. Selbst Heiko, der wirklich enorm erfahren und versiert im Umgang mit Software/Screenreadern ist, hatte massive Probleme damit. Ich musste ihm genau erklären, was da geschieht und nur deswegen war er dann unter meiner Anleitung in der Lage das überhaupt halbwegs zu nutzen. Alleine hätte er keine Chance gehabt (wie die anderen Redakteure in der Schulung).

Da mir schon mal signalisiert wurde, dass die Contao-Devs den Aufbau (bzw. die dahinter steckenden Features für sehende Nutzer) beibehalten wollen, möchten wir versuchen zumindest hier möglichst zeitnah ein paar Verbesserungen für sehbehinderte und blinde Nutzer reinzubekommen, damit Contao in diesem essentiellen Punkt für sie halbwegs sinnvoll bedienbar ist.

Hier ein paar konkrete Vorschläge in diesem Sinne:

Im Link sollten für Screenreader ergänzende Infos stehen.
Bisher:
<a href="javascript:void(0)" class="chzn-single chzn-single-with-drop" tabindex="-1"><span>Text</span><div><b></b></div></a>

Etwas besser:
<a href="javascript:void(0)" class="chzn-single chzn-single-with-drop" tabindex="-1"><span><span class="invisible">Gewählter Typ des Inhaltselements:</span> Text</span><div><b></b></div></a>

Dieser Link wurde mit tabindex="-1" aus der Tab-Reihenfolge entfernt. Das mag für blinde Nutzer vielleicht noch Sinn machen, da das Aus-/Einklappen der Liste sowieso rein visuell ist und keine Relevanz für blinde Nutzer hat. Allerdings setzen nicht nur blinde Nutzer Screenreader ein! Auch viele sehbehinderte Nutzer arbeiten ergänzend mit Screenreadern. Sie wollen also potentiell schon auch die aufgeklappte Liste sehen. Deshalb halte ich hier das tabindex="-1" eher für kontraproduktiv. Darüber könnte man aber ggf. diskutieren.

Das Suchfeld ist ungelabelt. Es sollte unbedingt ein sinnvolles Label haben, nach dem Schema:
<div class="chzn-search"><label for="suchfeld-x">Verfügbare Typenliste filtern/durchsuchen</label"><input id="suchfeld-x" type="text" autocomplete="off" tabindex="0" style="width: 100%;"></div>

Die Liste ist für blinde Nutzer wie gesagt ziemlich irritierend und nicht selbsterklärend. Es wäre sinnvoll, die UL zumindest mit einem ARIA-Label zu versehen, also beispielsweise so:
<ul class="chzn-results" aria-label="Verfügbare Listentypen - Gewünschten Typ anklicken zum Ändern des Elementtyps">

In der Liste sind bestimmte Einträge als unklickbare Überschriften gedacht, die die verfügbaren Typen inhaltlich unterteilen. Für Screenreader ist nicht erkennbar, was ein anklickbarer Typ ist und was nur der inhaltlichen Strukturierung der Liste dient.
Hier wäre es sinnvoll, diese Einträge tatsächlich als Überschriften (Hx) zu markieren. Das hätte den Vorteil, dass Screenreader-Nutzer diese ewig lange Liste auch über die Überschriften navigieren könnten.
<li id="ctrl_type_chzn_g_8" class="group-result" style="display: block;"><h4>Akkordeon<span lang="invisible">-Inhaltselemente</span></h4></li>

Das wären zumindest einige wichtige Verbesserungen, die im Rahmen des eingebauten HTML die Sache etwas zugänglicher machen. Die sehbehinderten und blinden Nutzer bräuchten dennoch am besten eine Schulung/Doku die ihnen erklärt, was hier geschieht, aber zumindest können sie danach damit arbeiten.

… because people should use the Doctrine connection

referring to contao/core-bundle#807

You implemented the new button "override Metadata", which is a great progress.
But: If we click on this "override Metadata", all the fields are empty at first.

For customers and editors, it would be great if the (already in the file-manager defined) Metadata would be inserted automatically, so that they can change/adjust it easily instead of having to insert everything from scratch.

Could it be made that when choosing a image (or: enabling "override Metadata"), the Metadata defined in the file-manager is fetched and inserted, so that the fields for the manual override are prefilled and can simply be changed?

Aus dem aktuellen Barrierefreiheit-Test, den Heiko Kunert und ich mit der aktuellsten Contao 4-Version durchgeführt haben:

Wenn man sich z.B. in einem Artikel alle eingefügten Inhaltselemente in der Übersicht ansieht, gibt es für Nutzer von Screenreadern mehrere Probleme:

1. Die Funktionsicons werden im HTML-Code vor der Bezeichnung des Elementtyps bzw. der Inhalte ausgegeben. Dadurch können die Nutzer von Screenreadern an der Stelle nur sehr umständlich erfassen, welchen Inhalt sie hier überhaupt bearbeiten/löschen etc. würden. Ich habe mit Heiko über verschiedene Möglichkeiten gesprochen, wie man hier eine möglichst verständliche Verbesserung hinbekommt. Am Ende einigten wir uns hierauf:
   Es würde helfen, wenn es jeweils an erster Stelle (vor den Funktionsicons eine Überschrift für Screenreader gäbe, die sowohl angibt, das wievielte Inhaltselement in der Übersicht es ist (Reihenfolge), welchen Typ es hat und ggf. noch welche ID). Der Code könnte dann z.B. so aussehen:

<li id="li_1">
<h2 class="invisible">1. Inhaltselement - Typ X - ID 46</h2>
<div class="tl_content even click2edit toggle_select hover-div">...

Das hätte auch noch den wichtigen Vorteil, dass Nutzer von Screenreadern bei sehr vielen Inhaltselementen gezielt über die Überschriftenstruktur einzelne Inhaltselemente anvisieren könnten.

2. Bei den Funktionsicons haben die Links Beschriftungen, die z.B. „Inhaltselement ID 46 bearbeiten“ lauten. Das ist für alle Nutzer (auch sehende) nur suboptimal, da der Standardnutzer an der Stelle gar nicht weiß, welches Element welche ID hat. Wenn für sehbehinderte/blinde Nutzer unter Punkt 1 in der Überschrift die ID mit ausgegeben wird, können zumindest sie etwas damit anfangen. Für sehende Nutzer könnte die ID sinnvollerweise noch bei der sichtbaren Typenbezeichnung ergänzend mit ausgegeben werden, damit das auch für sie einen Nutzen hat?

3. Die Drag-Drop-Funktion ist für blinde Nutzer irrelevant. Da wir aber die normale Verschieben-Funktion haben, empfinde ich das als unproblematisch, da die gewünschte Aktion damit erreicht werden kann. Heiko stimmte mir in dem Fall zu.
   Für sehbehinderte (und sehende) Nutzer wäre es hingegen hilfreich, wenn der jeweils gerade aktuelle Standort wo man per Drag-Drop hinschiebt, klarer erkennbar wäre. Momentan wird der neue Standort (solange man die Maus beim Verschieben nicht loslässt) nur durch ein leichtes Ausgrauen angezeigt. Hier wäre es für die Nutzer generell besser, wenn das eindeutiger ist. Aus meinen Schulungen weiß ich, dass auch sehende Nutzer häufiger falsch einschätzen, wo sie gerade wären und das CE deshalb erstmal falsch verschieben.

Zum Thema spezifischere Icon-Beschriftungen auch noch siehe Ticket #6361

Welches ist das make a Copy und welches ist das Add new Icon?

Die Icons der Content-Elemente Copy und Add new sind nicht unterscheidbar.

Für das Copy gäbe es gewohntere Icons: https://www.google.ch/search?q=copy+icon&client=safari&rls=en&dcr=0&source=lnms&tbm=isch&sa=X&ved=0ahUKEwjJsYK5sebXAhUIFuwKHcUyC9MQ_AUICigB&biw=1680&bih=930&dpr=2

Bis der Title Attribut eingeblendet wird und man schauen kann welches Icon zutrifft, vergeht eine Sekunde. Könnte man das nicht mit einem sofort erscheinenden Tooltip komfortabler gestalten?

We should standardise the use of all edit icons. Currently they are used in different case.

For example the use of the pencil icon in the site structure and articles:

Sometimes the pencil is for editing the element itself and sometimes for editing child elements. That's confusing.

We should add a icon for editing child elements or consistently use the header icon for editing elements itself.

I would like to see a new icon for editing child elements, despite I don't know how it should look like.

Ich möchte ein neues CE vorschlagen: eine Definitionsliste, also eine Erweiterung des ce_list um jeweils ein Feld (siehe auch: http://de.selfhtml.org/html/text/listen.htm#definition).
Damit wäre es Möglich, schnell ein paar Wertepaar anzugeben ohne extra eine Tabelle formatieren zu müssen.
Beispiele:
Max Mustermann | 1. Vorsitzender
Hans Mustermann | 2. Vorsitzender ...
oder
Ort | Simcity
Strasse | Neuestrasse ...

MfG, artemis

--- Originally created by artemis on July 15th, 2009, at 07:07pm (ID 886)

For better UX, I recommend to change the form fields from being mandatory fields to optional fields.
The default should be required.
http://uxmovement.com/forms/always-mark-optional-form-fields-not-required-ones/

Hello folks,

when having let's say a textarea defining a eval->maxlength-dca property of 400, validation goes wrong if the text contains encodable characters like "(" and ")" which in fact are encoded to ( and ). This encoding increases the string length the Widget::validator method uses to validate the max length.

I added an additional html_entity_decode() call to fix this:

    if ($this->minlength && $varInput != '' && utf8_strlen(strip_tags(html_entity_decode($varInput))) < $this->minlength)
    {
        $this->addError(sprintf($GLOBALS['TL_LANG']['ERR']['minlength'], $this->strLabel, $this->minlength));
    }

    if ($this->maxlength && $varInput != '' && utf8_strlen(strip_tags(html_entity_decode($varInput))) > $this->maxlength)
    {
        $this->addError(sprintf($GLOBALS['TL_LANG']['ERR']['maxlength'], $this->strLabel, $this->maxlength));
    }

In der Dateiverwaltung sollte die Möglichkeit geschaffen werden, dass Dateien nicht ungefragt überschrieben werden, wenn aus Versehen eine Datei gleichen Namens in einen Ordner hoch geladen wird.
Das kann nämlich zu peinlichen Situationen für die Betreiber/Redakteure einer Website führen :)
Am besten wäre es wahrscheinlich, beim Upload eine checkbox "Vorhandene Datei überschreiben" hinzuzufügen und diese Option defaultmäßig ungecheckt zu lassen.
Wenn eine Datei schon vorhanden ist und die Option nicht angehakt ist, sollte der Upload mit einer Fehlermeldung abbrechen.

Cummunity Thread:
https://community.contao.org/de/showthread.php?58258-Dateiverwaltung-2-gleiche-Dateinamen-im-selben-Ordner

Mit dem Formgenerator / Registration-Modul besteht die Möglichkeit einem Benutzer zu erlauben Dateien hochzuladen. Mit dem Content Element "Downloads" lässt sich für den jeweiligen Benutzer anzeigen (Benutzerverzeichniss verwenden).

In meinen Augen würde es Sinn ergeben, wenn man eigene hochgeladene Dateien auch wieder löschen könnte. Dies am besten als wählbare Option.

Grüsse

--- Originally created by anonymous on November 20th, 2008, at 12:52pm (ID 277)

@contao/developers I would like to add some kind of e-mail address confirmation routine to Contao.

If a member changes their e-mail address, the change shall only be applied after they have clicked a link in the confirmation e-mail. Thus I want to prevent that an invalid e-mail address is entered and there is no more way to contact the member.

What do you think about it?

For faster navigation between sibling items a quicknav as I made in this image. Upon moving to another page when not yet saved changes show confirmation screen. Adding this as option to dca, so developers decide if a quicknav makes sense or not for any table.

At this point, Contao only offers the functionality to sort either ascending or descending as defined in the DCA. It would be a nice feature if the user could reverse the sorting. Especially for tables sorted by date, clients are often asking whether it's possible to reverse the sorting sometimes.

Furthermore, I think it would be a nice feature and an improvement regarding the user experience if table columns (showColumns => true) would be clickable to change the sort by field. It's a feature, the people know from their operating system.

Hi, ich finde es total schade das man in den FAQ Modulen kaum Einstellungen hat die man bereits aus anderen Contao Modulen mit ähnlichen Funktionen kennt.
Meiner Meinung nach könnte man viele Einstellungsmöglichkeiten aus den Nachrichten Modulen übernehmen, z.B:

• Gesamtzahl der Beiträge
• Elemente pro Seite
• Meta-Felder
• Bild-Einstellungen

Ebenfalls wäre es toll eine Sortierungsmöglichkeit (z.B.: Alphabetisch, Datum (Auf- & Absteigend) zu haben. Mit Hilfe der Alphabetischen Sortierung könnte man dann z.B. ganz einfach ein Glossar umsetzen.

Klar lassen sich diese Features auch via Template Dateien und PHP lösen, ich denke allerdings, dass diese Features in die Core gehören und einen echten Mehrwert darstellen würden.

Es wäre sehr hilfreich, wenn man Benutzergruppen ein Default-Set an "Erlaubte Felder" zuweisen könnten indem man die Einstellungen exportieren und importieren könnte.

Mir geht es um die "Erlaubte Felder", die restlichen Einstellungen sind mir nicht so wichtig.

It would be interesting and useful for visitors to be able to explain how to fill a field in a form.

However, it is not possible to add a caption / help in the BE, for display in the FE.

I think we should add an extra field in the BE, type "help - give additional information on how your visitors must complete the field"

The idea is to come up with something like this: "please enter a valid address."

A +

If you have enabled the option limitWidth for the back-end theme, the #container will jump left and right in operating systems or browsers with fixed scrollbars, when you navigate between a page that requires vertical scrolling and one that does not.

This could be fixed by

body {
    overflow-y:scroll;
}

(also happens in Contao 3 and presumably Contao 4.3)

Ähnlich wie in Ticket #5393 können assistive Technologien wie Screenreader auch beim Link „Alle umschalten“ nicht erkennen, welcher Zustand (geöffnet/geschlossen) gerade aktiv ist. Die Nutzer müssten also zum nachfolgenden Tree View wechseln, dort nachschauen und dann ggf wieder zurücktabben. Möglich, aber ziemlich nervig.

Go to online demo CE 'File elements' preview.

It would be nice, if the BE preview of CEs download and downloads would show the file type icons. The classes are already there.

<div class="ce_downloads block">
  <h2>Download List Example</h2>
  <ul>
    <li class="download-element ext-jpg"> <a href="..." title="">DSC_5276.jpg <span class="size">(41,0 KiB)</span></a></li>
    <li class="download-element ext-jpg"> <a href="..." title="">DSC_5316.jpg <span class="size">(29,8 KiB)</span></a></li>
    <li class="download-element ext-jpg"> <a href="..." title="">DSC_5403.jpg <span class="size">(35,6 KiB)</span></a></li>
  </ul>
</div>

You can test it with devtools and this CSS. It's the CSS from icons.css
https://github.com/contao-components/contao/blob/master/css/icons.css
with modified path to the svg.

.download-element {
	padding:3px 6px 3px 22px;
	background:url("assets/contao/images/iconPLAIN.svg") left center no-repeat;
}
ul.enclosure {
	padding-left:0;
}
li.download-element {
	list-style-type:none;
}
/* Application files */
.ext-jpg {
	background-image:url("assets/contao/images/iconJPG.svg");
}
/* snip */

Wenn ich z. B. 3 Seiten habe, die ich in der Seitenstruktur an mehrere Stellen kopieren möchte, muss ich auf "mehrere bearbeiten" klicken, die Seiten auswählen, dann auf Kopieren klicken und die Seiten an der Zielstelle einfügen. Sobald das gemacht wurde, leert sich der "Zwischenspeicher" und ich muss den gesamten Vorgang nochmal wiederholen, wenn ich die gleichen 3 Seiten auch nochmal an eine andere Stelle kopieren will.

Ich habe hier gerade einen Fall wo ich 8 gleich benannte Seiten (mit identischen Voreinstellungen in Bezug auf Seitenlayout, Schutz, etc.) jeweils als Unterseiten von 20 Hauptseiten anlegen muss. Da der Speicher der "mehrere bearbeiten"-Funktion immer nur für einen Kopiervorgang reicht, muss ich nach jedem Vorgang den gesamten Ablauf wiederholen:

• auf "mehrere bearbeiten" klicken,
• die Seiten auswählen,
• dann auf den Button "Kopieren" klicken und
• die Seiten an der Zielstelle einfügen.

Sobald das gemacht wurde, leert sich der "Zwischenspeicher" und ich muss den gesamten Vorgang nochmal wiederholen, wenn ich die gleichen Seiten auch nochmal an eine andere Stelle kopieren will. Das ist sehr mühsam und frustrierend.

Ich würde mir daher einen Button nach dem Schema "Kopieren und für weiteres Kopieren in der Ablage behalten" wünschen. So könnte ich dann die Seiten an der Zielstelle einbinden und würde dann unmittelbar wieder mit den Einfügesymbolen begrüßt werden, so dass ich sie an der nächsten Stelle einbinden kann, usw. Wenn es mir reicht, könnte ich den Vorgang durch den bekannten Link "Ablage leeren" beenden.

Related issues: contao/core#2871

--- Originally created on November 24th, 2010, at 10:59am (ID 2692)

This is a follow up to contao/core#8012 regarding the discussion about the HTML markup for date ranges. The W3 consortium suggests to use some kind of microdata markup:

• hCalendar microformat vocabulary

  <time class="dtstart" datetime="2015-11-26">26/11/2015</time> –
  <time class="dtend" datetime="2015-11-30">30/11/2015</time>

• schema.org microdata vocabulary

  <time itemprop="startDate" datetime="2015-11-26">26/11/2015</time> –
  <time itemprop="endDate" datetime="2015-11-30">30/11/2015</time>

I have found some articles where they all suggest to use two separate <time> elements when it comes to mark up date ranges:

• http://www.brucelawson.co.uk/2012/best-of-time/
• http://www.sitepoint.com/html5-time-element-guide/#limitations

I guess this is the one problem users struggle with most when analyzing page speed. Page speed insights wants us to put blocking scripts out of the way and I guess it's right about that so we should do something about it. The problem is that almost all of our scripts are loaded in <head>. This is especially complicated for dynamically loaded scripts (when you include a gallery, an accordion etc.) so it's very hard to fix for non-devs and I think it should work better out-of-the-box.

I named this issue RFC as I request for comments here. Please do not just comment a "+1" if you think that needs to be done (you can do that by leaving feedback to the issue itself).
Please comment on concrete ideas how we could solve this.

My idea is to have a simple loader script we include in the <head> but inline (maybe also in <body> at the beginning? To be discussed). Here's a first example (obviously we would minify this):

<head>
    <!-- meta, css and stuff -->
    <script>
    function contaoLoadAsync(url, key) {
        var key = key || 'none';
        var script = document.createElement('script');
        var scripts = d.getElementsByTagName('script')[0];
        script.src = url;
        script.addEventListener('load', function (e) {
           var event = new CustomEvent('contao-script-loaded', { detail: {url: url, key: key} });
           document.dispatchEvent(event);
        }, false);
        scripts.parentNode.insertBefore(script, scripts);
    }
    </script>
</head>

For all the stuff added using $GLOBALS['TL_JAVASCRIPT'] we then output

<script>
contaoLoadAsync('url/to/script.js');
contaoLoadAsync('url/to/gallery.js', 'superduper-gallery-key');
</script>

Our initialize scripts that mostly listen to the domready jquery/mootools events can then be adjusted like so:

<script>
document.addEventListener('contao-script-loaded', function(e) {
    // You can check for your custom key here or check for "url" too
    if (e.detail.key !== 'superduper-gallery-key') {
        return;
    }

    // do initialization here
});

PS: My code is completely untested and just illustrates the general idea. Instead of new CustomEvent() we should use document.createEvent('CustomEvent'); for IE11 compatibility and make sure the async script is as small as possible when minified using more variables etc.

Die Abschnittsbeschriftungen im Backend (z.B. „Backend-Einstellungen“ bei den Personendaten) sind als anklickbare Legends eingestellt, damit man die darunter einsortierten Felder ein-/ausklappen kann. Sie können von Screenreadern derzeit aber nicht durch Tabben erreicht werden, da Legends nicht standardmäßig fokusierbare Elemente sind. Das könnte man beheben, indem sie das Attribut tabindex="0" erhalten. Ggf. müsste auch noch das dahinter liegende Script angepasst werden, um den Tastaturklick zu erkennen (habe ich jetzt nicht getestet).