bobbingwide / bigram Goto Github PK

When I recently created https://seriouslybonkers.com/bigram/sharing-board-2/
the first entry "Scowl because" was not sampled.
To correct this I edited the post and converted it to blocks.
I created a list of the words, then tried a paragraph with line breaks and finally a preformatted block.
Sampling didn't work until I changed the paragraph to

<!-- wp:paragraph -->
<p> Scowl because, school bear, so breakfast, squirrels believe, 
sometimes breathing, spoil blink, snuggle bubble, shadows barking, 
should be and see-saw bedstead. </p>
<!-- /wp:paragraph -->

Requirement

• Improve detection of SB's in block based content.
• Support blocks such as paragraph, and list.
• Consider supporting SBs which are bold, italicised or both.

We need a routine to populate the database with photos and screenshots containing SB bigrams.
For the first pass we want to reload the database with the photos that were in the Drupal version of the site.

• These are in the bigram/images directories.
• There are 65 in bigram/images
• And 20 in bigram/images/done

For each image the routine needs to create a bigram and attach the image.
More than one image can be attached to a bigram.
The logic should create the bigram with the date of the image.
The logic should also create as much information as possible:

• Category
• S tag
• B tag
• SEO meta description and keyword
• Body text

When attaching an image to an existing bigram it should be put through similar logic to that invoked when a new bigram is being created:

• change file name to match the bigram to which it's being attached
• set matching categories
• set featured image

While developing the first version of the genesis-SB theme for http://www.bigram.co.uk I noticed that there was a conflict between the taxonomy named 's' and the default WordPress behaviour for search.

I asked about it in the ukgenesis slack channel and @gamajo correctly pointed out that s is a reserved term. So I said I'd rename the custom taxonomies
from s to s-word and from b to b-word

@benfurfie then suggested I name them semantically. I replied I'd never forget, but @gamajo asked what happens when someone else joins / takes over the project.

So here's the issue that addresses this.

Solution

• Rename the custom taxonomies.... note that these are defined using the oik-types plugin.
• Update the database entries using MySQL.
• Change the batch process to use the new names.

While trying to reproduce the home page for seriouslybonkers.com in the SB theme I saw a lot of posts which had incorrectly formatted "read more" links.

The screenshot shows the end of a post which doesn't exhibit the problem followed by two which do.
Both of these postsonly contain automatically generated content - a classic block.

<!--more-->Sampled from Seize Bees.

It would appear that the post-content block is formatting the read more link incorrectly.
The aria-label looks iffy.

<div class="entry-content wp-block-post-content">
<p> 
<a href="https://s.b/bigram/bigram/sweat-bees/#more-5999" 
class="more-link">
<span aria-label="Continue reading <a href="https://s.b/bigram/bigram/sweat-bees">Sweat Bees</a>&#8220;>(more&hellip;)</span>
</a>
</p>
</div>

On the bigram's home page, archive pages and each singular page that displays a bigram there's a post meta field
that displays how many times the bigram has been seen.
The display is pretty basic

Seen before: n,nnn times

where n,nnn is the internationalised formatted number.

The Genesis-SB theme displays this automatically using the PHP function genesis_sb_seen_before()
For the SB theme I want to display this metadata using a block.

Requirements

Block to display the post meta value field name _seen_before

See also bobbingwide/sb#10

Proposed solution

• Develop a Gutenberg block to display the post meta field.
• See https://developer.wordpress.org/block-editor/how-to-guides/metabox/meta-block-1-intro/
• See https://developer.wordpress.org/block-editor/how-to-guides/metabox/meta-block-2-register-meta/
• etc
• Use register_post_meta to make the field accessible using the REST API
• The solution can be used as a prototype for a generic field block.

The block name will be bigram/seen-before
Since the value is supposed to be auto-incremented the post meta data doesn't need to be updateable.
But we may as well write the code to allow it to be updated as this will be necessary for other fields.

When I created a gallery with both captions and alt text an SB in the alt text was converted to a link. This caused formatting problems in the front end.

https://seriouslybonkers.com/bigram/stupidly-brilliant/

<figure class="wp-block-image size-medium"><img loading="lazy" decoding="async" width="400" height="400" data-id="7438" src="https://seriouslybonkers.com/wp-content/uploads/2024/03/20240221-165908-s-b-400x400.png" alt="Stupidly brilliant - <a href="https://seriouslybonkers.com/bigram/stippled-brush">stippled brush</a>&#8221; class=&#8221;wp-image-7438&#8243; srcset=&#8221;https://seriouslybonkers.com/wp-content/uploads/2024/03/20240221-165908-s-b-400&#215;400.png 400w, https://seriouslybonkers.com/wp-content/uploads/2024/03/20240221-165908-s-b-150&#215;150.png 150w, https://seriouslybonkers.com/wp-content/uploads/2024/03/20240221-165908-s-b-768&#215;768.png 768w, https://seriouslybonkers.com/wp-content/uploads/2024/03/20240221-165908-s-b.png 1024w&#8221; sizes=&#8221;(max-width: 400px) 100vw, 400px&#8221; /><figcaption class="wp-element-caption">Stippled brush</figcaption></figure>
</figure>

Workaround

remove the SB from the alt text

On the Home and Archive pages the (Edit) link that is displayed following the Last updated field does not appear to operate as a link.
Noted on iPad in landscape mode, it doesn't work in Safari but does in Chrome.

In Genesis-SB the Seen before: field is displayed by genesis_sb_seen_before()

function genesis_sb_seen_before() {
	$seen_before = genesis_sb_increment_seen_before();
	echo '<div class="seen-before">';
	_e( 'Seen before: ', 'genesis-SB' );
	echo '</span>';
	echo '<span class="seen-before-value">';
	
	$times = _n( '%1$s time', '%1$s times', $seen_before, "genesis-SB" );
	printf( $times, number_format_i18n( $seen_before ) ); 
	echo '</div>';
}

This code automatically increments the value before displaying it.

Requirements

• To display Seen before: n,nnn times.
• Where n,nnn is a nicely formatted number
• To autoincrement nnnn each time the post is "viewed"

Proposed solution

For the replacement Full Site Editing theme SB: Second Byte

• I need to display the field using a [bw_fields _seen_before] shortcode or an equivalent Gutenberg block.
• In order to use [bw_fields] I need to change the field's definition from '#theme' => false to '#theme' => true.
• Probably don't worry about having to do Seen before: 1 time or Seen before: 0 times.
• Find a way to autoincrement the value while allowing the block to be used more than once on a page.

This issue is to change the field definition.

The first pass routine(s) developed for #2 will need to be extended to allow images to be attached from whatever folder they happen to be in. It should also be possible to enter free form body text.

Proposed solution

The bigram plugin should implement the 'run_bigram.php' action, invoking a routine to create the bigram and associated attachment.

It would be nice if the routine could

• Detect and ignore exact duplicate images
• Support the entry of free form text for the body
• Operate locally and remotely... possibly using the REST API
• Ensure the images are the right way round - WordPress is pretty useless at doing what my PC seems to be able to do.
• Automatically detect screen captures and categorize them as "Surf Bite" rather than "Seen by"

The solution will need a theme specially built for the purpose.

I just took a photo on my iPhone and uploaded it to bigram.co.uk but it didn't appear immediately. It turns out that it is Scheduled. The photo was taken at 11:56 so that's the time used to create both the attachment and the bigram CPT.

What needs to be done to ensure it gets published immediately?
In Settings > General the timezone is shown as
Universal time (GMT) is 2017-06-22 11:15:59
which is behind the time of the photo.

Workaround

Just wait a while before uploading photos.

Proposed solution

Either, adjust the publication time so that it's no greater than the current time
OR detect that it's BST and subtract an hour from the image time.
OR a combination of the above.

bigrams and their taxonomies should be REST enabled so that we can use the block editor with them. Currently on https://seriouslybonkers.com bigrams show up with the classic editor. Find out why this is so, even when the CPT is marked as Show in Rest.

If we had an export CSV file of bigrams then we could satisfy some requirements.

Requirements

• Sort by bigram length
• Sort by S-word bytes, B-word bytes
• Sort by - Seen before
• Primary category
• Attached image
• Day / month created
• Reconciliation merging
• Finding anomalies with current entries

Proposed solution

• oik-batch or WP-CLI implementation
• virtual fields for admin page

Changes to WooCommerce in v8.0.0 mean that the bigram_pre_get_posts() action hook is being invoked before the main query has been run. The call to is_category() produces a Doing it wrong error.
See bobbingwide/bobbingwide#101 (comment)

Proposed fix

Use $query->is_category() instead of is_category()

See bobbingwide/sb#39

When a user performs a search with words starting S and B, both words exist but the exact result is not returned then we should create a new bigram with a category of Searched Before

Similarly, when we display a 404 page - this could create a Seen Before.

When a post is an exact match for a search then the number of times it's been searched for should be displayed.

The SB list ( https://github.com/bobbingwide/bigram/blob/master/admin/SB.txt ) was originally created using first letter capitalisation. This allowed for proper names.

In the current website(s) implementation

• some of the S-words and B-words are capitalised,
• others are all lower case
• and some appear to vary.

It depends on where they're used and how they're created.
We need to standardise the capitalisation of the first letters based on how they're used.

Requirements

Here we'll use examples with S-word B-word as the two words.

Where the logic should apply

• Sampled bigrams should be first letter capitalised automatically.
• Submitted bigrams should

When visiting the site bigram.co.uk I often just type the S and B word in the URL.
It would be nice if this could be detected and converted into the most appropriate request.
How do we know when it's a post or page and when it's a bigram?

Background

The permalink for bigrams is currently "/bigram/"
If we change it so that it doesn't have a prefix what will happen when
a user enters an URL like: https://bigram.co.uk/s-word b-word ?
Currently we get a 404 Not Found.

When the request is being parsed we get an opportunity to filter the values. If we see a request for a bigram with spaces we can convert the spaces ( %20 ) to hyphens.

If there are

• two words in the request
• and the first is an S-word
• and the second a B-word
• and the post type's not specified or is already bigram

we can change the request to be /bigram/s-word-b-word
Then there's more chance of finding the bigram.

A recent WordPress core update announced that uploaded images would be correctly rotated.
This didn't happen when I uploaded Santorini Bike from my iPad.
Investigate why not.

Using Jetpack’s publicise method a new bigram created using the Submit bigram page only has a two word title. We need to be able to enhance the message with more words.

Two options.

1. Don’t publicise on first publication.
2. Add a field for the excerpt / meta description / publicise message.

The Submit Bigram page used the [bw_new] shortcode to create a new post with the title of the bigram.
It doesn't check for an existing post.
When an image is being uploaded and the bigram was in the original SB list, or has been sampled or seen before then it makes sense to check if the bigram already exists. If it doesn't have a featured image then, rather than create a new one, we can reuse that post.

Requirements

• Ability to update an existing post using [bw_new] or similar.
• Merge post content from the original and new posts.
• Set the featured image on the original post.
• Don't actually create a new post.

In the SB theme we need to display some additional Search Banter on the search results page.
For details of what the block needs to display see the Search results section in bobbingwide/sb#24

Proposed solution

• Implement a server side rendered block called bigram/search-banter.
• The code used in genesis-SB needs to be copied and cobbled to provide the banter when the main query is a search.

Implementation notes

• The bigram plugin will need to be changed to a multiple entry point plugin - similar to oik - see bobbingwide/oik#202
• I understand the latest version of the wp-scripts routine already supports this.
• It would be good to try updating bigram to the latest build before adding the new block.

In bobbingwide/genesis-SB#2 we outline a single page view for selecting and displaying SB bigrams.

The component parts of the solution are expected to consist of:

• https://github.com/bobbingwide/react-SB for the front-end UI stuff
• REST API v2 to provide the data
• Custom taxonomies for the UI to request

Proposed solution

• two new tags for the bigram post type ( s-letter and b-letter )
• logic to automatically set s-letter and b-letter when creating / updating a bigram
• bigram should provide a batch process for initially setting the new tags ( s-letter and b-letter)
• the batch process will use functions developed for bobbingwide/oik-a2z#1
• bigram should register its custom post types and taxonomies with 'show_in_rest' true.

When creating a new SB bigram we often use other SB bigrams in the definition. e.g. Sam's Bar Sourdough Burger. Each of these SB bigrams (we'll call them SB's from now on) needs its own entry.

It would be nice if

1. SB's are automatically created when the content is saved
2. On display they are converted into complex pragmatic links

Part of the logic may need to be developed in the theme.

On my PC I can use batch processing to create a new bigram.
The process is still a little long winded though.

1. Change directory to the folder containing the image to upload.
2. Edit the image that contains the SB bigram
3. Rename the file to "S-word B-word.ext"
4. Invoke oikwp from the bigram plugin folder to run bigram_run_bigram() passing the file name and a short description and the directory for the image. This is made a little easier using the sb.bat file.

@echo off
rem (C) Copyright Bobbing Wide 2016
setlocal
set cd=%CD%
cd \apache\htdocs\bigram\wp-content\plugins\bigram
oikwp bigram.php %* dir="%cd%"
endlocal

Requirement

I want to be able to create new bigrams from screen captures on my iPhone / iPad, using a simple upload method directly into the site.

• The uploaded image file should become "S-word B-word.ext"
• The Category should be selectable.
• The title should be determined from the S-word and B-word
• The S-word and B-word need to be sanitized bravely
• Preferably the bigram should be dated when the image was created

Proposed solution

• Develop oik-media plugin with 'media' type field and file upload capability
• Extend [bw_new] to allow for uploading files
• Extend [bw_new] to allow additional validation & processing before the content is created
• Extend [bw_new] to support immediate publication of a post when the user is logged in with required capability
• Extend [bw_new] to support redisplay of the form for logged in users.
• Implement action hooks and filters in bigram to perform all the necessary processing to rename the media file after upload and attach it to the matching SB bigram
• Automate the setting of SEO post meta data
• Set the new bigram date based on the original date time of the image.

Update code to run without problems in PHP 8.1 and 8.2

See bobbingwide/bobbingwide#103

While investigating bobbingwide/oik-fields/issues/24 I created a new version of the site under WPMS. There I noticed a number of problems associated with the value being set for _wp_attached_file. Whereas single site appeared to work with fully qualified values, WPMS baulked.

The attachment file, being created by wp_insert_attachment(), was being passed $file_return['url'] from wp_handle_upload(). The value being stored therefore contained http: or https: and all the rest of the path to the file.
This was causing a problem on the subsequent file display, leading to 500 internal server errors.
The value that should be stored in _wp_attached_file is the relative path under the uploads directory for the site. e.g. 2017/05/s-b-n.jpg. Note: No preceeding slash; indicating a relative file name.

We can't simply use the file name first thought of, since this may be a duplicate name. Therefore we do need the unique file name, generated in wp_handle_upload, but we have to strip the basedir part of the file name, returned from wp_upload_dir(), plus the following '/' to create the value to store in _wp_attached_file.

I sometimes see SB's when using my iPhone / iPad and take a quick screen capture. I've decided that these should be classified as Surf Bite. It should be possible to automatically detect screen captures based on information in the EXIF data.

Proposed solution

tbc

Aside

Maybe there should also be Selfie Bomb... just because some selfies have the same image dimensions as screen captures.

Sometimes several bigrams are created on submission. The code should not allow the same bigram to be submitted twice in a row. I suspect it's not properly checking for an upload file.

• The original file (SB.txt) contained 1425 entries.
• The sanitized version contains slightly fewer - duplicates remove.
• We need to create a 'bigram' post type for each of these entries.
• Some of these may get attachments added in the future.
• Each bigram can have many attachments with the same name.
• It shouldn't be necessary to create a bigram if we only have a picture.

bigram's blocks are currently built with wp-scripts 23.6.0
Update to latest version 26.16.0

There's something very wrong with the logic that detects SB's in content and converts them into a link.

In this example the content was

<!-- wp:paragraph -->
<p>All I asked for was </p>
<!-- /wp:paragraph -->

<!-- wp:group {"style":{"spacing":{"padding":{"top":"var:preset|spacing|20","bottom":"var:preset|spacing|20","left":"var:preset|spacing|20","right":"var:preset|spacing|20"}},"border":{"width":"1px","color":"#eeeeee","radius":"12px"}},"layout":{"type":"constrained"}} -->
<div class="wp-block-group has-border-color" style="border-color:#eeeeee;border-width:1px;border-radius:12px;padding-top:var(--wp--preset--spacing--20);padding-right:var(--wp--preset--spacing--20);padding-bottom:var(--wp--preset--spacing--20);padding-left:var(--wp--preset--spacing--20)"><!-- wp:paragraph -->
<p>Santa's belt.</p>
<!-- /wp:paragraph --></div>
<!-- /wp:group -->

Workaround

Insert a space before Santa's

For the SB theme the page-sb.html template will need to invoke the react-SB JavaScript to display the React page which displays the SB's using the REST API.

Proposed implementation

• Develop a new block bigram/reactsb.
• This will be a dynamic block, server side rendered
• Since this block is only ever used in a hand cranked page template there's no need to write any code for the block editor.
• The block only needs to be registered in the server code