Getting messages like this:

Deprecated: implode(): Passing glue string after array is deprecated. 
Swap the parameters in plugins\oik-bob-bing-wide\shortcodes\oik-dash.php on line xxx

where xxx had various values.

When creating [github] shortcodes I can't remember whether or not the link should be issue #3 or issues #3.

Proposed solution

Perform some basic sanitation & auto-correcting of the type parameter so that
both of the following will work

[github bobbingwide oik-bob-bing-wide Issue 3]
[github bobbingwide oik-bob-bing-wide issues 3]

Maybe even lower case everything.

Having changed my local development to use https: rather that http: I've discovered a strange anomaly with the PHPUnit tests for [bw_post] and [bw_page].

When originally developed, with WordPress options siteurl and home both set to http://qw/wordpress
site_url() returned http://qw/wordpress and admin_url() returned http://qw/wordpress/wp-admin/.

Now, with the https: protocol the schemes are different.
site_url still returns http: but admin_url returns https.
home_url also returns https:

I added a new method - test_site_url() - that demonstrates this.

Note: Rather than change the tests to use admin_url() and a different string to replace ( appending /wp-admin/ ), I used home_url().

In oik-requests we use a new field type of serialized to store information about each of the different possible query parameters to a request.

oik-fields was extended to support the display of a serialized array using [bw_field] / [bw_fields]

See [oik fields issue #10]

The same logic should be available to oik-bob-bing-wide's [bw_option] shortcode.

Currently, if you attempt to display a serialized field you get
Notice: Array to string conversion in C:\apache\htdocs\wordpress\wp-content\plugins\oik-bwtrace\libs\bobbfunc.php on line 60
Array

*_Note: *_There aren't that many serialized fields where it makes sense to display them directly.

I want to be able to style the output of the "oik-bbw/wp" block using the global styles solution.

The blocks in oik-bob-bing-wide are currently:

• written using the old style method const { __ } = wp.i18n; rather than the package method import { __ } from '@wordpress/i18n';
• built using a hand cranked webpack build
• registered manually in both JavaScript and server

I believe that in order to be able to allow the blocks to support typography, colours and so on, that I need to change them:

• to be written using the new method
• to be built using wp-scripts
• to be registered from block.json - similar to sb-post-edit-block
• to use API version 2

Requirements

• to support end user customization of block's font size, colour etc

Proposed solution

I know that the sb-post-edit-block allows this customisation, so I'll aim to build the blocks using the same method.

• to use API version 2
• to register blocks using block.json...
• in the server using register_block_type_from_metadata() or whatever's the flavour of the month.
• in the JavaScript using metadata loaded from block.json.
• to render SSR blocks using the new techniques involving get_block_wrapper_attributes()

If the solution doesn't work then I'll be mystified, but at least I'll be better prepared for the future.

Too low a memory limit and your site may crash in a big heap.
If you don't have phpinfo.php installed then you may not be able to find the front end memory limit all that easily.

Proposal

Extend the [wp] shortcode to display the memory limit.

Solution

Add a parameter called m which can be used to display the currently defined memory limit.
Example: [wp v p m] or [wp v m=y]

Notes:

• Use of the parameter requires you to request the version ( v parameter ).
• The value displayed may not be the memory_limit used in all instances; plugins and themes can alter it.

Block examples are provided for quite a few of the core blocks.
It would be nice to have a simple example of the Search block.

Requirement

Provide an example for the Search block

Solution

• Implement a simple example using

example: {},

which will display the server side rendered Search.

Since early 2017 a new editor has been under development. Code named Gutenberg this new editor is being developed as a feature plugin. It is expected to be merged into core for WordPress 5.0.

We need to be aware of Gutenberg and to attempt to be compatible with it.
Actually, it's the other way round. Gutenberg needs to be backward compatible with us.

According to Gutenberg's README.

Posts are backwards compatible, and shortcodes will still work.

That's not the case right now.

I've already raised an issue against Gutenberg ( # 4456 ) which affects the [bw_csv] shortcode.
It probably also affects the [bw_rpt] shortcode in exactly the same way.

Problems

Workarounds?

For 4456 - new lines being ignored

• This affects [bw_csv] and [bw_rpt]
• There is no workaround using the Gutenberg editor
• You have to revert to using the Classic editor

This message is returned when Server Side Rendering the oik-bbw/csv block in wp-pompey.org.uk, running WordPress 5.4.2

{"code":"rest_invalid_param","message":"Invalid parameter(s): attributes","data":{"status":400,"params":{"attributes":"content is not a valid property of Object."}}}

<!-- wp:oik-bbw/csv {
"content":"Time,Item\n
7.00pm,Connect to Zoom. Bring your own drink and chat\n
7.10pm,Organisers’ introduction to the online meeting\n
7:15pm,Talks start - including Q \u0026 A\n
8:45pm,Wrap-up"}
 /-->

Why?

It'd be nice to be able to include the GitHub genericon in links to GitHub content.

When testing [bw_plug option=’active_plugins’] the Warning: array_merge() message was issued for the plugin called wpdb-alt.

Expected output

Display of the plugin without any messages with "No info available" in the Plugin links.

Actual output:

Warning: array_merge(): Argument #2 is not an array in
\oik-bob-bing-wide\shortcodes\oik-plug.php on line 406

Explanation

• wpdb-alt.php is a plugin I developed to work with an "Alternative database" ( on 27th March 2017) in order to be able to locally reconcile the post content in two versions of the same website.
• It was developed to work in batch mode only.
• It has a plugin header
• It doesn't have a readme.txt file
• So bw_get_readme_data() returns null
• and array_merge() returns null

Proposed solution

Don't call array_merge when bw_get_readme_data() returns null.
We should then expect some information to be displayed....
but it's not working yet.

I want to be able to automatically sum the values in columns in a CSV table and display this in a totals line.
E.g. for this simple table with a totals line for totals=C,T,A It would be would be

Where the codes are

I haven’t decided about requirements when pagination is active.

Block examples are provided for quite a few of the core blocks.
It would be nice to have a simple example of the CSV block.

Requirement

• Provide an example for the CSV block

Solution

• Implement a simple example.

A,B,C
1,2,3
4,5,6

• Just using letters and numbers means it doesn't really need to be translatable.

In bw_get_plugin_info_cache2 the test for cached plugininfo for a plugin is currently checking for an object.

$response_xml = get_transient( 'bw_plug2_'. $plugin_slug );
if ( empty( $response_xml ) || !is_object( $response_xml ) ) {

The logic to test for an object was added in 6f90c6d

The actual result from get_transient is (now) an array.

Just a thought, having recently forgotten the shortcode name and gone straight into the parameters.

Actually, it might be a better idea to implement this is as some sort of shortcode override or alias, and use diy-oik.

As part of making oik 100% translatable and localizable it's time to extract the shortcode help, syntax and example logic from oik for the shortcodes which were originally in oik but are now implemented in oik-bob-bing-wide. Most of this code is in oik-sc-help.
This will reduce the number of strings that need to be translated for oik.

Note: for translated help text oik-bob-bing-wide need not be dependent upon oik v3.2 for this to be implemented. We just need to implement a filter function for _sc__help.
i.e. It should work with oik v3.1.n

See also bobbingwide/oik#9

Changes discovered by comparing wp-includes/css/dashicons.css in v4.1 and v4.7 lead to the following additions being required in bw_list_dashicons.

// New in WordPress up to 4.7
$di[] = "filter";
$di[] = "admin-customizer";
$di[] = "admin-multisite";
$di[] = "image-rotate";
$di[] = "image-filter";
$di[] = "editor-table";
$di[] = "unlock";
$di[] = "hidden";
$di[] = "sticky";
$di[] = 'excerpt-view';  // Now corrected
$di[] = "move";
$di[] = "plus-alt2";
$di[] = "warning";
$di[] = "laptop";
$di[] = "thumbs-up";
$di[] = "thumbs-down";
$di[] = "layout";
$di[] = "paperclip";

The WordPress info block ( oik-bbw/wp ) was originally developed as a couple of shortcodes [wp] and [guts].
[wp] was implemented in oik-bob-bing-wide, [guts] was first implemented in oik-block.

The current version of the block has 4 attributes which are strings:

The server side implementation doesn't handle all combinations.
If the g attribute is specified then we run [guts] to display the WordPress and Gutenberg version.
Otherwise we run the original WordPress shortcode.

Requirement

Improve the block and server side rendering to implement a better UI.

Proposed solution

• Change attributes to boolean toggles
• Rework server side code to use the toggles in this order: WordPress version, Gutenberg version, PHP version, Memory limit
• Add an example to display WordPress and Gutenberg versions by default
• Internationalize and localize
• Support font size and colours: text and background/gradient

Consider deprecating the bw_wp() function, implementing the new solution using oik_block_guts() or a new version of it.

For improved front end performance of the [bw_follow_me] shortcode I changed the logic to support SVG icons rather than
dashicons or genericons. Use theme=svg to choose this.

I implemented a shared library class OIK_SVG_icons for the purpose.

Requirements

• Improve the implementation of SVG icons for the [bw_dash] shortcode.
• Implement SVG icons for the [bw_github] shortcode.

Proposed solution

• Implement the shared library class-oik-svg-icons
• Change [bw_github] to use this shared library rather than genericons
• Change [bw_dash] to use the shared library logic
• Update SVG definitions to latest from Gutenberg's icons
• Eliminate redundant logic
• Update the Dashicons block to reflect new icons.

See also bobbingwide/oik#187 for notes about the [github] shortcode

I was converting to blocks some content on oik-plugins.com. As expected, it didn't convert all the shortcodes. But there were some that could easily be converted.
e.g. [bw_blockquote] could become a core/quote block.

How easy is it to add a transform to an existing block? Do I have to use the block registration filter?

I've been looking at a number of GitHub repositories which are for Genesis child themes and decided I wanted an easy way to display links to the repositories using their screenshots.
It makes sense to extend the [github] shortcode to display the image when the type parameter is a file name which is an image (e.g. .jpg, .png)

The image displayed would have an URL like this
https://raw.githubusercontent.com/bobbingwide/oik-bob-bing-wide/master/assets/oik-bob-bing-wide-banner-772x250.jpg

Shortcode example:
[github bobbingwide oik-bob-bing-wide assets/oik-bob-bing-wide-banner-772x250.jpg]

While we're at it, we may as well support other files.
Shortcode example:
[github bobbingwide oik-bob-bing-wide shortcodes/oik-github.php]

https://github.com/bobbingwide/oik-bob-bing-wide/blob/master/shortcodes/oik-github.php

We won't default the file name.
So a link to a theme by its screenshot.png file would be
[github bobbingwide genesis-oik screenshot.png]

When using the [bw_option] shortcode in a site where oik-fields was not activated a Fatal error was displayed due to the function bw_theme_field() not being defined.

Workaround

Activate oik-fields or don't use the shortcode

Proposed solution

Ensure the function is available regardless of the activation status of oik-fields

I need to rebuild the blocks in oik-bob-bing-wide.
The build for oik-blocks works but the build for oik-bob-bing-wide doesn't.

Update the build / tools so that the blocks work.

The bw_dash shortcode currently expects to be passed a single icon name.

Requirements

It so that it can display multiple icons in one invocation of the shortcode
e.g.
[bw_dash star-filled,star-filled,star-filled,star-half,star-empty]
would display a star rating of 3.5 stars of 5.

Proposed solution

• Accept multiple values in the icon parameter (positional parameter 0)
• call bw_dash_enqueue_font for the first icon only
• if multiple fonts are required then you'll need multiple bw_dash shortcodes
• use DIY-oik to create simpler shortcodes e.g. s15 through s55 for star ratings 1 to 5

Changes in PHP 7.1 mean that some logic which worked without problems under PHP 7 and earlier now issue Notices, Warnings Errors and even Fatal errors.

In the code for the [bw_post] and [bw_page] shortcodes we get Warning: Illegal string offset 'post_type' from the following code construct.

function bw_post( $atts=null, $content=null, $tag=null ) {
  $atts['post_type'] = bw_array_get_from( $atts, "post_type,0", "post" ); 

The code assumes that $atts is passed as an array or can be handled as an array.
When no parameters are set on the shortcode then $atts is passed as null.
The warning is issued from the assignment.

Many WordPress shortcodes avoid this issue by using shortcode_atts(), which casts the $atts parameter to an array. We might be able to find a solution by changing bw_shortcode_event, in oik.

The current version of the GitHub block supports setting of text and background colours and also size.

The block needs to be improved.

Requirements

• Remove the redundant, hardcoded header
• Make the block dynamic using Server Side Rendering rather than generating the [github] shortcode
• Make the block dynamic using JavaScript in the editor and Server Side Rendering in the backend.

Proposed solution

Implementation steps similar to above...

• Attempt to support deprecation
• Remove the redundant, hardcoded header
• Make the block dynamic using Server Side Rendering rather than generating the [github] shortcode
• Make the block dynamic using JavaScript in the editor and Server Side Rendering in the backend.

It's happened a couple of times. Sometimes, before pushing my changes I create a new .zip file for a plugin to test on a live server.
I find some problems, fix them, commit the changes, create a new zip file and re-upload.
But I don't pay attention to where I'm uploading the new .zip file.
WordPress lets me know I'm replacing the current version, but I know that so I continue.
Then I realise I've just uploaded the .zip file into a local install where the plugin I've updated was symlinked to the master GIT repo.
The plugin I've updated appears to work.
But I then discover that the master GIT repository is a completely empty repo.

No .git directory, Nothing.

Fortunately I have the newly installed plugin and the latest .zip file from which it came.
But, because my zip process doesn't package everything the I'm missing the following folders:

• node_modules
• tests
• assets

I can rebuild the node_modules, but can't recover the brand new tests I wrote, nor the commit history since the most recently pushed commit.

BUGGER

Is this a bug?

Is this a bug in WordPress?
Possibly. I know it's something I've tried to address in oik, detecting GIT repositories and symlinked folders.
But when oik's not activated, then this protection is not provided.
So the answer is
Yes. It would appear to be limitation of the new updating capability of WordPress core.

Could I improve my process?

Yes. Before creating the zip file push the most recent commits.

So process would be something like

• commit changes
• l10n - Run internationalization and localization routines
• pu - Run PHPUnit tests
• tgh - To Git Hub
• zip - package
• commit zipped version
• tgh
• upload and test

If there's a problem with the zipped version I really only need to change the version number if no one else has had access to the new version.

• Add trace levels to the tracing in the [bw_plug] shortcode
• Use bw_get_property() to avoid notices when accessing fields from $plugininfo

If the output of a shortcode is to be cached then we have to be able to cater for side effects of shortcode expansion such as script or style enqueing. The [bw_dash] shortcode enqueues the dashicons and/or genericons fonts. If the only instance of the bw_dash shortcode is going to be cached then the fonts may not be enqueued, so the display is incorrect.

A workaround to this problem is to ensure an instance of bw_dash is always invoked. But we may not want the icon to be displayed. This may be achieved using the class parameter, setting it to a value that causes the icon to not be displayed.

E.g
[bw_dash none font=dashicons class=bw_display_none]

Alternatively, the shortcode may be changed to make this easier. E.g. [bw_dash dashicons] would cause the dashicons font to be enqueued.

There are a number of shortcodes, which have now been converted to blocks, that load content direct from the shortcode or block's content attribute. [bw_csv] also supports a src attribute. If there is no content and the value is numeric then the content is loaded from the attached file to the attachment with the given post ID.
This may not have been used for a while.

I want to extend the logic for the following shortcodes and blocks

• [bw_csv] oik-bbw/csv
• [bw_css] oik-css/css
• [bw_geshi] oik-css/geshi
• [chart] sb-chart-block/chart
• [bw_graphviz] ?

Requirement

• Support loading of content from content, attachment file, local file or remote URL
• Ability the set the src attribute in the block editor

Proposed solution

• Add shared library class ( Oik_attachment_contents ) to replace the existing logic to obtain the $contents_array.
• Implement logic to support loading of a local file or remote URL
• Add a text field to allow entry of the src attribute in the block editor
• Write PHPUnit tests to validate the shared library content
• Implement shared library file in relevant plugins
• Optionally, allow the filename to be entered as content - if it's a single line without the separator character

bw_get_plugin_info2() is now receiving a different result from its request
being performed by the following code

$request_url = "http://api.wordpress.org/plugins/info/1.0/$plugin_slug.info";
$response_xml = bw_remote_get2( $request_url ); //, null );

Expected output

For some plugins hosted on WordPress the [bw_plug] shortcode would display the latest available information for the plugin.

Actual output

No info available

For some plugins the results appear to be unchanged. I'll need to confirm this!
I don't think it's the local caching of the results in transients.

Explanation

In a brief discussion on WordPress Slack Meta channel I was advised that I was using an endpoint that's not officially supported.
https://wordpress.slack.com/archives/C02QB8GMM/p1495034365502545

Subsequent messages indicated that there are a variety of acceptable formats giving slightly different results.

It turns out that in order to continue to receive the response as serialized data I should either remove the .info or change it to .php
For JSON format data I could use the .json suffix.

It's odd that the code had worked fine since April 2015 but is playing up now.
I suspect it's something to do with the new plugin directory.

Not sure if I've found the right source files... https://meta.trac.wordpress.org/browser/sites/trunk/wordpress.org/public_html/wp-content/plugins/plugin-directory/api/routes/class-plugin.php

https://meta.trac.wordpress.org/browser/sites/trunk/wordpress.org/public_html/wp-content/plugins/plugin-directory/standalone/class-plugins-info-api.php

The Archives widget only displays posts. We need to display the archive for other post types.

Requirements

• display archive list for post types other than post
• support parameters accepted by wp_get_archives

Proposed solution

• [bw_archive] shortcode
• automatic detection of post type for the archive?

While changing the Opacity RangeControl slider for sb-chart-block bobbingwide/sb-chart-block#31 (comment) I discovered the reason that none of the RangeControls were displaying the slider part.
I fixed this by removing the enclosing <PanelRow> and redundant <PanelBody> containers.

This problem also occurs in:

• wp-top12/wp-top12

Update code and PHPUnit tests to run without problems in PHP 8.1 and 8.2

See bobbingwide/bobbingwide#103

In the absence of tests for every function we should add tests to load every relevant .php file to check for Deprecated messages produced by PHP 8.2.
Relevant may/may not include files for blocks.

While writing a new bw_csv shortcode I'd failed to type the first ]
This led to the shortcode attempting to open the named file and Warning messages being returned.
This caused the new editor to report Updating failed.

[bw_csv y=Y n=N,Block,core,oik,Divi,Beaver Builder,Fusion objects,Site Origin

Actual output

<br />
<b>Warning</b>:  file(Builder,Fusion): failed to open stream: No such file or directory in <b>plugins\oik-bob-bing-wide\shortcodes\oik-csv.php</b> on line <b>254</b><br />

Twice

Expected output

A friendlier message as part of the shortcode response.

Problem explanation

Ths shortcode interpreted Builder,Fusion as the file name, which it then tried to open without validating the file's presence.

Proposed solution

• Validate the file name
• Validate the parameters
• Check there's no embedded content
• Some of the above

Workaround.

Insert the missing ]

When you visit a plugin on WordPress.org using the old style link
you get taken to a page that says "Test out the new Plugin Directory and let us know what you think."

The target URL is only slightly different.

https://wordpress.org/plugins/wordpress-seo/
https://wordpress.org/plugins-wp/wordpress-seo/

Should we be pointing users to the new plugin directory?
What happens when this goes live?

If a CSV file is pasted into a post then it's possible that the last n or y that should be converted to a dash icon yes or no is not actually converted.

[bw_csv y=Y n=N]Plugin,2015,2016
Akismet,n,n
oik-bwtrace,y,y
[/bw_csv]

In this example

• the first n in the Akismet row will be converted, but not the second.
• the first y in the oik-bwtrace row will be converted, but not the second.

Workaround

Append a , to each row.

There may be a new editor in WordPress 5.0 that will use a number of different "dashicons" that are implemented using SVG rather than being part of the dashicons font.

Requirement

• To be able to use [bw_dash] to display these icons.
• To handle all the icons defined in gutenberg/components/dashicon/index.js
• To be able to specify the displayed size.
• Drop support for icons which don't actually exist

Future requirement

• To use SVG icons in preference to dashicons or genericons
• To be able to support an SVG/dashicon block

There have been various instances of this message in the logs for oik-plugins.com and oik-plugins.co.uk
I got this one performing a bulk update to turn off comments on a number of pages.
I didn't realise that WordPress SEO would cause my posts to run their shortcodes at this point.

This is a duplicate of #19

When uploaded to blocks.wp-a2z.org the CSV block for the most recently published plugins fails to render due to a 414 HTML error code.

This occurs when there are 100 plugins in the "content" attribute.

For Top 10 WordPress plugins I want to improve the styling of the output from the [bw_plug] shortcode when displayed as a table. That means setting class names on tds and putting spans around each field in the last column.
The last columns class name will be the unmemorable 'vtdlut', being the lower case version of the first letter of each word in the fields: Version, Total Downloaded, Last Update, Tested

Additionally, I'd like the Total Downloaded and Last Update date to be formatted as per website settings.

Notice: Undefined index: host in C:\apache\htdocs\wordpress\wp-content\plugins\oik-bob-bing-wide\shortcodes\oik-plug.php on line 385

Now that I'm making better use of git, raising GitHub Issues, and tagging releases, etc..
I want a shortcode to be able to quickly reference GitHub repositories, issues, releases and stuff.

Proposed solution

[github] shortcode.

This first version will simply be used to create links to GitHub.

The shortcode will accept positional parameters representing:

• owner
• repository
• content type
• identifier

so that I can type something like
[github bobbingwide oik-bob-bing-wide issues 1]
and end up with a link to this issue.
#1

Initial limitations

It'll be very basic. It won't use the GitHub API to extract information from GitHub. It'll just make links a bit friendlier than typing the whole URL. The 'text' part of the link will be a bit more pleasing to the eye.

Don't know when but http://s-plugins.wordpress.org/ has been replaced by http://ps.w.org/

Also, there's a Notice trying to reference $plugininfo->oik_server

The [bw_plug] shortcode should be improved to provide easier links to a referenced plugin.
In a multisite environment it might also be nice if it were able to to detect the 'correct' site.

Also fix...

Warning: Attempt to assign property of non-object in C:\apache\htdocs\wordpress\wp-content\plugins\oik-bob-bing-wide\shortcodes\oik-plug.php on line 241

While attempting to use the [bw_csv] shortcode to display the contents of an attached CSV file, using the src= parameter I encountered the SSL security certificate problem again.

Warning: file(): SSL operation failed with code 1. OpenSSL Error messages: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed in C:\apache\htdocs\wordpress\wp-content\plugins\oik-bob-bing-wide\shortcodes\oik-csv.php on line 254

Warning: file(): Failed to enable crypto in C:\apache\htdocs\wordpress\wp-content\plugins\oik-bob-bing-wide\shortcodes\oik-csv.php on line 254

Warning: file(https://blocks.wp.a2z/wp-content/uploads/sites/10/2019/12/wp-plugins-blocks-20191109.csv): failed to open stream: operation failed in C:\apache\htdocs\wordpress\wp-content\plugins\oik-bob-bing-wide\shortcodes\oik-csv.php on line 254

Workaround

• Either fully qualify the name of the file
• Copy the failing URL and change the scheme to http.

Requirement

• replace the [guts] shortcode from oik-block with the eqiuvalent logic in a block

Proposed solution

• Enhance the oik-bbw/wp block to call the server logic for the guts shortcode when the attribute called g is set.
• No need to remove the code from the oik-block plugin, just don't activate oik-block.

Note: This is a QAD solution.
The original code uses text fields for the options to display version, PHP version and memory.
The new option to display Gutenberg information is also implemented as a string.

It's only really needed to assist problem determination, being performed immediately or in the future.

In a future version the attributes would be better implemented as toggles, with logic to convert the boolean variables to the attributes the shortcode functions expect.

Using Markdown a table can be created easily using vertical bar delimiters.
[bw_csv] currently expects commas as the delimiter.
There have been many times that I've unintentionally used a comma as part of the text... and seen additional unwanted columns.
It would be nice if the required delimiter character could be specified or inferred from the content.
e.g.

[bw_csv del=|]This|that
Row 1 | Cell 2
Row 2 | Cell 2, and still cell 2
[/bw_csv]

or ( inferred ) from the first delimiter in the content.

[bw_csv]This|that
Row 1 | Cell 2
Row 2 | Cell 2, and still cell 2
[/bw_csv]

Syntax should allow del= or sep= parameter for the delimiter / separator.
Don't expect both to be passed; behaviour undefined.

While running PHPUnit tests for PHP 8, with PHPUnit 9.5.2, I was getting the wrong results for [bw_post] and [bw_page].

I think it's something I did a while ago with SVG icons replacing dashicons.

1) Tests_oik_post_page::test_bw_post_no_params
Failed asserting that two arrays are equal.
--- Expected
+++ Actual
@@ @@
 Array (
     0 => '<a href="https://qw/src/wp-ad...Post">'
-    1 => '<svg aria-hidden class="svg "  role="img" focusable="false" xmlns="http://www.w3.org/2000/svg" width="24" height="24" viewBox="0 0 24 24">'
-    2 => '<path d="M10.44 3.02l1.82-1.82 6.36 6.35-1.83 1.82c-1.05-.68-2.48-.57-3.41.36l-.75.75c-.92.93-1.04 2.35-.35 3.41l-1.83 1.82-2.41-2.41-2.8 2.79c-.42.42-3.38 2.71-3.8 2.29s1.86-3.39 2.28-3.81l2.79-2.79L4.1 9.36l1.83-1.82c1.05.69 2.48.57 3.4-.36l.75-.75c.93-.92 1.05-2.35.36-3.41z" />'
-    3 => '</svg>'
-    4 => '</a>'
+    1 => '<span class="texticons texticons-unknown ">'
+    2 => '</span>'
+    3 => '<span class="texticons texticons-dashicons-admin-post ">'
+    4 => '</span>'
+    5 => '</a>'
 )

Using [bw_csv] you can easily display ticks and crosses instead of y's and 'n'. The bw_csv__syntax() function needs updating to reflect this.