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.

The following shortcodes, which depend on the new line character being respected in content, may not work correctly after being manipulated by the Gutenberg editor
[bw_css]
[bw_geshi]

Analysis

The reason we see br's for the [bw_geshi] output is because gutenberg_wpautop() introduces them but bw_geshi() doesn't strip them.
We don't see them in [bw_css] because the oik_css() function removes them using bw_remove_unwanted_tags().

With oik-css v1.1.0 the oik-css/css block no longer displays example CSS when the text= attribute is not empty.

It works for the shortcode and on oik-plugins.co.uk, but not on oik-plugins.com

Using the shared library logic developed in bobbingwide/oik-bob-bing-wide#40 for the CSV block, apply similar changes to the [bw_csv] and [bw_geshi] shortcodes and their associated blocks oik-css/css and oik-css/geshi.

Requirements

• Improve the support for loading content from a source file rather than being entered into the block
• Improve the blocks to add a text field used to identify the file to be loaded.

Proposed solution

• Implement the shared library file libs/class-oik-attachment-contents.php
• Add a text field in the Settings area to accept the attachment ID, URL or file name
• Update documentation with appropriate examples

For a while now I've been using the WordPress embed block to embed content from another site / same site but have been noticing strange anomalies. Sometimes the embed works fine in the editor but doesn't display the same output in the front end.

Steps to reproduce

With / without oik

First attempt
I tried reproducing the problem in s.b/cwiccer, with a simple embed from the same site. ( s.b/cwiccer/gm ) It worked OK when oik wasn't activated but didn't when oik was activated. I'd chosen a bad example. The post ( entitled GM ) used the [bw_show_googlemap] shortcode.

Second attempt
Embedding sb/cwiccer/pagey-posts produced the same result regardless of oik's activation status.

Here you can tell that oik's activated since the [oik] shortcode has been expanded to oik

When attempting to test oik-css after applying a fix it failed immediately

1) Tests_admin_oik_css::test_oik_css_options_bw_autop_enabled
Error: Call to undefined function bw_form_start()

Activating oik-bwtrace resolves the problem.

Determine if this is sensible requirement.

Note: oik-css delivers two blocks: CSS and GeSHi. These work even when oik is not activated, but the admin page is dependent upon oik.

oik-css needs to be internationalized and localized using the same i18n and l10n techniques as for oik.

See https://github.com/bobbingwide/oik/issues/#9.

As noted in #7, when syntax highlighting with lang=html5, then HTML tags are linked to December.com. More often than not these links aren't wanted as they lead to outdated documentation.

And since there aren't any links for some languages it would make sense to turn them off for all languages.

Default GeSHi processing and my comments

Proposed solution

They should to be disabled, for all languages, using

$geshi->enable_keyword_links(false);

This also means replacing the use of geshi_highlight() with our own function bw_geshi_highlight().

Note: For Syntax highlighting of PHP we can use the [bw_api] shortcode https://www.oik-plugins.com/oik_shortcodes/bw_api/ This will produce links to PHP and oik's documentation of WordPress APIs: core, plugins and themes.

For oik-requests the [bw_sql] shortcode would benefit from having the SQL formatted using GeSHi.

Proposed solution

Add support for the GeSHI mysql.php formatter
Syntax:

[bw_geshi mysql] 
SELECT option_name,  option_value FROM wp_options WHERE autoload = 'yes'
[/bw_geshi]

oik-css uses GeSHI for pretty printing of code samples using the [bw_geshi] shortcode.

Actual output

This produces the following message under PHP 7.2

Deprecated: Function create_function() is deprecated in C:\apache\htdocs\wordpress\wp-content\plugins\oik-css\geshi\geshi.php on line 4751

Expected output

No messages

Explanation

The GeSHi code contains the deprecated create_function.

Proposed solution

Update the version of GeSHi.

• The version currently included is 1.0.8.12.
• The latest version is 1.0.9.0.
• Since this version has not yet been changed for PHP 7.2 we’ll have to do it ourselves.
• I raised an Issue GeSHi/geshi-1.0#98
• A pull request was created. See GeSHi/geshi-1.0#100
• Create unit tests that will produce messages under 7.2 until the deprecated logic has been removed.
• Apply the pull request to a local copy of the repository.
• Copy the changed files to oik-css

GeSHI links:

• http://qbnz.com/highlighter/
• Https://github.com/GeSHi/geshi-1.0

Note: oik-css will use another version of GeSHi if it has already been loaded by another plugin. This is because it was being used alongside wp-syntax; a long time ago. If the other version which has already been loaded is back level then the Deprecated message may appear. Should we test for this? Or is the deprecated message good enough. I’d say the latter.

During testing of WordPress 4.7-beta3 ( & 4 ) the following message was displayed when WP_DEBUG is true.

Notice: Indirect modification of overloaded element of WP_Hook has no effect in C:\apache\htdocs\wordpress\wp-content\plugins\oik\includes\oik-filters.inc on line 67

oik-css uses the bw_replace_filter() function from oik's includes/oik-filters.inc
This function sees $wp_filters as a multi-dimensional array.

The Notice is issued from

    $saved =& $wp_filter[$tag][$priority][$function_to_replace];

In WordPress 4.7 the $wp_filter array is of WP_Hook objects.

This issue is associated with another issue in the oik base plugin. bobbingwide/oik#58

I recently added some custom CSS to a page to style the output from [bw_related]
When I viewed it on my iPhone I found that the Cost field was overriding the title.
It was just too narrow.
The pragmatic solution was to alter the position of the Cost field for every display.
But I would have preferred to only have done this for narrow displays.
I would have used a CSS @media rule, if I could remember the syntax.
I thought that [bw_css] could help by allowing a media= parameter.
bw_css would wrap any content inside a @media query.

The default would be @media only screen and ( max-width: . valuepx ) {
when value is an integer.

For the [bw_geshi] shortcode when the lang= parameter is a certain value we need to undo some of the processing performed by other filters attached to the_content. For some languages this means eliminating unwanted paragraphs and breaks.

This is not the case for html and html5.

We also have ‘none’, which is intended for formatting examples of shortcodes.

Expected output

<p>What happens <b>here</b>?</p>

Actual output

What happens <b>here</b>?

Notes:

• Syntax highlighting is not being performed for lang=html. This is a bug.
• For lang=html5 the tags are linked to December.com. We don’t want them, so they need to be disabled using $geshi->enable_keyword_links(false);. See #8

Proposed solution

• Create shortcode examples for each language, including none.
• Implement tests for these examples - making them pass with the actual output, even when it's not expected.
• Update to latest source from GeSHi and re-test.
• Correct the logic so that p and br tags are shown for html and html5.
• Update tests to reflect the expected result.
• Check what happens for lang=none
• Check whether or not html5 should be listed in the options for the lang= parameter.

Note: It may be necessary to revisit the hooks attached to the_content and other places where the shortcode may be expanded. Basically, we don’t want any wpautop logic applied to the content between [bw_geshi] and [/bw_geshi].

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

See bobbingwide/bobbingwide#103

While running npm run makepot I noticed a message associated with a missing translators comment in admin/oik-activation.php.

• For __( '%1$s may not be fully functional.', null)
• I updated the code in oik-css but questioned the necessity/validity of this change.
• During oik-zip processing the file is copied from oik's shared libraries.

Note: The translators comment is not missing from oik; there's another file that uses the same translatable text - admin/oik-activation.php

Explanation

• Many moons ago I implemented shared libraries in oik-css so that it was no longer dependent upon oik.
• The code in oik_css_activation() still exists, but is not invoked.

Proposed solution

• The oik_css_activation() function can therefore be removed
• admin/oik-activation.php is not required either.
• So we don't have to worry about the missing translator's comment.

Update the PHPUnit tests so that they run under PHPUnit 8 with WordPress 5.3.2

• Change setUp to return void
• Add name to testsuite
• Ensure wp_generate_attachment_metadata is available

- 1) Tests_shortcodes_oik_background::test_bw_background
Error: Call to undefined function wp_generate_attachment_metadata()

In a demo of the CSS block at WordPress Cambridge I noticed that styling of the h2 tag didn't take effect in the block editor.
Analysis shows that there's some Gutenberg CSS, in gutenberg/build/block-library/reset.css
that overrides the server side rendered CSS produced by the block.

html :where(.editor-styles-wrapper) h1, html :where(.editor-styles-wrapper) h2, html :where(.editor-styles-wrapper) h3, html :where(.editor-styles-wrapper) h4, html :where(.editor-styles-wrapper) h5, html :where(.editor-styles-wrapper) h6 {
    color: revert;
    font-size: revert;
    font-weight: revert;
    line-height: revert;
    margin: revert;

Can anything be done about this?

Note: If you do want to style h2 tags then you can use !important in the CSS.
Should the block do this automatically, or should it be a documented limitation?

The version of geshi.php in oik-css is 1.0.8.11
It should be updated to the latest 1.0.8.12 as this already has the required code for PHP 7.0

The oik-css plugin was originally built using webpack.

When used in WordPress 5.8 the Widget block editor produces a "doing it wrong" message due to the enqueueing of wp-editor.
It seems the best solution is to rework the code to build it using wp-scripts which will enable use of

import ServerSideRender from '@wordpress/server-side-render';

See bobbingwide/bobbingwide#30 (comment)

Requirements

• Ability to use the Widget block editor without getting messages regarding wp-editor.
• Which means changing the build to allow the import above.
• Build using wp-scripts
• Register each block using block.json
• Ensure each block can be selected
• Add some typography settings similar to UK tides

Proposed solution

• Copy and cobble the solution developed for oik-magnetic-poetry, as this is now ahead of sb-starting-block
• Remove unnecessary files: webpack.config.js and .babelrc
• Change package.json for oik-css
• Change block.json for each block: oik-css/css and oik-css/geshi
• Change oik-css/index.js and oik-geshi\index.js to register the block from block.json
• Change oik-css.php to register the blocks from block.json
• Change oik-css.php to use get_block_wrapper_attributes()
• Update node_modules and rebuild

Process for updating node_modules

1. Remove the existing node_modules folder
2. npm install
3. npm install @wordpress/scripts --save-dev

See https://developer.wordpress.org/block-editor/reference-guides/packages/packages-scripts/

This worked first time! In the next plugin just 1. and 2. or 1. and 3. and see if the build works

oik-css is currently built with wp-scripts v24.6.0
Does it need rebuilding for WordPress 6.3 or can it just be retested and readme.txt updated?