Daniel F

1 hour ago, Clover13 said:

Hi @Daniel F, the client area credentials should be accurate now.  Please try again.  Thanks!

Unfortunately the user has no permissions to access the ACP.

You do not have permission to access the Admin CP.

2 minutes ago, Edjazoli said:

is there any changes and I need to modify CRON command?

It depends on the command. Does it contain the path to your PHP binary? If yes, you'll need to adjust it to point to your recent PHP version.

It's working fine for me on my test instance, so there must be something else going on what we'll need to investigate.

Unfortunately I'm not able to get into your ACP, could you please review your ACP credentials we have on file?

If it’s for our marketplace, please report the review and we’ll remove it 

Do you mind to share any feed url which isn't working for you?

I’m investigating this via your ticket 

56 minutes ago, kurosaki ichigo said:

$iPosted = isset( $topic->contentPostedIn ) ? $topic->contentPostedIn : ( $topic AND method_exists( $topic, 'container' ) AND $topic->container() !== NULL ) ? $topic->container()->contentPostedIn() : array();
$return .= <<<CONTENT

That's either a plugin template or a 3rd party style, which the author of the plugin / designer will need to fix.

You could try to use the DEBUG_TEMPLATES constant to see which template results in this error.

3 hours ago, kurosaki ichigo said:

thanks for the reply, as I said the problem happens only with plugins that call the getTemplate.
at first i thought that the problem was only the plugin so i contacted the dev and explained him the situation , i gave him access to my site and he answered me like this :

 

that is why I am here to ask you.

ps : i have only the default theme , i have no custom themes , i have disabled all plugins and applications , still same problem .

Who was the developer? 

We have already an internal suggestion for this 

What browser are you using? 

I see it in the address bar and even the copied URL is

https://invisioncommunity.com/forums/topic/470924-emoji-in-seotitle-unfriendly-url-🔥😅😲💛🤩🤮😊

We're investigating this

Stu is correct, in 99,9999% we'll reject it, BUT it's also OK to use an existing storage handler like core_Theme in few cases like uploading a watermark image, logo or any other use cases where it's not worth to have an own file storage extension and database table and all the other logic, as long as you take care of ALL the logic like removing the file when the plugin is removed, updating the path when the files were moved or the storage handler was changed.

We have also logic in place ( see Application::uploadSettings() ) to register the settings so that the framework takes care of everything.

I'm already on it:)

4 hours ago, Andreas Grace said:

My whole account is set to run on PHP 8.1, I can't think of anything accessing the database running PHP 7.

As mentioned in the ticket, it seems that there's still a cron using the php7 interpreter path.

@Arcade King could you please check Plesk or your cron table and ensure that you're not affected by the same issue.

The reason that this issue happened now, even if PHP8 or PHP8.1 was used for months is, that you wouldn't have noticed till yet if the task was called with php7 or 8, but now we're using a php function inside the mail class which is only available in PHP8.

Can you please make sure that the cron is using the php8 executable? 

I would suggest to use the media manager which is part of the pages app for this.

12 minutes ago, usmf said:

One of our communities now has 8 locked tasks and one community has 6 locked tasks. 

Please review your cron settings, especially the path to the php executable. It seems that it's still using PHP7 to call the script!

We're going to improve the code for the CLI task system so that a warning is logged when the wrong php version is being used. 

1 hour ago, Andreas Grace said:

Same problem here with the 4.7.5 update, self hosted PHP 8.1 and tasks set to run with traffic. I unlock them and they lock again next time. Nothing in logs.

1 minute ago, OptimusBain said:

I didn't know about the Cron job path. I will check out the cPanel and confirm it's correctly setup. I've been running the community on PHP 8 for a few weeks now without these issues and I didn't update any Cron job settings.

Yea we're just starting to utilize the new PHP8 features and new functions, so there's now a new function being used inside our Mail Class which is only available in PHP>8

So each time a mail is being sent via the cron, it results in 

Quote

Error: Call to undefined function str_starts_with() (0)
#0 /home/.../init.php(927) : eval()'d code(144): IPS\_Email::_parseElementForClickTracking(Object(DOMElement), '..')

Are you calling the tasks via the cron option? If yes, have you updated the cron job command to point to the recent PHP version?

Please see https://invisioncommunity.com/forums/topic/470836-problem-with-locked-tasks/?do=findComment&comment=2917324 🙂

Can you confirm that you also updated the cron job after switching the PHP version?

8 minutes ago, Hatsu said:

Depending on your set up for cronjobs it can be that your path in the cronjob (config) still points to the 7.4 executable. If you use Plesk f.e. and you use their menu for cronjobs where you have to provide the absolute path to PHP this can happen. It happened for me when I changed my PHP version and forget about the cronjobs. But you can't see this in ACP.

Yea, I'm quite sure that it's this. The current command in the ACP to create the cron job points to  /opt/cpanel/ea-php80/root/usr/bin/php 

so anything created with PHP7.x would have pointed to /opt/cpanel/ea-php7....

According to the error log you're not using PHP8 for the CLI cron job, even if your TASK setting shows the path to the php8 executable.

I've called the locked tasks from the ACP where they worked without any problems and have added some logging code to the applications/core/interface/task/task.php to see what's going on.