[RTM] Always fix the domain and language when generating URLs by leofeyer · Pull Request #8238 · contao/core

leofeyer · 2016-02-26T15:41:38Z

This PR fixed #8204 and all duplicate tickets for good (hopefully).

aschempp · 2016-02-26T15:45:26Z

Why do we need still the $strForceLang?

aschempp · 2016-02-26T16:20:10Z

Also, can we add support for $arrRow being a PageModel?

leofeyer · 2016-02-26T16:21:03Z

Thought about it, too. Maybe not in the bugfix release.

aschempp · 2016-02-26T16:21:38Z

What's the difference? If we always force domain, we always force the language…

leofeyer · 2016-02-26T18:31:47Z

Why do we need still the $strForceLang?

We do not need it, we just keep supporting it for BC. Not sure what people have used it for …

Toflar · 2016-02-26T18:50:02Z

Not sure what people have used it for …

To force the language, like the parameter says? If you don't have any front end context, how would you generate it correctly? :-)

BTW: I think I have a better approach for your code performance wise which will be fully backwards compatible:

Check if tl_page.language has changed in save_callback and if so, update all child records with it.
Modify the PageModel and introduce a getLanguage() method:

public function getLanguage()
{
    // Ensure root page language is inherited if not set by save_callback (BC)
    if ('' === $this->language) {
        $this->loadDetails();
    }

    return $this->language;
}

Support passing the \PageModel to \Controller::generateFrontendUrl() then instead of using $arrRow['language'] use \PageModel::getLanguage().

Why in 3.5: Well, we have to change the handling because it's buggy at the moment but if we already change it then we should make it right :-)

leofeyer · 2016-02-26T19:29:35Z

To force the language, like the parameter says? If you don't have any front end context, how would you generate it correctly? :-)

No front end context is required. It will set the language and domain based on $page->rootLanguage and $page->domain, which are both set in PageModel::loadDetails().

I think I have a better approach for your code performance wise which will be fully backwards compatible

How is your code performing better? We'd still have to bubble up to the root page to check the domain, wouldn't we?

leofeyer · 2016-02-26T19:32:05Z

Not to forget $page->trail, which also required to load the page details.

…ndUrl().

leofeyer · 2016-02-28T20:00:45Z

The PR is ready to merge now. Please review one last time.

aschempp · 2016-02-29T07:35:49Z

system/modules/core/classes/Backend.php

-		$objDatabase = \Database::getInstance();
-
-		// Get published pages
-		$objPages = $objDatabase->prepare("SELECT * FROM tl_page WHERE pid=? AND (start='' OR start<='$time') AND (stop='' OR stop>'" . ($time + 60) . "') AND published='1' ORDER BY sorting")


If I remember correctly, we intentionally do not use models here because of performance and memory …

I don't remember anything alike. Has there been a ticket?

I remember something like this as well. Cannot find it though but it sure is an issue with a lot of pages. Please do not change this!

I have to change it to fix the initial problem.

This will fail miserably, I tell you. This is a no go, I'm sorry.

You are telling me this based on something you think you remember, which however is nowhere documented?

#7928 (comment)

leofeyer · 2016-02-29T10:11:45Z

I have investigated a bit. Here are some findings of where not to use models:

Rebuilding the search index is not one of them. Also, I have debugged rebuilding the search index with and without models:

With models

Without models

Using models requires 10% more memory, however, it also decreases the number of database queries and the number of rows which need to be transferred.

@Toflar What exactly are your concerns?

Toflar · 2016-02-29T10:13:51Z

Try this on an installation with 3000 pages that are split over 12 domains times 4 languages (= 48 root pages). I think it's going to fail 😄

leofeyer · 2016-02-29T10:20:50Z

I found the ticket about what you think to remember: #7928

We have also discussed that we need to use the database class again, but then we found a bug in the Model class, which turned out to cause the problems.

After fixing the bug, the memory issues were gone. So we can safely merge this PR now.

aschempp · 2016-02-29T10:25:11Z

After fixing the bug, the memory issues were gone.

That's just not true. The last comment was "please test", so we don't know if anything changes. The major difference (in my opinion) is that the models will be kept in the registry indefinitely, whereas the database result will be removed from memory when not used anymore.

leofeyer · 2016-02-29T10:27:47Z

Of course they were gone. We have tested the change extensively, we have just not commented in the ticket. But it was only closed two weeks after finding the bug.

Toflar · 2016-02-29T10:47:00Z

I tried to do some tests to back my use case and ended up with a regular page model requiring more or less 20kb of RAM. So for 3000 pages it would require about 60 MB RAM which is fine then I think :-) If they are split over 48 root pages it will certainly need quite a lot more memory but it should still be fine. So I guess my concerns are refuted :-)

However, I still think, inheriting dns, language and whatever other columns are needed to generate a front end url, is the way to go. You can safely generate a front end url from one single database row without having to load the model and its root page and bubble up all the pages to load the details then. It would greatly improve performance, memory consumption and developer experience :-)

aschempp · 2016-02-29T10:56:45Z

However, I still think, inheriting dns, language and whatever other columns are needed to generate a front end url, is the way to go. You can safely generate a front end url from one single database row without having to load the model and its root page and bubble up all the pages to load the details then. It would greatly improve performance, memory consumption and developer experience :-)

That's certainly something we should think about, but certainly not in the 3.5.7 patch release ^^

leofeyer · 2016-02-29T11:00:51Z

However, I still think, inheriting dns, language and whatever other columns are needed to generate a front end url, is the way to go.

Yes, I'm totally with you on this one. However, that is a different issue.

The problem is that storing the fields in the database is pretty cumbersome and also error-prone, because you have to keep it in sync when the root page changes. There are some solutions for this problem already and backbone87 has implemented one in #6193 (his initial issue was #6830).

leofeyer · 2016-02-29T11:04:20Z

So now that we have settled this and that I have changed all you have suggested, can I merge the PR?

Toflar · 2016-02-29T12:25:26Z

Imho, yes.

leofeyer · 2016-02-29T12:41:45Z

Ah, no, I cannot. I have not solved this issue brought up by @aschempp :(

leofeyer · 2016-02-29T15:26:40Z

You could have added a flag to $arrOptions to disable the fePreview check?

I have thought about exactly this, too 😄

I have not asked you though, because I also think it is a new feature. But we should definitely implement this!

leofeyer · 2016-02-29T15:30:04Z

I have created a separate ticket: contao/core-bundle#452

leofeyer · 2016-02-29T16:17:34Z

Merged in c68d813.

### 4.1.1 (2015-03-03) * Remove the "disable IP check" field from the back end settings (see #436). * Do not quote the search string in `FIND_IN_SET()` (see #424). * Always fix the domain and language when generating URLs (see contao/core#8238). * Fix two issues with the flexible back end theme (see contao/core#8227). * Correctly toggle custom page type icons (see contao/core#8236). * Correctly render the links in the monthly/yearly event list menu (see contao/core#8140). * Skip the registration related fields if a user is duplicated (see contao/core#8185). * Correctly show the form field type help text (see contao/core#8200). * Correctly create the initial version of a record (see contao/core#8141). * Correctly show the "expand preview" buttons (see contao/core#8146). * Correctly check that a password does not match the username (see contao/core#8209). * Check if a directory exists before executing `mkdir()` (see contao/core#8150). * Do not link to the maintenance module if the user cannot access it (see contao/core#8151). * Show the "new folder" button in the template manager (see contao/core#8138).

leofeyer added 2 commits February 26, 2016 16:28

Adjust the Controller::generateFrontendUrl() method.

b5c0d46

Adjust the page controller.

255d0a9

leofeyer added the defect label Feb 26, 2016

leofeyer self-assigned this Feb 26, 2016

leofeyer added this to the 3.5.7 milestone Feb 26, 2016

leofeyer mentioned this pull request Feb 26, 2016

Fehlerhafte URL bei News/Event RSS-Feeds - 3.5.6 #8204

Closed

leofeyer added 2 commits February 26, 2016 16:59

Adjust the non-navigation modules.

2e373ff

Update all other non-navigation resources.

246acda

leofeyer added 4 commits February 26, 2016 21:00

Use PageModel::getFrontendUrl() instead of Controller::generateFronte…

89cc8a5

…ndUrl().

Fix the Module::renderNavigation() method.

88bfef1

Fix everything but getSearchablePages().

ced4aa8

Fix the getSearchablePages() methods.

6b2aec1

leofeyer changed the title ~~[WIP] Always fix the domain and language when generating URLs~~ [RTM] Always fix the domain and language when generating URLs Feb 28, 2016

Correctly handle $pid=0 in Backend::findSearchablePages().

db5b8ac

aschempp reviewed Feb 29, 2016
View reviewed changes

leofeyer mentioned this pull request Feb 29, 2016

Use instanceof instead of !== null contao/core-bundle#451

Closed

Pass $strForceLang in Frontend::jumpToOrReload().

57abb98

leofeyer force-pushed the hotfix/fix-frontend-urls branch from 95b5a98 to 57abb98 Compare February 29, 2016 08:14

Correctly find the published pages.

001fcd4

leofeyer force-pushed the hotfix/fix-frontend-urls branch from de5e692 to 001fcd4 Compare February 29, 2016 10:03

Only overwrite the page information if it has not been set.

7bf3c75

Do not make findSearchablePages() depend on BE_USER_LOGGED_IN.

a83463a

leofeyer mentioned this pull request Feb 29, 2016

Add a flag to disable the FE preview in a model contao/core-bundle#452

Closed

leofeyer merged commit a83463a into hotfix/3.5.7 Feb 29, 2016

leofeyer deleted the hotfix/fix-frontend-urls branch February 29, 2016 16:17

fritzmg mentioned this pull request Mar 14, 2016

sitemap erstellt keine ssl links mehr #8270

Closed

DanielSchwiperich mentioned this pull request May 26, 2016

INFO: Contao incompatible change in Symfony v2.8.5 - _locale param in urls contao/core-bundle#510

Closed

Uh oh!

Comments

Conversation

leofeyer commented Feb 26, 2016

Uh oh!

aschempp commented Feb 26, 2016

Uh oh!

aschempp commented Feb 26, 2016

Uh oh!

leofeyer commented Feb 26, 2016

Uh oh!

aschempp commented Feb 26, 2016

Uh oh!

leofeyer commented Feb 26, 2016

Uh oh!

Toflar commented Feb 26, 2016

Uh oh!

leofeyer commented Feb 26, 2016

Uh oh!

leofeyer commented Feb 26, 2016

Uh oh!

leofeyer commented Feb 28, 2016

Uh oh!

aschempp Feb 29, 2016

Choose a reason for hiding this comment

Uh oh!

leofeyer Feb 29, 2016

Choose a reason for hiding this comment

Uh oh!

Toflar Feb 29, 2016

Choose a reason for hiding this comment

Uh oh!

leofeyer Feb 29, 2016

Choose a reason for hiding this comment

Uh oh!

Toflar Feb 29, 2016

Choose a reason for hiding this comment

Uh oh!

leofeyer Feb 29, 2016

Choose a reason for hiding this comment

Uh oh!

aschempp Feb 29, 2016

Choose a reason for hiding this comment

Uh oh!

leofeyer commented Feb 29, 2016

Uh oh!

Toflar commented Feb 29, 2016

Uh oh!

leofeyer commented Feb 29, 2016

Uh oh!

aschempp commented Feb 29, 2016

Uh oh!

leofeyer commented Feb 29, 2016

Uh oh!

Toflar commented Feb 29, 2016

Uh oh!

aschempp commented Feb 29, 2016

Uh oh!

leofeyer commented Feb 29, 2016

Uh oh!

leofeyer commented Feb 29, 2016

Uh oh!

Toflar commented Feb 29, 2016

Uh oh!

leofeyer commented Feb 29, 2016

Uh oh!

leofeyer commented Feb 29, 2016

Uh oh!

leofeyer commented Feb 29, 2016

Uh oh!

leofeyer commented Feb 29, 2016

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants