Acceptance Criteria:

1. Used CSS should be generated for the different language homepages that are stored in the subdirectories with TranslatePress
2. Used CSS should be generated correctly for translated pages different than homepage with TranslatePress
3. Used CSS should be generated correctly for regular, not translated homepage and other pages with TranslatePress
4. No regressions in generating Used CSS without TranslatePress

Scope a solution

To fix that issue we can create a thridparty class that detect TranslatePress by checking if the constant TRP_PLUGIN_VERSION is defined.
Then we will create an callback on the rocket_rucss_is_home_url with the following logic:

	add_filter('rocket_rucss_is_home_url', function( $is_home, $url ) {
	
	$url_converter =  new TRP_Url_Converter( new TRP_Settings() );
	$language = $url_converter->get_lang_from_url_string($url);
	
	$url_language = $url_converter->get_url_for_language($language);

	return $url === $url_language ? $url_language : $is_home;
	}, 10, 2);

Estimate the effort

Effort S

@piotrbak I am re-opening this one as the issue is still happening with 3.14.3.

According to @mostafa-hisham, we send the request to the queue which is for is_home but when we fetch the data we check the non-home queue.

After adding error_log() statements here:

On the first pass $url, $url_language, and $home_url have the correct value for the additional language, e.g. https://example.com/fr.

When retrying, only the $url is correct. The other two values are that of the default language: https://example.com/.

I rolled back TranslatePress to 2.5.4 in case they changed something on their side but the issue is still there.

Reproduce the issue ✅

Identify the root cause ✅

I think this is coming from the context, front or admin. When on admin the home URL is not rewritten, so we don't get the expected values.

Scope a solution ✅

There is a filter we can use, and that is already in use in other methods of the compatibility class trp_add_language_to_home_url_check_for_admin.

Using add_filter( 'trp_add_language_to_home_url_check_for_admin', '__return_false' ); before using the methods from the converter class should make sure we get the expected values.

We can do remove_filter( 'trp_add_language_to_home_url_check_for_admin', '__return_false' ); after.

Estimate the effort ✅

Effort [XS]

Good catch @Tabrisrp

Also I think we can use the method get_home_url_for_lang instead of the line:

[Enhancement] and I can see a room for enhancement by making private properties for mostly used variables like

$translatepress = TRP_Translate_Press::get_trp_instance();

and

$converter      = $translatepress->get_component( 'url_converter' );

this is used everywhere, what do u think?

Scope a solution

The first step will be to change the table to add a new is_home field.

For that we will have to change the inc/Engine/Optimization/RUCSS/Database/Tables/UsedCSS.php class to change the schema and add the migration logic.
Then we will have to change the schema to add the new field inc/Engine/Optimization/RUCSS/Database/Schemas/UsedCSS.php.
We will have to do the same for the rows in inc/Engine/Optimization/RUCSS/Database/Row/UsedCSS.php.
Finally we will have to add the is_home parameter to the create_new_job method.

The second step is to reuse that new logic inside the controller.
For that we need to add the is_home when creating the row and in check_job_status reuse the row value instead of calling the method is_home again.

Estimate effort

Effort S

Sounds good. Just one quick though for the future: what if we add a third queue at some point? We would have to add another column to the datamodel.
It won't cost more and it would be more future-proof to add a column "queue_name" instead of "is_home", and have constant strings to identify the queues, like DEFAULT and HOME for now?

@CrochetFeve0251 ⤴

Sounds good. Just one quick though for the future: what if we add a third queue at some point? We would have to add another column to the datamodel. It won't cost more and it would be more future-proof to add a column "queue_name" instead of "is_home", and have constant strings to identify the queues, like DEFAULT and HOME for now?

@MathieuLamiot We could do this but we send a boolean is_home to the SAAS and not the name of the queue so I think that would be more logic to save a boolean.
'is_home' => $this->is_home( $url ),

As @Mai-Saad stated that the issue was not reproducible on 3.15.4, we concluded to block it for the moment.

Let's reopen it when needed