Contao Open Source CMS

Affected version(s) 4.7.X und 4.8.X unter PHP 7.X

Description
Durch eine Vereins-Homepage-Aktion wurden mehrere Contao 4.8.3 - Webseiten bei verschiedenen Hostern (1und1, Strato und All-Inkl) erstellt und online gebracht. Nach einiger Zeit fiel uns und auch den Vereinen auf, dass die Webseiten (ALLE!) immer beim ersten Seitenaufruf nach einer gewissen Zeit sehr langsam laufen (bis zu 20 sec!!!) und danach ganz normal! Das ganze Spiel wiederholt sich dann nach 2-3h wieder und dann laufen die Seiten wieder mega schnell mit Latenzen von < 1 sec!!! Anfangs ungläubig konnte es dann durch Serverlogs und Monitoring nachvollzogen werden! Logs von index.php, HTTPKernel.php und EventDispatcher.php sind im Anhang zu finden!

Es scheint wirklich so zu sein, dass Contao (oder gar Symfony) hier ein massives Problem hat bis es quasi "warmgelaufen" ist! Das fällt bei wenig frequentierten Seiten besonders auf!!!

Link Community: https://community.contao.org/de/showthread.php?73770-Geschwindigkeitsproblem-bei-1-amp-1-Ionos/page2&p=511357

Noch eine Info dazu:

• Deaktivieren Command-Scheduler bringt keine Verbesserung
• Längste Antwortzeit bis zu 20 sec, wiederholt sich nach ca. 2-3h Inaktivität der Seite wieder, Schnitt schlechter Antwortzeiten bei ca. 12-16 sec
• Unabhängig vom Hoster oder Domain
• PHP-Interpreter schliesse ich aus (siehe Logs)

How to reproduce

Unveröffentlichte Contao4.8.X-Webseite erstellen und nach ca. 3-4h erneut aufrufen

Debug-Files Debug-Bad.zip Debug-Good.zip

Affected version(s) contao 4.6.x

Description
The {{post::}} insert tag will not be replaced.

How to reproduce
Make a new form, with a form field named "test", then use {{post::test}} to print the content. (checked at demo.contao.org) This should be the default behaviour. contao/core-bundle#1230

Maybe related to contao/core-bundle#1550

In an earlier version, you could specify the folders and files to be excluded in an input field, separated by commas. In the current version of the contao file system I integrated a CIFS share that can only be read. Therefore when I click "Don't sync", I get this error message: Internal Server Error: Failed to touch ".../.nosync".

I also have a CIFS share which is a distributed file system. For synchronizing on the Windows side it contains a none radable Folder by ls -la: d????????? ? ? ? ? ? MyPrivateName If I want to edit it in contao for not-synchronizing, I get this error message: Forbidden: What is the problem?, File or folder ".../MyPrivateName" is not mounted or cannot be found.

If I decide not to include a page in "the" XML sitemap used for search engines, it will not appear in the frontend module sitemap either. There should be a possibility to choose the visibility in both sitemaps separately, because XML sitemap and sitemap frontend module are different matters IMHO.

In a project we decided to set the Robots-Tag for the privacy statement page to "noindex, nofollow", but at the same time we chose to include the page in the sitemap, because we want to show it in the sitemap page which uses the sitemap frontend module. Now, Google sends me mails complaining about the page being included in the XML sitemap while being set to noindex in the Robots-Tag. Therefor, I need to exclude the page from XML sitemap but keeping it included in the frontend module.

Affected version(s) Contao v4.9.2

Stack used

• MySQL v8.0.20 (Linux on x86_64)
• PHP-FPM v7.4
• Apache Server v2
• Docker 20.10.8

Composer file

{
    "name": "contao/managed-edition",
    "type": "project",
    "description": "Contao Open Source CMS",
    "license": "LGPL-3.0-or-later",
    "authors": [
        {
            "name": "Leo Feyer",
            "homepage": "https://github.com/leofeyer"
        }
    ],
    "require": {
        "php": ">=7.2",
        "contao/calendar-bundle": "^4.9",
        "contao/comments-bundle": "^4.9",
        "contao/conflicts": "@dev",
        "contao/faq-bundle": "^4.9",
        "contao/listing-bundle": "^4.9",
        "contao/manager-bundle": "4.9.*",
        "contao/news-bundle": "^4.9",
        "contao/newsletter-bundle": "^4.9"
    },
    "conflict": {
        "contao-components/installer": "<1.3"
    },
    "extra": {
        "contao-component-dir": "assets",
        "symfony": {
            "require": "^4.4"
        }
    },
    "scripts": {
        "post-install-cmd": [
            "Contao\\ManagerBundle\\Composer\\ScriptHandler::initializeApplication"
        ],
        "post-update-cmd": [
            "Contao\\ManagerBundle\\Composer\\ScriptHandler::initializeApplication"
        ]
    }
}

Description

During the testing of a fresh Contao installation we got few MySQL errors and only the first three tables were created:

tl_crawl_queue
tl_cron_job
tl_remember_me
tl_trusted_device

Complete error log trace

[2020-05-04 00:00:00] request.CRITICAL: Uncaught PHP Exception Doctrine\DBAL\Exception\SyntaxErrorException: "An exception occurred while executing 'CREATE TABLE tl_article (id INT UNSIGNED AUTO_INCREMENT NOT NULL, pid INT UNSIGNED DEFAULT 0 NOT NULL, sorting INT UNSIGNED DEFAULT 0 NOT NULL, tstamp INT UNSIGNED DEFAULT 0 NOT NULL, title VARCHAR(255) DEFAULT '' NOT NULL, alias VARCHAR(255) DEFAULT '' NOT NULL COLLATEutf8mb4_bin, author INT UNSIGNED DEFAULT 0 NOT NULL, inColumn VARCHAR(32) DEFAULT 'main' NOT NULL, keywords TEXT DEFAULT NULL, showTeaser CHAR(1) DEFAULT '' NOT NULL, teaserCssID VARCHAR(255) DEFAULT '' NOT NULL, teaser TEXT DEFAULT NULL, printable VARCHAR(255) DEFAULT '' NOT NULL, customTpl VARCHAR(64) DEFAULT '' NOT NULL, protected CHAR(1) DEFAULT '' NOT NULL, groups BLOB DEFAULT NULL, guests CHAR(1) DEFAULT '' NOT NULL, cssID VARCHAR(255) DEFAULT '' NOT NULL, published CHAR(1) DEFAULT '' NOT NULL, start VARCHAR(10) DEFAULT '' NOT NULL, stop VARCHAR(10) DEFAULT '' NOT NULL, INDEX alias (alias), INDEX pid_start_stop_published_sorting (pid, start, stop, published, sorting), PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8mb4 COLLATEutf8mb4_unicode_ciENGINE = InnoDB ROW_FORMAT = DYNAMIC': SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'groups BLOB DEFAULT NULL, guests CHAR(1) DEFAULT '' NOT NULL, cssID VARCHAR(255)' at line 1" at /var/www/share/project/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/AbstractMySQLDriver.php line 79 {"exception":"[object] (Doctrine\\DBAL\\Exception\\SyntaxErrorException(code: 0): An exception occurred while executing 'CREATE TABLE tl_article (id INT UNSIGNED AUTO_INCREMENT NOT NULL, pid INT UNSIGNED DEFAULT 0 NOT NULL, sorting INT UNSIGNED DEFAULT 0 NOT NULL, tstamp INT UNSIGNED DEFAULT 0 NOT NULL, title VARCHAR(255) DEFAULT '' NOT NULL, alias VARCHAR(255) DEFAULT '' NOT NULL COLLATEutf8mb4_bin, author INT UNSIGNED DEFAULT 0 NOT NULL, inColumn VARCHAR(32) DEFAULT 'main' NOT NULL, keywords TEXT DEFAULT NULL, showTeaser CHAR(1) DEFAULT '' NOT NULL, teaserCssID VARCHAR(255) DEFAULT '' NOT NULL, teaser TEXT DEFAULT NULL, printable VARCHAR(255) DEFAULT '' NOT NULL, customTpl VARCHAR(64) DEFAULT '' NOT NULL, protected CHAR(1) DEFAULT '' NOT NULL, groups BLOB DEFAULT NULL, guests CHAR(1) DEFAULT '' NOT NULL, cssID VARCHAR(255) DEFAULT '' NOT NULL, published CHAR(1) DEFAULT '' NOT NULL, start VARCHAR(10) DEFAULT '' NOT NULL, stop VARCHAR(10) DEFAULT '' NOT NULL, INDEX alias (alias), INDEX pid_start_stop_published_sorting (pid, start, stop, published, sorting), PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8mb4 COLLATEutf8mb4_unicode_ciENGINE = InnoDB ROW_FORMAT = DYNAMIC':\n\nSQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'groups BLOB DEFAULT NULL, guests CHAR(1) DEFAULT '' NOT NULL, cssID VARCHAR(255)' at line 1 at /var/www/share/project/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/AbstractMySQLDriver.php:79, Doctrine\\DBAL\\Driver\\PDOException(code: 42000): SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'groups BLOB DEFAULT NULL, guests CHAR(1) DEFAULT '' NOT NULL, cssID VARCHAR(255)' at line 1 at /var/www/share/project/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php:83, PDOException(code: 42000): SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'groups BLOB DEFAULT NULL, guests CHAR(1) DEFAULT '' NOT NULL, cssID VARCHAR(255)' at line 1 at /var/www/share/project/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php:78)"} []

Environment variables used

• APP_ENV: prod
• SECRET: abcdef1230
• TRUSTED_PROXIES: 127.0.0.1,REMOTE_ADDR
• DATABASE_URL: mysql://username:passwd@database:3306/dbname

Steps to reproduce the issue

https://github.com/contao/contao/issues/1696#issuecomment-944373619

Screenshots

https://github.com/contao/contao/issues/1696#issuecomment-945426969

Beim Upgrade von C4.4.45 auf Contao 4.8.5 via CM bin ich an einem weissen Fenster im Installtool gestrandet. Wie sich nach längerem hin und her herausgestellt hat wird der Fehler durch zuwenig RAM verursacht. Nachdem All-inkl das auf 512 MB erhöht lief es durch. Leider gibt es da keinerlei Logeinträge weder am Server noch im var/log.

Spooky hatte mich gebeten das nochmals auf Github zur Diskussion zu stellen.

Mehr Details dazu sind hier zu fnden https://community.contao.org/de/showthread.php?76450-Weisses-Fenster-im-Installtool-nach-Upgrade-auf-C-4-8&p=514551#post514551

Randbedingungen: All-inkl Premium mit 256 MB RAM PHP 7.2 Contao 4.8.5 Isotope 2.6.3 Codefog Mobile-Menu 2.7 DB-Sicherung 1.3

Hello folks,

after much tinkering I finally gave up the approach we followed in #495 and followed another lead, that was easier to implement and actually even better interface-wise. Here is what this PR implements at the moment:

• Editors get a decent preview of the content they or somebody else deleted, rather than an ugly SQL query
• Editors may filter by user or type aka source table
• The list renders the deleted dataset as it was rendered in their respective backend modules list view. This means you get the full content element previewed
• It hooks into the existing DCA list label config (fields, format, label_callback)

As a side effect:

• Outputs the table name as CSS class on the tl_listing_container which was necessary to style everything as needed. I wished I had this plenty times already in other list views.

The implementation of the renderLabel method is copied from the Picker widget by @aschempp with minor adjustments. Thanks, Andy :)

I would have prefered the restore and show icons and the undo meta data (who, what, when) in a single line, but this is not possible with the two column table the DC_Table driver generates 🤷 So the interface is a compromise of what is possible with the given structure.

What's left to do?

• [x] Translate more table names (i. e. tl_content = Content element, tl_article = Article)
• [x] Implement a function to safely use table names as CSS classes.
• [x] Test this implementation against some more extensions
• [x] Add a proper icon for jump-to-parent functionality
• [] Update documentation ~- Refactor the renderLabel method and the Picker widget to use the same function?~

Happy to hear your comments :-)

Cheerio

Affected version(s)

Contao 4.9

Description When using the autologin function (Cookie REMEMBERME) in the frontend login module, the actual autologin never works on first, but only on second page load.

How to reproduce

1. Create a simple page
2. Create MemberGroup Testgroup
3. Create Member Testmember, allow login and assign Testgroup
4. Insert frontend user login module in pages article
5. Insert text element "Loggedin" and protect it for MemberGroup Testgroup
6. Browse to page with a clean browser session, login as Testmember and tick "remember me / autologin"
7. Text "Loggedin" will show.
8. Let session expire or manually delete PHPSESSION Cookie using your browsers development tools
9. Reload page.

Expected Result Text "Loggedin" will show, login form will be hidden and button Logout shows.

Actual Result Text Loggedin does not not show, but login form is hidden and button Logout shows. When refreshing the page now, the Text Loggedin will show.

In addition to this, if you also you make the page itself procteded for MemberGroup Testgroup this exception will be logged / shown in dev mode:

`ErrorException: Warning: implode(): Invalid arguments passed

at vendor/contao/core-bundle/src/Resources/contao/controllers/FrontendIndex.php:281 at Contao\FrontendIndex->renderPage(object(PageModel)) (vendor/symfony/http-kernel/HttpKernel.php:158) at Symfony\Component\HttpKernel\HttpKernel->handleRaw(object(Request), 1) (vendor/symfony/http-kernel/HttpKernel.php:80) at Symfony\Component\HttpKernel\HttpKernel->handle(object(Request), 1, true) (vendor/symfony/http-kernel/Kernel.php:201) at Symfony\Component\HttpKernel\Kernel->handle(object(Request)) (web/index.php:31) at require('.../web/index.php') (web/app.php:4) `

| Q | A | -----------------| --- | Fixed issues | Fixes https://github.com/contao/contao/pull/3103#issuecomment-865977632 | Docs PR or issue | https://github.com/contao/docs/pull/782

This introduces a new AbstractRecordedMigration that extends the existing AbstractMigration and automatically keeps a record on whether the migration was executed or not in a tl_migration table, if you use the createResult method. In your own shouldRun you can either use hasRun or call parent::shouldRun which also checks for hasRun.

The Migration entity itself is similar to the CronJob entity and will only hold the name of the migration (its FQCN by default) and a timestamp when it was executed.

Your own migration will then look like this at a minimum:

// src/Migration/ExampleMigration.php
namespace App\Migration;

use Contao\CoreBundle\Migration\AbstractRecordedMigration;
use Contao\CoreBundle\Migration\MigrationResult;

class ExampleMigration extends AbstractRecordedMigration
{
    public function run(): MigrationResult
    {
        return $this->createResult(true);
    }
}

Or, if you want to check for additional conditions (which will be the case for most):

// src/Migration/ExampleMigration.php
namespace App\Migration;

use Contao\CoreBundle\Migration\AbstractRecordedMigration;
use Contao\CoreBundle\Migration\MigrationResult;

class ExampleMigration extends AbstractRecordedMigration
{
    public function shouldRun(): bool
    {
        if ($this->hasRun()) {
            return false;
        }

        return /* custom condition */;
    }

    public function run(): MigrationResult
    {
        return $this->createResult(true);
    }
}

or

// src/Migration/ExampleMigration.php
namespace App\Migration;

use Contao\CoreBundle\Migration\AbstractRecordedMigration;
use Contao\CoreBundle\Migration\MigrationResult;

class ExampleMigration extends AbstractRecordedMigration
{
    public function shouldRun(): bool
    {
        // Custom condition

        return parent::shouldRun();
    }

    public function run(): MigrationResult
    {
        return $this->createResult(true);
    }
}

Add an option to configure the template inheritance from parent pages to child pages.

Possible options are:

• use layout on subpages (current behaviour, default & fallback behaviour)
• use layout on this page only
• use a custom layout for subpages

It is much easier to implement special overview pages or more complex layout structures via the page structure in this way:

• If a single overview page requires a special layout, define use layout on this page only – subpages then use the layout of the overview page’s parents (the current page is skipped when walking through the parents looking for a layout).
• If all subpages of a page should have the same layout which is not the layout of the parent page, set use a custom layout for subpages and select the layout for the subpages.

Overall, this decouples layout inheritance somewhat from the page tree (which is primarily used for menu structure). Another advantage is that the default inheritance of the layout to subpages is displayed directly to editors by the default option use layout on subpages.

Handling missing configuration: This new implementation still does not resolve a bad/missing configuration:

• If a parent page has includeLayout set but has no layout, the empty layout is inherited by the current page.
• If a parent page has layoutInheritance set to use a custom layout for subpages but has no subpagesLayout, the empty subpagesLayout is inherited by the current page.

Since the layout select widgets do not have a blank option, both cases should not happen when editing a page mindfully, but could happen after a submitOnChange without a manual save after.

One could argue that in case of a missing layout value, the layout should not be inherited from this parent.

Target Contao version: As a feature, this should probably be added to the latest Contao version. But since it is a progressive enhancement which defaults to the current behavious, it could be added to Contao 4.9 rather easily. The current pull request is based on Contao 4.9.

Issues on this topic:

• #1797
• https://github.com/contao/core/issues/1270 (very old)
• https://github.com/contao/core/issues/4868 (very old)

Affected version(s)

Contao 4.9 and Contao 4.11

Description

After installing Contao 4.11 at All-Inkl Webhosting Contao seems at first ok. The install tool creates the needed tables and does not show any database changes afterwards. But after installing an arbitrary bundle (e.g. I installed Rocksolid Custom Elements), the installtool insists on changing database columns which already have been created during Contao installation. After starting the database update those changes are still shown. Contao seems to work ok, though.

** Hosting Envoronment **

Hosting: All-Inkl Webhosting Premium PHP-Version: 8.0.6 MySQL: (Infos according to phpMyAdmin) Server-Typ: MariaDB Server-Version: 10.5.11-MariaDB-1:10.5.11+maria~focal-log - mariadb.org binary distribution Protokoll-Version: 10

The issue is only seen PHP 8.0.6 and All-Inkl Webhosting, switching to PHP 7.4 the issue disappears. Going back to PHP 8 it appears again. Others have reported that this also happens with Contao 4.9. Link to phpinfo output Link to forum thread

as mentioned in https://github.com/contao/contao/pull/5031#issuecomment-1369084846, here's the follow-up to implement a dark mode toggle 😎

It's functionality is derived from what I implemented at https://app.trakked.io. It works like this: By default, the back end is rendered by the browser/system preference. She user can then toggle to the opposite state through the profile menu. This selection is then remembered in the local storage. If a custom selection is switched back to the system default, the locale storage state is dropped and the back end behaves like the system again.

Storing the value in local storage imho makes a lot more sense than the user profile (or the session, which is stored in the user profile as well), simply because I would select a dark mode depending on my device, not my user account.

PS: I also refined the CSS for the drop down to include the small arrow border (that's the changes in #tmenu ul.menu_level_1:after) 😉

wenn $this->class gesetzt ist, wird !empty($this->img['class']) nicht weiter abgeprüft in

if ($this->class || !empty($this->img['class'])):

der Key "class" muss aber nicht vorhanden sein und bringt eine entsprechende Warning in

<?= trim($this->class.' '.$this->img['class']) ?>

Affected version(s)

4.13

Description

If members are automatically deactivated at a predefined time, the icon in front of the member's name is greyed out. However, the eye icon (activate/deactivate member) remains green. This is irritating from a usability point of view. This icon should also be greyed out. Furthermore, it is not possible to filter the member list by automatically deactivated members. With the filter option [Deactivate - yes/no], only manually deactivated members are displayed. Automatically deactivated members should also be shown here.

Follow-up on https://github.com/contao/contao/pull/5598#discussion_r1053627360

So? It's even better with single requests. Why would I download a file that contains the scripts for chosen, simplemodal, datepicker etc. combined? Chances that only one of them changes during a Contao update are pretty high. The way it is now it would generate a new combined file forcing me to download it all again. Yes, I agree it's still better to combine the stuff that belongs together in one file, even with http2/3. But these files are completely independent from each other. Chosen is not related to simplemodal whatsoever. Imho, we should not combine here.

@contao/developers Do we want to apply the same to the asset .css files?

This backports #5315 for Contao 4.13.

With this PR, it should be possible to use modern fragments and Twig templates in extensions and be compatible with Contao 4.13 and Contao 5.

Aside from the syntax changes to be compatible with PHP 7.4, the only difference to #5315 now basically is the default template name, that gets set in the RegisterFragmentsPass (see fe115410e3e2a4b19f8fe78e618b11fa228275ca).

I went through a lot of manual testing but please also test this PR, preferably in a real project. :relaxed: There a so many setup variants, so it's easy to miss one.