Duplicate entry for key 'url' INSERT INTO tl_search #8498

BugBuster1701 · 2016-09-21T12:13:00Z

Ähnlich dem #8460 .
Contao 3.5.17 hat zwei Seitenbäume, für Sprache de und en bei gleicher Domain.
Die Sprachkürzel in der URL sind nicht aktiviert!
Home Alias bei "de" ist "index", bei "en" ist "home".

Ruft man nun mittels de und en Browser die Home Seiten ohne Alias auf, wird zweimal versucht die Url http://domain.xy/ einzutragen.

leofeyer · 2016-09-21T14:49:18Z

Also dürfen wir nie die leere URL indizieren, wenn addLanguageToUrl deaktiviert ist, richtig?

leofeyer · 2016-09-21T14:49:28Z

@contao/developers /cc

fritzmg · 2016-09-21T14:53:54Z

Oder nur die Fallback Sprache indizieren in so einem Fall.

ausi · 2016-09-21T15:08:31Z

Also dürfen wir nie die leere URL indizieren, wenn addLanguageToUrl deaktiviert ist, richtig?

IMO ja, denn wenn dieselbe URL zwei verschiedene Seiten/Inhalte liefern kann, darf nichts unter dieser URL indiziert werden. Ist die Seite mit dem Alias index dann eigentlich noch über eine andere URL abrufbar?

leofeyer · 2016-09-21T15:15:26Z

Vielleicht ist das auch ein Fehler im Routing? Denn eigentlich muss der Browser unter der leeren Domain immer dieselbe Seite anzeigen, nämlich das Index-Dokument.

fritzmg · 2016-09-21T15:18:30Z

Contao zeigt bei einem leeren Request aber einfach die erste Seite des jeweiligen Seitebaums an. Contao ermittelt also in diesem Fall zuerst den richtigen Seitenbaum anhand der Browser-Sprache und zeigt da die erste (published) Seite an - egal ob die den Alias index hat oder nicht.

leofeyer · 2016-09-21T15:22:25Z

Was aber falsch sein könnte, wie wir jetzt durch den hier diskutierten Fehler bemerken. Auch Google zeigt ja nicht unter ein und derselben Domain verschiedene Seiten an, oder?

KaiserCh · 2016-09-21T15:34:08Z

Google nicht, da die zig lokalisierte Domains haben, aber das -Attribut "lang" wird soweit ich weiß durchaus hinsichtlich duplicated content & Co in Betracht gezogen.
Wenn die Startseiten beider Sprachen im Endeffekt den selben Content enthalten, nur eben lokalisiert, dürfte eine identische URL nicht vollkommen falsch sein, solange die deklarierte Sprache stimmt.

So gesehen wäre eine möglich Lösung für unser Problem hier, den Unique Key einfach um eine weitere Spalte für das Sprach-Kürzel zu ergänzen.

BugBuster1701 · 2016-09-21T16:34:11Z

Also dürfen wir nie die leere URL indizieren, wenn addLanguageToUrl deaktiviert ist, richtig?

Doch, es heißt ja nicht, dass es einen weiteren Seitenbaum gibt. Hat man nur einen, warum soll ich dann addLanguageToUrl aktivieren?

BugBuster1701 · 2016-09-21T16:39:10Z

Google mag ja nur eine Sprache aufnehmen, ist hier aber auch egal.
Eine Webseite mit zwei Sprachen (+Seitenbäumen) möchte auch sprachabhängig suchen können.

Bräuchte man hier nicht einfach nur die Sprache (language) mit aufnehmen?

fritzmg · 2016-09-21T16:39:23Z

Google nicht, da die zig lokalisierte Domains haben, aber das -Attribut "lang" wird soweit ich weiß durchaus hinsichtlich duplicated content & Co in Betracht gezogen.
Wenn die Startseiten beider Sprachen im Endeffekt den selben Content enthalten, nur eben lokalisiert, dürfte eine identische URL nicht vollkommen falsch sein, solange die deklarierte Sprache stimmt.

Trotzdem kann man dann aber nicht dediziert unter example.org/ einen bestimmten Content aufrufen. Dieser hängt vom Request ab (User-Agent).

KaiserCh · 2016-09-21T18:09:02Z

Ja, der User-Agent ändert den Content. Aber nichts anderes sagt der vary:User-Agent - Header, der z.B. auch von contao.org ausgesendet wird. Contao macht davon sogar regen Gebrauch, um dem body Klassen zuzuweisen.

Nach genauerer Konsultation der Google-Guidelines lag ich mit meiner ersten Einschätzung aber falsch. Google achtet nicht auf <html lang="...", sondern ermittelt die Sprache einer Seite anhand des Contents. SEO-technisch wäre es also falsch, unter "domain.tld/" mehrere verschiedene Sprachen auszuliefern, auch wenn der vary:User-Agent - Header sowas durchaus zu lässt.

Auch wenn n zusätzliches Feld im Unique-Key das ursprüngliche Problem beseitigen würde, wäre eine umfassendere Lösung besser. Wie wäre es, wenn bei obigem Szenario (Multi-Lang, kein Lang-Parameter in der URL) beim Aufruf der Domain in einer anderen als der Fallback-Sprache ein Redirect auf domain.tld/sprachstart-alias.html erfolgt? Müsste dann aber n 302 sein, damit Browser den Redirect nicht cachen & Suchmaschinen ihn nicht fest indizieren.

asaage · 2016-09-21T18:54:34Z

Ich hatte mir schon des öfteren gewünscht den Lang-Parameter bei jeder Sprache AUßER der Fallback-Sprache automatisch in die url hängen zu können - das wäre wohl auch eine Möglichkeit dieses Problem anzugehen.

leofeyer · 2016-09-28T12:08:20Z

SEO-technisch wäre es also falsch, unter "domain.tld/" mehrere verschiedene Sprachen auszuliefern, auch wenn der vary:User-Agent - Header sowas durchaus zu lässt.

So sehe ich das auch.

Wie wäre es, wenn bei obigem Szenario (Multi-Lang, kein Lang-Parameter in der URL) beim Aufruf der Domain in einer anderen als der Fallback-Sprache ein Redirect auf domain.tld/sprachstart-alias.html erfolgt?

Entweder so (leere Domain == Fallback-Sprache) oder anhand des Index-Dokuments (leere Domain == Seite mit Alias "index"). Letzteres wäre näher am normalen Verhalten eines Webservers.

KaiserCh · 2016-09-28T12:17:54Z

Das mit dem Alias "index" setzt aber voraus, dass jeder Webmaster bei der Startseite seiner Fallback-Sprache eben "index" setzt, bzw. überhaupt "index" irgendwo verwendet.
Auch wenn es sinnvoll und empfohlen ist, die Startseite index zu nennen, damit domain.tld/index.html = domain.tld/, ist es eben keine Pflicht.
Somit wäre so eine Änderung ein BC-Break.

Leere Domain = Fallback ist evtl. SEO-technisch und semantisch nicht DIE ultimative Lösung, aber sie gewährleistet Abwärtskompatibilität.
Oder natürlich "index, wenn index vorhanden, sonst Fallback".

fritzmg · 2016-09-30T10:40:34Z

On that note, there are currently 3 URLs for the startpage in Contao:

example.org/
example.org/alias-of-the-start-page.html
example.org/alias-of-the-root-page.html

The changelanguage extension creates URLs to the root page for example (see terminal42/contao-changelanguage#81) - but that URL simply displays the contents of the start page.

leofeyer · 2016-09-30T15:19:41Z

That is not correct. If you open the root page URL, you are being redirected.

fritzmg · 2016-09-30T15:51:57Z

True, I remembered that wrong.

KaiserCh · 2016-09-30T20:13:29Z

This still leaves us 2 options, domain.tld/ and domain.tld/alias.html (if alias != index). From a SEO point of view, this is total garbage if not compensated with a canonical-tag.
For the Contao search, I assume that it will handle "domain.tld/" and "domain.tld/alias-of-start.html" as 2 different pages, even though they are the same. But I'm not sure of this aspect. If my assumption is correct, this needs fixing, too.

leofeyer · 2016-10-06T13:34:02Z

As discussed in Mumble on October 6th, we should 302 redirect to the respective root page in this case. Only if there is a page with the alias index and the page language matches, the page can be delivered under the empty domain.

leofeyer · 2016-10-21T09:45:56Z

Fixed in f42f2a4.

The fix also fixes the "Do not redirect empty URLs" feature, which obviously nobody is using, because nobody ever complained that it was broken. 😄

asaage · 2016-10-21T09:58:10Z

"Do not redirect empty URLs"

i never got what it's used for 😄

Toflar · 2016-12-01T18:57:25Z

Für die Implementation in Contao 4 können wir Cookies natürlich nicht einfach ignorieren, aber Einführung für entsprechende Vary-Header hab ich mir auf die Fahne geschrieben. Das wird also verbessert werden. Das Problem ist, dass Cookie nicht als Vary geeignet ist, weil beliebige Info daran hängt. Die Liste ist also auch nich praktikabel (z.B. das PHP-Session Cookie wäre das selbe aber abhängig von der Session kann man tausende Dinge am Inhalt ändern). Für Contao 3.5 würde ich wohl tatsächlich den Eintrag ignorieren, wenn er bereits existiert.

leofeyer · 2016-12-15T15:58:09Z

@contao/developers Soll ich also wirklich das UPDATE in ein UPDATE IGNORE ändern? Die fehlenden Indexer-Kommentare in der Cookiebar-Erweiterung würde ich eher als ein Bug in der Erweiterung betrachten, der ja auch bereits gefixt wurde.

Würde ein UPDATE IGNORE nicht eher andere Bugs verschleiern, weil eben keine Exception mehr kommt?

Toflar · 2016-12-15T16:20:07Z

Das stimmt so nicht ganz. Der Inhalt könnte beliebig verändert werden aufgrund eines Cookies. Es ist aber richtig, dass dieser Inhalt dann meistens auch nicht indexiert werden muss. Z.B. ein Warenkorb etc. pp. Aber der Suchindex sollte sich daran auch nicht stören, weil es absolut valid ist, auf derselben URL verschiedenen Inhalt zu haben. Genau dafür ist ja eben der Vary header da :-)
Insofern ist das ganz klar ein Fehlverhalten von Contao im Moment.

discordier · 2016-12-15T16:26:56Z

@Toflar Ich sehe da durchaus ein Problem wenn in diesem Falle dann dummerweise der Cookie-based Content im Index landet und der "richtige" nicht mehr reinkommt und ich nichtmal einen Fehler bekomme.

Dass es sich hierbei um ein Fehlverhalten handelt ist, denke ich, unbestritten. Dennoch sollten wir nicht ein Fehlverhalten durch ein anderes tauschen.

Toflar · 2016-12-15T16:28:50Z

Da bin ich ja bei dir, ich hab keine Aussage getroffen, ausser dass es jetzt falsch ist.

discordier · 2016-12-15T16:30:19Z

Dann habe ich dich falsch verstanden, ich dachte dass du pro UPDATE IGNORE seist.

Ich bin aus o.g. Grund dagegen.

Toflar · 2016-12-15T16:30:28Z

Imho sollten wir in der 3.5 das Indizieren ignorieren wenn credentialed requests reinkommen. Also sprich Authorization oder Cookie in den HTTP headers vorkommen. WDYT?

Toflar · 2016-12-15T16:31:15Z

Ah, dann hätten wir keine personalisierten Suchergebnisse mehr.

discordier · 2016-12-15T16:32:14Z

Exakt, we are doomed. 😺
Das ist btw. auch eins der Probleme die ich in meinem crawler in C4 habe, ich kann nicht personalisieren.

Toflar · 2016-12-15T16:33:15Z

Es geht halt einfach nicht. Es ist wieder eins dieser Probleme die sich einfach nicht lösen lassen in 3.5. In der 4 können wir anständige Vary header setzen und dann passt das, dann geht es auch für deinen Crawler.

leofeyer · 2016-12-15T16:38:59Z

Aber Google berücksichtigt den Vary-Header auch nicht beim Indizieren. Das hat @KaiserCh oben schon erläutert.

discordier · 2016-12-15T16:41:00Z

Die praesentieren aber auch nicht jedem Besucher einen anderen Inhalt sondern jedem denselben?

Toflar · 2016-12-15T16:48:11Z

Das ist ja auch irrelevant. Es geht darum was unsere Suche macht und im Moment geht sie davon aus, dass unter der selben URL immer derselbe Content existiert was ein Fehler ist, denn dem ist einfach nicht so. Die URL ist nie unique. Sie ist unique zusammen mit allen Vary Headern und mit denen kann weder unser Contao 3.5 HTTP-Cache noch unsere Suche umgehen.
Uns fehlt nebst der Unterstützung für die Vary Header auch das senden dieser Header, nämlich für

Page Layout (Desktop / Mobile)
Mitgliedergruppe bzw. Mitglied-ID (für personalisierten Inhalt)
etc.

Und die hängen am Cookie, man muss sie also erst noch mit Vorab-Requests aufsplitten. Das ist ein riesiger Aufwand.
Es ist deshalb m.M.n. zum jetzigen Zeitpunkt unmöglich dieses Problem zu fixen. Die Suche muss davon ausgehen, dass auf der selben URL verschiedener Inhalt ist.

KaiserCh · 2016-12-15T18:09:29Z

Zumindest für alle Content-Änderungen, die nicht vom Session-Cookie, sondern x-beliebigen weiteren abhängen (wie z.B. bei der Cookiebar-Extension) gäbe es eine schnelle und nicht all zu hässliche Lösung:

$_COOKIE auf ne temporäre Variable kopieren & den Array-Key PHPSESSID entfernen (falls vorhanden)
Wenn die Länge des temp-arrays jetzt > 0, dann gibts noch mehr Cookies außer der Session und der Search Indexer sollte zur Sicherheit übersprungen werden.

Hilft natürlich nix für Dinge aus der Session, z.B. wenn eine Extension eine sortier- oder filterbare Liste darstellt, die Filter-Einstellungen in der Session lagert und die Liste nicht vom Indexer ausschließt. Aber irgend was ist ja immer...

fritzmg · 2017-02-15T13:34:45Z

Is there any plan to accommodate this in a bugfix version in Contao 3? While we identified the problem with extensions likes visitors and cookiebar there are still sporadic reports on the community forum about this - while having the most recent version of the aforementioned extensions.

A Google search still reveals a lot of websites that suffer from this problem - though most of them haven't been updated to the most recent Contao LTS version, otherwise the error would not be visible in the front end.

Toflar · 2017-02-15T13:55:35Z

Imho this needs to be reopened, yes. The only question is whether we should go for ON DUPLICATE KEY UPDATE or ignore :)

leofeyer · 2017-02-15T14:02:47Z

Correct. I have already asked this question on December 15th, 2016, but never got an answer.

Toflar · 2017-02-15T14:03:28Z

Both ways are possibly incorrect, so what. Just pick one :D I think I'd just ignore it.

KaiserCh · 2017-02-16T23:06:59Z

@Toflar What do you mean regarding ON DUPLICATED KEY UPDATE? The problem here exists because of an UPDATE statement. UPDATE does not have a syntax like UPDATE ON DUPLICATE KEY UPDATE. The only option regarding duplicates is IGNORE. Only INSERT statements support an optional UPDATE.

What would happen if we set it to ON DUPLICATE KEY IGNORE and change regular content of the page, e.g. add/modify a content element? Wouldn't in this case the index still contain the old content until someone issues a full reindex from backend? If this is the case, IGNORE is no option at all.
But the main problem still persists. I think I've seen one of those Update-Duplicate-Errors this week on one of our projects, and it should be a current Contao installation, at least as current as the mail-related security update.

I think it's wrong to simply say "Check your extensions". While old extensions might be the reason this problem exists, these extensions were not resulting in this kind of error for older v3.5-releases. Since the core-updates on LTS-release should not result in backward compatibility issues, it is wrong to expect every extension to adapt to the modified search behaviour with checksum_pid. If an extension was working with 3.5.0, it should work with 3.5.999.

Oh, and a Google-search for "contao Query error: Duplicate entry" reveals pure horror...

Toflar · 2017-02-17T08:43:04Z

Yeah obviously I mean the update statement.

What would happen if we set it to ON DUPLICATE KEY IGNORE and change regular content of the page, e.g. add/modify a content element? Wouldn't in this case the index still contain the old content until someone issues a full reindex from backend? If this is the case, IGNORE is no option at all.

Yeah, as I said. It's a problem we cannot fix. If your content element provides different output for the same URL based on something like the session, the content changes. You cannot determine which change was correct. We can always update the entry instead of ignoring it but anyway it leads to inconsistent search results no matter what way we choose.
It cannot be fixed properly without huge changes that are not feasible for Contao 3.5 and require major efforts in Contao 4.

ausi · 2017-02-17T08:51:40Z

I don’t think this is a problem only with extensions. I can reproduce it reliably in my installation:

Clear the search index
Open the home page with a query example.com/?foo=bar
Navigate to the real home page URL example.com/

This leads to Duplicate entry '...' for key 'checksum_pid' (INSERT INTO tl_search....

The error with UPDATE (not INSERT) is a bit harder to reproduce, but also possible:

Output randomly a 0 or a 1 somewhere on the home page, e.g. <?= mt_rand(0, 1) ?>
Clear the search index
Open the browser and navigate between example.com/ and example.com/?foo=bar until you get the error message.

This leads to Duplicate entry '...' for key 'checksum_pid' (UPDATE tl_search....

I think both cases can be fixed by adding a DELETE statement to Search.php:189:

$objDatabase->prepare("DELETE FROM tl_search WHERE id=?")
			->execute($objIndex->id);

The comment on this line says “the new URL is more canonical” which IMO means that the old entry should get deleted, so the DELETE seems to be the right thing to do here.

Toflar · 2017-02-17T08:54:48Z

Yeah that should improve it already. Still you might have different output on the same URL. The very correct way would be to include Vary headers in the search index entry but as you know we cannot expect all developers to add them correctly. Yet. :-)
Anyway, are you creating a PR for the DELETE query?

ausi · 2017-02-17T08:55:58Z

Anyway, are you creating a PR for the DELETE query?

Yes.

ausi · 2017-02-17T09:02:08Z

Done: #8647

KaiserCh · 2017-02-17T09:13:16Z

@Toflar Even if the Indexer might index wrong/personalized content, removing the fatal error is still a huge improvement. The worst that might happen is: the search result won't match the page it points to, but only until a user clicks on the result.

Toflar · 2017-02-17T09:14:04Z

Sure, the PR fixes the issue. Go test and comment, please :-)

leofeyer · 2017-02-17T10:53:34Z

Thank you guys!

fritzmg · 2018-02-06T13:06:45Z

Unfortunately this has resurfaced again in a Contao 4.4.12 installation. This website was launched with Contao 4.4 in general.

Doctrine\DBAL\Exception\UniqueConstraintViolationException:
An exception occurred while executing 'INSERT INTO tl_search (tstamp, url, title, protected, filesize, groups, pid, language, text, checksum) VALUES (1517922060, 'https://example.org/lorem/ipsum.html', 'Page Title', '', '93.06', 0, '300', 'de-AT', …, '3244dac04c1a5521b4c037de894a8ba2')':

SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'https://example.org/lorem/ipsum.html' for key 'url'

  at vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/AbstractMySQLDriver.php:70
  at Doctrine\DBAL\Driver\AbstractMySQLDriver->convertException('An exception occurred while executing \'INSERT INTO tl_search (tstamp, url, title, protected, filesize, groups, pid, language, text, checksum) VALUES (1517922060, \'https://example.org/lorem/ipsum.html\', …, \'3244dac04c1a5521b4c037de894a8ba2\')\':SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry \'https://example.org/lorem/ipsum.html\' for key \'url\'', object(PDOException))
     (vendor/doctrine/dbal/lib/Doctrine/DBAL/DBALException.php:176)
  at Doctrine\DBAL\DBALException::wrapException(object(Driver), object(PDOException), 'An exception occurred while executing \'INSERT INTO tl_search (tstamp, url, title, protected, filesize, groups, pid, language, text, checksum) VALUES (1517922060, \'https://example.org/lorem/ipsum.html\', …, \'3244dac04c1a5521b4c037de894a8ba2\')\':SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry \'https://example.org/lorem/ipsum.html\' for key \'url\'')
     (vendor/doctrine/dbal/lib/Doctrine/DBAL/DBALException.php:150)
  at Doctrine\DBAL\DBALException::driverExceptionDuringQuery(object(Driver), object(PDOException), 'INSERT INTO tl_search (tstamp, url, title, protected, filesize, groups, pid, language, text, checksum) VALUES (1517922060, \'https://example.org/lorem/ipsum.html\', …, \'3244dac04c1a5521b4c037de894a8ba2\')', array())
     (vendor/doctrine/dbal/lib/Doctrine/DBAL/Connection.php:915)
  at Doctrine\DBAL\Connection->executeQuery('INSERT INTO tl_search (tstamp, url, title, protected, filesize, groups, pid, language, text, checksum) VALUES (1517922060, \'https://example.org/lorem/ipsum.html\', …, \'3244dac04c1a5521b4c037de894a8ba2\')')
     (vendor/contao/core-bundle/src/Resources/contao/library/Contao/Database/Statement.php:284)
  at Contao\Database\Statement->query()
     (vendor/contao/core-bundle/src/Resources/contao/library/Contao/Database/Statement.php:257)
  at Contao\Database\Statement->execute()
     (vendor/contao/core-bundle/src/Resources/contao/library/Contao/Search.php:227)
  at Contao\Search::indexPage(array('url' => 'https://example.org/lorem/ipsum.html', 'title' => 'Page Title', 'protected' => '', 'groups' => false, 'pid' => '300', 'language' => 'de-AT', 'description' => '', 'keywords' => '…'))
     (vendor/contao/core-bundle/src/Resources/contao/classes/Frontend.php:669)
  at Contao\Frontend::indexPageIfApplicable(object(Response))
     (vendor/contao/core-bundle/src/Framework/Adapter.php:47)
  at Contao\CoreBundle\Framework\Adapter->__call('indexPageIfApplicable', array(object(Response)))
     (vendor/contao/core-bundle/src/EventListener/AddToSearchIndexListener.php:74)
  at Contao\CoreBundle\EventListener\AddToSearchIndexListener->onKernelTerminate(object(PostResponseEvent), 'kernel.terminate', object(TraceableEventDispatcher))
  at call_user_func(array(object(AddToSearchIndexListener), 'onKernelTerminate'), object(PostResponseEvent), 'kernel.terminate', object(TraceableEventDispatcher))
     (vendor/symfony/symfony/src/Symfony/Component/EventDispatcher/Debug/WrappedListener.php:104)
  at Symfony\Component\EventDispatcher\Debug\WrappedListener->__invoke(object(PostResponseEvent), 'kernel.terminate', object(ContainerAwareEventDispatcher))
     (vendor/symfony/symfony/src/Symfony/Component/EventDispatcher/EventDispatcher.php:212)
  at Symfony\Component\EventDispatcher\EventDispatcher->doDispatch(array(object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener)), 'kernel.terminate', object(PostResponseEvent))
     (vendor/symfony/symfony/src/Symfony/Component/EventDispatcher/EventDispatcher.php:44)
  at Symfony\Component\EventDispatcher\EventDispatcher->dispatch('kernel.terminate', object(PostResponseEvent))
     (vendor/symfony/symfony/src/Symfony/Component/EventDispatcher/Debug/TraceableEventDispatcher.php:139)
  at Symfony\Component\EventDispatcher\Debug\TraceableEventDispatcher->dispatch('kernel.terminate', object(PostResponseEvent))
     (vendor/symfony/symfony/src/Symfony/Component/HttpKernel/HttpKernel.php:88)
  at Symfony\Component\HttpKernel\HttpKernel->terminate(object(Request), object(Response))
     (vendor/symfony/symfony/src/Symfony/Component/HttpKernel/Kernel.php:167)
  at Symfony\Component\HttpKernel\Kernel->terminate(object(Request), object(Response))
     (web/app_dev.php:66)

I'll try to analyze the cause.

leofeyer added the defect label Sep 21, 2016

leofeyer added this to the 3.5.18 milestone Sep 21, 2016

leofeyer added the up for discussion label Sep 21, 2016

leofeyer removed the up for discussion label Oct 6, 2016

leofeyer self-assigned this Oct 21, 2016

leofeyer added a commit that referenced this issue Oct 21, 2016

Redirect the empty URL depending on language and alias name (see #8498).

f42f2a4

leofeyer closed this as completed Oct 21, 2016

leofeyer added a commit that referenced this issue Oct 26, 2016

Redirect the empty URL depending on language and alias name (see #8498).

32e70a8

ausi mentioned this issue Feb 17, 2017

Delete old search entry if new URL is more canonical #8647

Merged

asaage mentioned this issue Sep 2, 2017

language in URL but not in "main" page tree contao/core-bundle#1051

Closed

Duplicate entry for key 'url' INSERT INTO tl_search #8498

Duplicate entry for key 'url' INSERT INTO tl_search #8498

Comments

BugBuster1701 commented Sep 21, 2016

leofeyer commented Sep 21, 2016

leofeyer commented Sep 21, 2016

fritzmg commented Sep 21, 2016

ausi commented Sep 21, 2016

leofeyer commented Sep 21, 2016

fritzmg commented Sep 21, 2016

leofeyer commented Sep 21, 2016

KaiserCh commented Sep 21, 2016

BugBuster1701 commented Sep 21, 2016

BugBuster1701 commented Sep 21, 2016

fritzmg commented Sep 21, 2016

KaiserCh commented Sep 21, 2016 • edited Loading

asaage commented Sep 21, 2016

leofeyer commented Sep 28, 2016

KaiserCh commented Sep 28, 2016

fritzmg commented Sep 30, 2016 • edited Loading

leofeyer commented Sep 30, 2016

fritzmg commented Sep 30, 2016

KaiserCh commented Sep 30, 2016

leofeyer commented Oct 6, 2016

leofeyer commented Oct 21, 2016

asaage commented Oct 21, 2016

Toflar commented Dec 1, 2016

leofeyer commented Dec 15, 2016

Toflar commented Dec 15, 2016

discordier commented Dec 15, 2016

Toflar commented Dec 15, 2016

discordier commented Dec 15, 2016

Toflar commented Dec 15, 2016

Toflar commented Dec 15, 2016

discordier commented Dec 15, 2016

Toflar commented Dec 15, 2016

leofeyer commented Dec 15, 2016

discordier commented Dec 15, 2016

Toflar commented Dec 15, 2016

KaiserCh commented Dec 15, 2016

fritzmg commented Feb 15, 2017

Toflar commented Feb 15, 2017

leofeyer commented Feb 15, 2017

Toflar commented Feb 15, 2017

KaiserCh commented Feb 16, 2017

Toflar commented Feb 17, 2017

ausi commented Feb 17, 2017

Toflar commented Feb 17, 2017

ausi commented Feb 17, 2017

ausi commented Feb 17, 2017

KaiserCh commented Feb 17, 2017

Toflar commented Feb 17, 2017

leofeyer commented Feb 17, 2017

fritzmg commented Feb 6, 2018 • edited Loading

KaiserCh commented Sep 21, 2016 •

edited

Loading

fritzmg commented Sep 30, 2016 •

edited

Loading

fritzmg commented Feb 6, 2018 •

edited

Loading