handig

Thank you for your help.

I’m happy. I really don’t know how the scope="row"?for the first cell of the header row appeared. Happy that it is gone.

This is my modified code now where I tried to follow your tip to get rid fof the wrapper function and I adjusted the priority of the filter to 10 instead of 100:

add_filter('tablepress_cell_tag_attributes', 'tablepress_correct_scope_attributes', 10, 7);

/**
 * Correct scope attributes for table headers
 *
 * @param array $tag_attributes Array of HTML attributes for the cell.
 * @param string $table_id The current table ID.
 * @param string $cell_content The cell content.
 * @param int $row_idx The row number of the cell.
 * @param int $col_idx The column number of the cell.
 * @param int $colspan_row The number of combined columns for this cell.
 * @param int $rowspan_col The number of combined rows for this cell.
 * @return array Modified array of HTML attributes for the cell.
 */
function tablepress_correct_scope_attributes($tag_attributes, $table_id, $cell_content, $row_idx, $col_idx, $colspan_row, $rowspan_col) {
    // Correct the scope attribute for the first cell in the header row
    if ($row_idx == 1) {
        $tag_attributes['scope'] = 'col'; // All cells in the header row should have scope="col"
    }
    // Set scope='row' for the first cell in each body row
    elseif ($col_idx == 1) {
        $tag_attributes['scope'] = 'row';
    }

    return $tag_attributes;
}

Hi,
Worked some more on it and I’m getting more confused.

Could it be that Tablepress is caching/rendering something when clicking on Table options-Table Head row-The first row of the table is the header of the table?

That would explain the strange outputs. I think my new code seems to work as it returns scope ‘col’ for the header row cells and scope ‘row’ for the first cell of the body rows.

I did some testing on two sites one on Generatepress and one on Twenty Four theme. The original code snippet didn’t seem to work on the Twenty Four theme. It works on Generatepress. My second code snippet seems to work on Generatepress and Twenty Four theme.

Hi,

I tried the other approach. So I added the first_column_th=true?parameter to the “Configuration parameters” field of the “TablePress table” block?and added this code:

add_action('init', 'add_tablepress_cell_attributes_filter');

function add_tablepress_cell_attributes_filter() {
    // Use a high priority to ensure our filter runs last
    add_filter('tablepress_cell_tag_attributes', 'tablepress_correct_scope_attributes', 100, 7);
}

/**
 * Correct scope attributes for table headers
 *
 * @param array $tag_attributes Array of HTML attributes for the cell.
 * @param string $table_id The current table ID.
 * @param string $cell_content The cell content.
 * @param int $row_idx The row number of the cell.
 * @param int $col_idx The column number of the cell.
 * @param int $colspan_row The number of combined columns for this cell.
 * @param int $rowspan_col The number of combined rows for this cell.
 * @return array Modified array of HTML attributes for the cell.
 */
function tablepress_correct_scope_attributes($tag_attributes, $table_id, $cell_content, $row_idx, $col_idx, $colspan_row, $rowspan_col) {
    // Correct the scope attribute for the first cell in the header row
    if ($row_idx == 1) {
        $tag_attributes['scope'] = 'col'; // All cells in the header row should have scope="col"
    }
    // Set scope='row' for the first cell in each body row
    elseif ($col_idx == 1) {
        $tag_attributes['scope'] = 'row';
    }

    return $tag_attributes;
}

But now the first cell of the header row is set to scope ‘row’ while it should be scope ‘col’. The subsequent rows have their first cells set to scope ‘row’.
I made a test page here you see the output is:

<thead>
<tr class="row-1">
	<th class="column-1" scope="row">Feature</th><th class="column-2" scope="col">Product A</th><th class="column-3" scope="col">Product B</th>
</tr>
</thead>
<tbody class="row-hover">
<tr class="row-2">
	<th class="column-1" scope="row">Schaalbaarheid</th><td class="column-2">Hoog in de middenklassen</td><td class="column-3">Laag voor de lagere klasses</td>
</tr>
<tr class="row-3">
	<th class="column-1" scope="row">Prijs</th><td class="column-2">2 euro</td><td class="column-3">3 euro</td>
</tr>
</tbody>

And I would want it to be one data table with three column header cells:

<thead>
<tr class="row-1">
	<th class="column-1" scope="col">Feature</th><th class="column-2" scope="col">Product A</th><th class="column-3" scope="col">Product B</th>
</tr>
</thead>
<tbody class="row-hover">
<tr class="row-2">
	<th class="column-1" scope="row">Schaalbaarheid</th><td class="column-2">Hoog in de middenklassen</td><td class="column-3">Laag voor de lagere klasses</td>
</tr>
<tr class="row-3">
	<th class="column-1" scope="row">Prijs</th><td class="column-2">2 euro</td><td class="column-3">3 euro</td>
</tr>
</tbody>

• This reply was modified 3 months, 4 weeks ago by handig.

Looking forward to it. I appreciate that you take a broader view which includes other blocks and try to make for us the whole design process easier.

• This reply was modified 1 year, 6 months ago by handig.

Ah nice you are correct. The style card do work cross-site. Really nice function.

I think your blocks are a great foundation to build landingpages. And with the style cards I can easily adopt it to a corporate identity.

Probably a bit far fetched. But what would be really cool if the style cards could be used on forms plugins too. I’m using Formidable Forms which has styling but you can disable that. Maybe if you have a special formidable forms container block where you can insert the formible forms block so that it inherits the styling rules from the styling card?

Hi,
Maybe the problem is bigger. I think this issue also leads to critical errors.

I have PHP 8.1 and ManageWP Worker 4.9.15. Get the same notices. Site seems to work okay, but when a form is submitted I get an critical error. The debug log doesn’t log it. But I made a screenshot video where the error is displayed: /wp-content/plugins/worker/src/MWP/Worker/Request.php on line 198

I contacted ManageWP support, hope they get a solution for this. As a workaround I enabled the PHP extension PDO. Don’t know why, but the critical error doesn’t occur when that is enabled.

Host doesn’t have Redis. Guess my question is as follow.

If I do not object cache for for posts, post_meta, users and user_meta, does it have an added value to enable Memcached?

I have Memcached installed and added add post_meta and posts to the do not cache groups.

But keep getting notices in my debug log. So I’m going to add users and user_meta. But I’m trying to understand how it works?

If adding ‘posts’ to the ‘do not cache groups’ means that memcached isn’t used for posts, what is the use of enabling memcached at all?

Hi,
Also noticed this in my debug log.

Hi,
Thanks for the code. I tried it and it works, but there are some PHP warnings that this will throw an Error in a future version of PHP.

Warning: Use of undefined constant ‘genesis – assumed ”genesis’
Warning: Use of undefined constant blocks – assumed ‘blocks’
Warning: A non-numeric value encountered
Warning: A non-numeric value encountered
Warning: Use of undefined constant fontawesome’ – assumed ‘fontawesome”
Warning: A non-numeric value encountered in
Warning: call_user_func_array() expects parameter 1 to be a valid callback

This is the code I used:

function remove_genesis_blocks_fontawesome() {
	wp_dequeue_style( 'genesis-blocks-fontawesome' );
}
add_action( 'init', 'remove_genesis_blocks_fontawesome', 20 );
add_action( 'enqueue_block_editor_assets', 'remove_genesis_blocks_fontawesome', 20 );

if ( wp_style_is( ‘genesis-blocks-fontawesome’ ) ) {
wp_dequeue_style( ‘genesis-blocks-fontawesome’ );
wp_deregister_style( ‘genesis-blocks-fontawesome’ );
}

The warnings are referring to this line:

if ( wp_style_is( ‘genesis-blocks-fontawesome’ ) ) {

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

Hi,
Thanks a lot for the plugin. I stubmled on it before but never had a concrete usage for it. Now I do and it really works great.

Initially I couldn’t generate a sitemap with either. At the end I didn’t get it working with Rankmath but it worked with Yoast.

These were the steps I followed:

I have to Include an Addtional URL (absolute) to the Sitemap URL of Yoast (or Rankmath) in the Simply Static Settings to get it generated.
Then I got a XML parse error after uploading the generated files. The Rankmath and Yoast sitemaps are referring to a main-sitemap.xsl. I couldn’t get it working with Rankmath. With Yoast I got it working by Including Additional Files …/wp-content/plugins/wordpress-seo/css/main-sitemap.xsl

I’m not sure if the XML parse error is a problem in getting your sitemap picked up but if it is I would use Yoast. I prefer Rankmath though.

Do you know of a way to get the Rankmath main-sitemap.xsl generated at the right place?

Thanks. The WP 5.5 news is really nice. In the meantime I was thinking about using WP OPcache plugin to automatically flush opcache when WordPress is updated.

And I was thinking about setting opcache to:
opcache.revalidate_freq=60
opcache.validate_timestamps=1

This way updated pages are ‘there’ in 60 seconds.

And other non-default opcache settings:
opcache.memory_consumption=512
opcache.max_accelerated_files=50000
to avoid opcache to be full/prevent opcache to restart cache.

I just typed in Firefox the url without the https. So for example https://mywebsite.com.

It didn’t redirect while the htaccess file had the #Really Simple SSL redirects rules. I know mod_rewrite.c worked because permalink like mywebsite.com/sample-post/ permalink works.

Then I activated WordPress 301 redirect in REally Simple SSL while the option of htacess 301 redirect is also chosen. Then the redirect from http to https works.

I then deactivated WordPress 301 redirect (so only htacess redirect in plugin) and then to my surrise the 301 htaccess redirect seems to work again.

So happy that it works, but I’m wondering if this will repeat itself. Ofcourse I could leave WordPress 301 redirect on, but I’m afraid if this will make my pagespeed slower.

The host confirms the module is active.