ziegel

the support of ‘page-attributes’ is required to be first added to the post type generated manually, in order, to later call the ‘menu_order‘ directive. This directives allows the order to be done according to defined setting and not according to default post creation time.

You may read more about it, here

So the adding of the element to be controlled on functions.php would now look like this:

function list_faq() {
    register_post_type('faq_questions',
        array(
            'labels' => array(
                'name' => __('FAQ'),
                'singular_name' => __('FAQ')
            ),
            'public' => true,
            'has_archive' => true,
            'supports' => array('title', 'editor', 'thumbnail', 'excerpt' , 'page-attributes')
        )
    );
}

add_action('init', 'list_faq');

And the placing on the website of the fetched content would now look like this:

<div class="tabcontent-box" id="id">
	<ul class="ul-content">
	<?php
	$query = new WP_Query(array(
		'post_type' => 'faq_questions',
		'orderby' => 'menu_order',
		'order' => 'ASC',
		'tax_query' => array(
			array(
				'taxonomy' => $current_term->taxonomy,
				'field' => 'slug',
				'terms' =>	$current_term->slug

			)
		)
	));
	while ( $query->have_posts() ) : $query->the_post(); ?>
		<li>
			<a href="<?php the_permalink() ?>" class="tabcontent-link"><?php the_title() ?></a>
		</li>
	<?php endwhile; ?>
	</ul>
</div>

And now… the magic returns, and moving by drag-and-drop of the elements with this plugin is back to working.

You may also manually change the numbering of menu_order on the WordPress POST data base, according the post_type of the highlighted chosen by you name. This is required when you have more p

the support of ‘page-attributes’ is required to be first added to the post type generated manually, in order, to later call the ‘menu_order‘ directive. This directives allows the order to be done according to defined setting and not according to default post creation time.

You may read more about it, here

So the adding of the element to be controlled on functions.php would now look like this:

function list_faq() {
    register_post_type('faq_questions',
        array(
            'labels' => array(
                'name' => __('FAQ'),
                'singular_name' => __('FAQ')
            ),
            'public' => true,
            'has_archive' => true,
            'supports' => array('title', 'editor', 'thumbnail', 'excerpt' , 'page-attributes')
        )
    );
}

add_action('init', 'list_faq');

And the placing on the website of the fetched content would now look like this:

<div class="tabcontent-box" id="id">
	<ul class="ul-content">
	<?php
	$query = new WP_Query(array(
		'post_type' => 'faq_questions',
		'orderby' => 'menu_order',
		'order' => 'ASC',
		'tax_query' => array(
			array(
				'taxonomy' => $current_term->taxonomy,
				'field' => 'slug',
				'terms' =>	$current_term->slug

			)
		)
	));
	while ( $query->have_posts() ) : $query->the_post(); ?>
		<li>
			<a href="<?php the_permalink() ?>" class="tabcontent-link"><?php the_title() ?></a>
		</li>
	<?php endwhile; ?>
	</ul>
</div>

And now… the magic returns, and moving by drag-and-drop of the elements with this plugin is back to working.

You may also manually change the numbering of menu_order on the WordPress POST data base, according the post_type of the highlighted chosen by you name. This is required when you have more p

the support of ‘page-attributes’ is required to be first added to the post type generated manually, in order, to later call the ‘menu_order‘ directive. This directives allows the order to be done according to defined setting and not according to default post creation time.

You may read more about it, here

So the adding of the element to be controlled on functions.php would now look like this:

function list_faq() {
    register_post_type('faq_questions',
        array(
            'labels' => array(
                'name' => __('FAQ'),
                'singular_name' => __('FAQ')
            ),
            'public' => true,
            'has_archive' => true,
            'supports' => array('title', 'editor', 'thumbnail', 'excerpt' , 'page-attributes')
        )
    );
}

add_action('init', 'list_faq');

And the placing on the website of the fetched content would now look like this:

<div class="tabcontent-box" id="id">
	<ul class="ul-content">
	<?php
	$query = new WP_Query(array(
		'post_type' => 'faq_questions',
		'orderby' => 'menu_order',
		'order' => 'ASC',
		'tax_query' => array(
			array(
				'taxonomy' => $current_term->taxonomy,
				'field' => 'slug',
				'terms' =>	$current_term->slug

			)
		)
	));
	while ( $query->have_posts() ) : $query->the_post(); ?>
		<li>
			<a href="<?php the_permalink() ?>" class="tabcontent-link"><?php the_title() ?></a>
		</li>
	<?php endwhile; ?>
	</ul>
</div>

And now… the magic returns, and moving by drag-and-drop of the elements with this plugin is back to working.

You may also manually change the numbering of menu_order on the WordPress POST data base, according the post_type of the highlighted chosen by you name. This is required when you have more posts that can be seen on the WordPress panel.

Issue seems to be un related to your plugin. My appologizes.

Issue could be related to a generic WordPress file of the name:

wp-includes/PHPMailer/PHPMailer.php

That file uses a miserable PHP function, of the name: gmdate() 

That functions uses UTC…

I have replaced it with the echo date('Y-m-d H:i:s'); function (around line 928), and also placed directive: date_default_timezone_set('Myontinenet/MyCountry'); on the beginning of the file.

This seems to have solved the PHP error log, not logging current time, but UTC time.

I have found the problem by searching for the usage of the string error_log( on all my domain files. That is because this is the PHP function that logs error logs, and those wrong error log, came from somewhere….

• This reply was modified 1 year, 7 months ago by ziegel.

I’m checking of this is kind of a syslog issue

• This reply was modified 1 year, 7 months ago by ziegel.

No, it’s not /etc/psa-webmail/roundcube/php.ini which I modified, and issue reappeared:

Time zone is set as correct in the PHP error log, however once an email is sent and there are PHP errors associated to its generation, the timezone changes to UTC

Can you please investigate if this issue is coming from the plugin’s code?

Problem could also come from another email software component, as:

/etc/psa-webmail/roundcube/php.ini

Where time is set as:

date.timezone = UTC

removed this comment.

• This reply was modified 1 year, 7 months ago by ziegel.

Ok, I have managed to install WP Offload SES Plugin Version 1.6.1, having it on a server backup file, and it seems to work smoothly.

Please let me know when version 1.6.4 out there, so I can install it.

Ok. I get what seems to be the logic of the needed fix, however do not konw the syntax and var name used, to implement it.

First it should be checked what PHP version is used. For older than version 8.2, the array data structure should be used.

For version 8.2 and newer, a second IF should be used, to see if there are errors or not. If there are errors, an array data structure should be used, and if there are no errors, the array should be removed from the code, as the result would be a bolean.

As I can not code the above on my own, although it should not be complicated at all for a junior developer, I would search for an old version of the plugin and install it. I hope disabling current plugin, and setting a new one, doesn’t break anything in the email configuration.

Can you please advise?

With the below code, it seems there is no PHP error, however emails are still stuck in the queue state:

function comprePhpVersion() {

		if(version_compare(phpversion() , "8.2") >= 0) {
			private static function setLastErrors($lastErrors)
				{
				static::$lastErrors = $lastErrors;
				}
		}
				
		else {
			private static function setLastErrors(array $lastErrors)
				{
				static::$lastErrors = $lastErrors;
				}	
		}	

}

Still no success

• This reply was modified 1 year, 7 months ago by ziegel.

I got the below PHP Error, and would soon look into it.

PHP Parse error:  syntax error, unexpected token "if", expecting "function" or "const" in /var/www/vhosts/example.com/httpdocs/wp-content/plugins/wp-ses/vendor/Carbon/Carbon.php on line 802

Hi,

Please note, getting and installing, older plugin versions, is not as that simple.

Thus, I am trying to figure out a possible solution, which seems to me, to be more ‘elegant’. That would be, modifying the Plugin code, on wp-ses/vendor/CarbonCarbon.php line number 800 or so, to suit both PHP versions:

if(version_compare(PHP_VERSION, "8.2") >= 0) {
	private static function setLastErrors($lastErrors)
			{
			static::$lastErrors = $lastErrors;
			}
}
			
else {
	private static function setLastErrors(array $lastErrors)
			{
			static::$lastErrors = $lastErrors;
			}	
}	

And, just to be on safe side, I have also restarted some server services, as:

systemctl restart apache2
systemctl restart nginx
systemctl restart plesk-php82-fpm

What I have done, is placed an IF for the PHP version. version_compare compares two versions and return three boolean values, where PHP_VERSION is a built-in PHP constant returning the numerical value of the used PHP version.

Thus, if the PHP version used is “8.2” or higher, I have returned a modified plugin code line, suitable for the new PHP version 8.2 data structure. This would mean, changing the previous code line which was private static function setLastErrors(array $lastErrors) to be private static function setLastErrors($lastErrors) (omitting the “array” inside setLastErrors(...).

For the else condition, where version is lower than PHP version 8.2, I have left the original code, with the data structure containing array, suiting older PHP versions: private static function setLastErrors(array $lastErrors)

The simple usage of the version_compare() PHP function and PHP_VERSION PHP constant, is simply explained in this link, or in section below:

The examples below use the PHP_VERSION constant, because it contains the value of the PHP version that is executing the code.

Example #1 version_compare() examples

<?php
if (version_compare(PHP_VERSION, '7.0.0') >= 0) {
    echo 'I am at least PHP version 7.0.0, my version: ' . PHP_VERSION . "\n";
}

if (version_compare(PHP_VERSION, '5.3.0') >= 0) {
    echo 'I am at least PHP version 5.3.0, my version: ' . PHP_VERSION . "\n";
}

if (version_compare(PHP_VERSION, '5.0.0', '>=')) {
    echo 'I am at least PHP version 5.0.0, my version: ' . PHP_VERSION . "\n";
}

if (version_compare(PHP_VERSION, '5.0.0', '<')) {
    echo 'I am still PHP 4, my version: ' . PHP_VERSION . "\n";
}
?>

Problem:

Emails are still stuck in queue. Forcing the cron currently does not release them. I suspect there is another problem in the current plugin version.

Please note, I have noted that PHP error log, for some reason uses UTC and not the local time zone. I have not fully succeeded in forcing it to use the current time zone set via PHP. I am bring this issue to your attention, as I have noticed on the mySQL data base database_oses_jobs that the time zone of queued emails is also using UTC time zone as is, for the queued emails (which are said to be related to: DeliciousBrains\WP_Offload_SES\Queue\Jobs\Email_Job) fields: available_at and created_at .

Thus may I ask, if it could be, that a set to error emails, time-zone issue be related to the root problem of emails queued with error not being sent even later on?

And finally, may I ask for your opinion, and if looking good, suggest you implement it, in a new plugin version release.

Possibly… the fix would be:

Old Line

private static function setLastErrors(array $lastErrors)

New Line

private static function setLastErrors($lastErrors)

Can you please be kind, and have a look?