hakre

Hello @iapial (/cc @arrasel403), thanks for reaching out. What I can see in https://github.com/WPDevelopers/simple-301-redirects/commit/d9aa6b0f885922c03f2be96487d95ac4a79e765f looks good to me.

Not an issue that would render the change non-functional, nevertheless you may be interested that the expression

( isset( $_SERVER['HTTP_HOST'] ) && isset( $_SERVER['REQUEST_URI'] ) )

can be simplified in PHP as isset() supports multiple variables and only returns true when all are set. Example:

isset( $_SERVER['HTTP_HOST'], $_SERVER['REQUEST_URI'] )

More details about isset() can be found in the PHP manual at https://php.net/isset .

• This reply was modified 1 year, 1 month ago by hakre.

Oh no worries, and don’t make it harder than it needs be. Just an HTTP URL that wget(1) can grab from the command-line should suffice. Just drop the link here or let me know if the support team is not capable for some reason.

Thanks again.

• This reply was modified 2 years, 2 months ago by hakre.

Hi @arrasel403,

sorry for not being responsive.

First of all thanks for providing a link, unfortunately the plugin is updated via WordPress itself, so we take the released version.

So how does this work? As you have closed here, does it mean there is already a new fix release? This was not clear with closing the topic from your end.

(the download link didn’t work for me in any case, I could have created a patchset, but unfortunately even that is not possible as the download does not work)

Thans so far.

The reason is rather straight forward: Access on $_SERVER on array members that don’t exist in CLI (PHP-CLI-SAPI) to construct some URL.

When you try to reproduce enable PHP error reporting to the highest level, that should show it.

It requires to run the WP cron via crontab.

To quote from my extended feedback in the other thread:

To add a bit more information, the issue manifested when running within cron and the PHP 8.0 language level. With the PHP 7.4 language level I didn’t see this notice. As PHP 7.4 will be out of main project support this year, and the plugin should be forward compatible with PHP 8.0 / 8.1 language levels, I think it is worth to address this notice.

A first fix I’m currently running is to have the function return void (as in the phpdoc which also looks like an error) in case HTTP_HOST is not within $_SERVER.

I must admit I have no clue why the function is called in the cron context anyway, but this is perhaps something that rings a bell on your end.

This type of fix prevents the notice naturally and it didn’t produce any other notices as a side-effect so far.

• This reply was modified 2 years, 3 months ago by hakre.
• This reply was modified 2 years, 3 months ago by hakre.
• This reply was modified 2 years, 3 months ago by hakre.
• This reply was modified 2 years, 3 months ago by hakre.

To add a bit more information, the issue manifested when running within cron and the PHP 8.0 language level. With the PHP 7.4 language level I didn’t see this notice. As PHP 7.4 will be out of main project support this year, and the plugin should be forward compatible with PHP 8.0 / 8.1 language levels, I think it is worth to address this notice.

A first fix I’m currently running is to have the function return void (as in the phpdoc which also looks like an error) in case HTTP_HOST is not within $_SERVER.

I must admit I have no clue why the function is called in the cron context anyway, but this is perhaps something that rings a bell on your end.

This type of fix prevents the notice naturally and it didn’t produce any other notices as a side-effect so far.

Can confirm the issue established and retained in 2.0.6.

It looks like the function get_address() gets called in contexts there is no HTTP available, which confirms this original report.

@arrasel403: Please reopen.

@glx77 Sorry, that was / is not possible, now not any longer. It was the old design and it’s now gone. Unfortunately for the new server, I would need to double-check if it still provokes the error. At least I’ve kept the way on how to reproduce.

Perhaps just as a take-away that for any data structure in JSON every access needs to be guarded unless it has been asserted already earlier on (from a stability standpoint for these errors).

Could take a couple more weeks until I stumble over this again, just saying.

Slt Edson Galina Fortes,

merci.

Its on a 404 page so it’s not taking the whole site down. Just wanted to report as it’s a fatal error in the code and thought you might want to know about at least.

Using the W3C checker I’ve checked the page and there are only two errors: a missing alt attribute on an img tag and a css directive with too many values – if it helps.

And they told me the Weglot Pro thing was on the limit, so perhaps this for the JSON?

@glx77 thanks for keeping this issue updated, excuse me if I appear ignorant here, it’s not intended, I may miss something here:

– composer.json is still in, didn’t you wanted to take it out with the next release (which is now the current, right?) ?

– you? have removed/hidden the repository (and perhaps another) from github: https://github.com/weglot/weglot-php – but seem to have missed its representative package on packagist: https://packagist.org/packages/weglot/weglot-php

you certainly have many reasons making the repositories private, but quel bordel.

do I need to suggest users to run weglot out? what kind of representation is that? this is creating obstacles over obstacles.

@glx77 one functionality of the plugin is to make changes to it. Right now it is indeed not easy to understand that those repositories are private now (I do can see some parts are in the vendor folder). Perhaps that would not have been an issue if there would be no composer.json in the package.

@glx77 composer install is just an example that sources are missing in the vendor folder. Would you please be so kind and check if they are complete?

• This reply was modified 3 years, 8 months ago by hakre.

Slt @remyb92, yes, it looks like it is incomplete, a vanilla composer install errors with the source package. Maybe the development requirements are missing?

That is just a warning, used for debugging purposes. You won’t see it if you don’t have WP_DEBUG enabled.

I have used that to fix some HTTP standard violations within wordpress core, it’s likely that some plugin authors are also violating the standard (at least the current HTTP 1.1 one).

This is taking that standard strict, it’s just that most browsers are able to deal with relative links, too in location headers. The problem is that location headers have no defined base URI so that relative URIs technically do not work here. That’s also why in HTTP 1.1 this is not possible and why the plugin gives notice when you are in development mode (WP_DEBUG).

See as well: How to Debug Redirect Problems in WordPress (about the debug mode of the plugin)

Actually that’s true, however the question remains how to do it? Even with CSS only ??

@nacin: Just wanted to link it while reading WPDEVEL.