When a noderef field is both #multiple and #optional and 'None' is selected then the value stored in postmeta is 0. As this is not a valid post ID it should not be included in the list of posts processed by bw_theme_field_noderef.

The bw_field shortcode can be used to display certain types of content which may contain shortcodes. If so desired, the shortcodes should be expanded.

e.g. when [bw_field no_title] is used in the title of a post and then the title is displayed in the content, we would want the shortcode to be expanded so that it's not displayed.

the [bw_related] shortcode enables you to list content that is related to something. It supports meta_key=. where the . is a placeholder. This enables you to list things in the future or in the past. The output can be formatted either as a list or using the logic for bw_pages. It would also be nice if the content could be formatted using bw_table logic,

If the fields associated with a post type are just taxonomies then an empty Fields metabox is displayed. Is this truly necessary?

Example: bigram post type on http://bigram.co.uk

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

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

It would also be nice to

• make it available on WordPress.org
• provide functions in shared libraries
• which can be used by oik-types
• and other plugins

In the docblock for bw_field() there's the following TO DO, with a partial answer.

resolve quandary – when the field names are specified are we allowed to override the #theme setting? ie. Ignore #theme => false ?
Answer: For "taxonomy" type fields the #theme setting may not be defined. BUT these fields have to be specified separately anyway.

On the bigram.co.uk website, logged in users can create a new bigram using the Submit bigram page. This uses the [bw_new] shortcode, with extension logic provided by the bigram plugin.

When using an https connection and Chrome on my iPhone I get "This site can't be reached" domain is currently unreachable ERR_CONNECTION_FAILED. This problem does not occur on my Windows laptop nor iPad.

With Safari, I get "Safari cannot open the page because it could not connect to the server".

When the user has the required capability ( e.g. "publish_pages" ) then they should be allowed to publish content directly with [bw_new].

In this situation

• the post can be published directly
• it is not necessary to notify the author of the post that contains the form
• the form may be redisplayed so that another submission may be made

One assumes that the user is logged in, otherwise current_user_can() is unlikely to return true for "publish_pages".

While testing the noderef field using Gutenberg I noted that a title less post in a noderef field would appear to be automatically selected.

The choice of editor isn't relevant to the problem; it's just what I was using when I noted the problem.

When a form includes an upload file then the tag requires enctype=multipart/form-data.
The [bw_new] shortcode needs to set this when the format of the fields in the form require a file upload.

See also:

• bobbingwide/oik-media#1
• bobbingwide/oik#34

For bigrams I want to be able to update existing entries if one already exists but doesn't have an attached featured image.
See bobbingwide/bigram#28

Requirement

• Ability to update an existing post with the given title
• Ability for plugins to determine the post's new field values

Solution

• Extend the [bw_new] shortcode to check if the post already exists and offer an update capability.
• Implement a filter called bw_new_pre_update_post to enable a plugin to indicate whether or not it's happy for the update to proceed and for the plugin to set the new value for post_content, etc.
• It's the plugin's responsibility to applying the changes to the post's fields.
• If the filter returns null then don't update the existing post.
• The logic will only apply for logged in users who can "publish" a new post immediately. ie when the post_status is "publish".

The bw_register_field() API is used in conjunction with the 'bw_register_field_for_object_type()' API to map a field to a post type.

Currently it uses a global called $bw_mapping which contains two two-dimensional associative arrays. This array is used by functions such as bw_effort_meta_boxes(),
bw_effort_save_postdata(), and bw_get_field_names() to automatically handle post data associated with a post.

options fields, be they simple, serialized or serialized arrays are also 'fields'. It shouldn't matter what they're associated with; posts, users, options or taxonomies.

Requirement

Extend the API to allow fields to be associated with users, options and taxonomies.

See also /issues/1

To avoid getting Notice: Array to string conversion messages, _bw_theme_field_default should be able to handle arrays.

The Notices, produced when _bw_theme_field_default does not receive a scalar value, can be avoided by using logic similar to that in bw_option_unserialized_array() from oik-bob-bing-wide.

Using oik-types it is possible to define a taxonomy which has already been registered.
It can then be related to a post type
and then displayed using the [bw_fields] or [bw_field] shortcode, specifying the specific taxonomies to be displayed.

Currently it's not possible to use [bw_field] without any parameters to display the taxonomy fields.
I have a need for this in WP-a2z.

bw_theme_field_URL currently includes the whole URL in the link text. It would be nicer if the scheme ( e.g. http://, https:// ) were not included.

The googlemap virtual field uses Google Maps JavaScript to display a Map.
It doesn't work in the Fields meta box displayed in the new block editor.

Expected output - Classic editor

When displayed using the Classic editor the Google Maps Map is correctly displayed

Actual output - Block editor

When the field is displayed in a meta box controlled by the new block editor the field is not displayed.
The following message appears in the console log

post.php?post=962&action=edit:505 Uncaught ReferenceError: google is not defined
    at initialize1 (post.php?post=962&action=edit:505)
initialize1 @ post.php?post=962&action=edit:505
load (async)
(anonymous) @ post.php?post=962&action=edit:505

Explanation

The bw_fields_get_google_map function uses the Google Maps logic developed for the [bw_show_googlemap] shortcode.

oik_require( "shortcodes/oik-googlemap.php" );
$google_map = bw_googlemap_v3( get_the_title( $ID )
							, $lat
							, $long
							, $post_code
							, "100%"
							, "400px"
							);

The block editor expands the content during REST API processing. This causes the logic to increment a counter which is used to determine whether or not the Google initialisation code is required.
We need to ensure that the meta box enqueues the script.

Proposed solution

Insert the following line between the oik_require and bw_googlemap_v3 calls.

bw_gmap_map( null );

Update code to run without problems in PHP 8.1 and 8.2

See bobbingwide/bobbingwide#103

Requirement

• Support display of the author_name for a post using a block.

Solution

• Add a new virtual field author_name
• Implement the callback function bw_fields_get_author_name() using get_the_author()

Note: It's also possible to use the core/post-author block, with the settings adjusted to not display the Avatar or Bio
and the "Byline" set as required for the label, if needed.

See bobbingwide/oik-blocks#45 and bobbingwide/sb-field-block#5

A translatable field is one which will get passed through the WordPress translation functions.
Input will be in US English. It will be translated to other languages when displayed. The text domain will need to be specified.

The intention is that this field will be used by the theme to create labels for titles in the reader's chosen language.

Proposed solution

Add an optional arg to text fields: #translatable => text_domain

In _bw_show_new_post_form_oik() the wrong number of parameters are passed to wp_nonce_field() leading to the field being included twice in the page. Need to add , false.

There is a limit to how many posts can be loaded when populating the select list for a noderef field. When there are thousands of nodes the #options array becomes quite unwieldly.
Also there is a distinct possibility that the server runs out of memory.

When editing an oik_hook post type ( part of the oik-shortcodes plugin ), the Fields metabox fails to display due to.

Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 16781312 bytes) in C:\apache\htdocs\wporg\wp-includes\functions.php on line 3464

This is because there are over 16K posts with post type of oik_api.

Ditto for any other post type that attempts to display a select field for a noderef of post type oik_api

Workaround

Exclude the fields from the Fields meta box by not registering it's association to the post type.

Proposed solution

Implement a select2 like field or another solution that works with mega data.

The [bw_fields] shortcode with no parameters displays the labels and values for all the fields regardless of their value.
This can display a lot of labels with no values.
It would be nice to have an option to not display the label or field if the field value is null

Proposed solution

• Support a parameter on the field definition to avoid display for null values
• Support a parameter on the shortcode to override the field definition

While investigating bobbingwide/fizzie/issues/28 I developed a fix for using the [bw_fields] shortcode to display the fields for the current post in an archive display.
If the id attribute value passed to the shortcode is . then the current post ID is used.
This overrides the is_single() checking that I'd implemented 5 years ago.

The code change was to add the last 3 lines in this extract:

function bw_metadata( $atts=null, $content=null, $tag=null ) {
	if ( !oik_is_shortcode_expansion_necessary() ) {
		return "Not today thank you.";
	}
  $post_id = bw_array_get( $atts, "id", null );
	if ( '.' === $post_id ) {
		$post_id = bw_current_post_id();
	}

I then found an alternative solution; use [bw_field] instead of [bw_fields].
I could use this because I did not need the field's prefix.

Requirement

Consider adding this as a possible solution to the second @todo for the bw_metadata function

@TODO decide best way to deal with nested usage of this shortcode or multiple usage of this shortcode
 * when the post we're trying to process is different from the main post. 
 * This happens when we are combining information from multiple posts into one output. 
 * Current solution is to not produce anything, not even 'Not single'

The [bw_fields featured] shortcode displays the featured image. If this has already been displayed, by the theme, then it gets shown twice. It would be nice if the shortcode could somehow be aware of the fact that the featured image has already been displayed and disable itself.

We need to analyse the situations where the shortcode is used and choose the most appropriate method of enabling / disabling the logic.

Implementation options

The Genesis theme framework sets options for archive displays. If the archive displays excerpts then it can also display featured images. If that option is chosen then the logic to display the featured field can be disabled by setting #theme = false.

When the "googlemap" virtual field is displayed with lat or long set to null then an Uncaught SyntaxError message is produced in the browser.

This was originally reported as bobbingwide/oik/issues/44

Proposed solution

Only call bw_googlemap_v3() if both $lat and $long are numeric.
See also #2

Shortcodes such as [bw_related] can be used to list items in the future and in the past but cannot be used for a date range, except by artificially limiting the number of items shown.
We need to be able to perform comparisons using between a and b.

When a new post is created using [bw_new], taxonomies associated with the post type can be displayed in the form if the relationship has been defined using bw_register_field_for_object_type().

But there is no logic to automatically call wp_set_post_terms() for the taxonomy fields.

Requirements

• Allow display of input fields for taxonomies
• Allow automatic setting of taxonomy terms
• In admin pages, do not display the taxonomies as part of the Fields meta box

specifically for bigram.co.uk

• Display the categories in a drop down list
• Do not allow creation of new terms for 'categories'

Some post meta data is stored as serialized arrays.

It should be possible to display the serialized array using [bw_field] / [bw_fields]

It should also be possible to edit the serialised array, including nested fields.

When viewing Plugins -> Updates Available, attempting to update oik-fields can lead to an Update failed message. oik-fields is delivered from the oik-plugins server.
It is however possible to update to update other oik plugins such as oik-sc-help.
This worked from handmadestudios.org on 2018/01/10 at 10ish.

In oik-plugins.com, for the Required version and Compatible up to taxonomies, which are categories, I used to define all the supported versions.
Now I just want there to be one term, the highest.

Should I change oik-fields to display just the last term, or does it make more sense to remove the unwanted terms.... in a batch routine for oik-plugins and oik-themes?

Answer: the batch routine appears to be the most sensible solution.

Deprecated: Function get_page_by_title is deprecated since version 6.2.0! Use WP_Query instead. in /home/customer/www/seriouslybonkers.com/public_html/wp-includes/functions.php on line 5413.

This message was issued when using https://seriouslybonkers.com/submit-bigram/

Add logic to support display of a Google Map, implemented as a virtual field.

Proposed solution

The Google map will be displayed if the current post has values for the following post meta fields: _post_code, _lat, _long

It will use the logic in the oik shortcode [bw_show_googlemap]

The select field type supports single or multiple select. Currently when displaying a multiple select field using the [bw_field(s)] shortcode the display is incorrect. It's only displaying the first value from the array.

It needs to cater for the fact that the value passed is actually an array and each value needs to be converted to the display version.

The fields should be displayed as comma separated values, similar to the display for taxonomies.

Proposed solution

Change bw_return_field_select() to check for $args #multiple and process accordingly.

Also update the documentation. For the current documentation on the select field see

http://www.oik-plugins.com/wordpress-plugins-from-oik-plugins/free-oik-plugins/oik-fields-custom-fields-plugin/oik-fields-field-types/select-field-type/

Since early 2017 a new Block 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.

Over time, more content will be created using the Block editor than the Classic editor.
The new solution needs to be backward compatible with our existing solution, so there shouldn’t be a need to change anything and it should still work. But that has not yet proven to be the case.
Also, over time, more content will be created/edited using the Block editor than the Classic editor.
We need to embrace the improvements.

So, rather than being compatible with Gutenberg we need to be Gutenberg aware.

For oik-fields there are two areas.

1. Fields which rely on JavaScript to be displayed in meta boxes
2. Fields which will need to be accessible in the Block editor through the REST API.

Non functional requirements

• The solutions implemented for oik-types and oik-fields should be logically consistent.
• Where possible the code should use shared library logic
• New code should be tested
• Code should be internationalised and localized
• It should not cause Notices or Warnings, even when WP_DEBUG is true
• Backward compatibility with WordPress 4.9.x as a minimum
• Tested with PHP 7.1 and 7.2

Oik v3.2.0 was intended to be 100% internationalised on wordpress.org. But there were some .inc files which were not processed by makepot so not all strings were presented for translation in GlotPress. Fixing this issue means moving the active logic from .inc to .php files. There are situations where this can cause problems for oik-fields.

An updated version of oik-fields would have to check which version of oik it's using.
To avoid Fatal errors when oik is back level, the code will need to determine the active version of oik and continue to load the .inc files for oik v3.2.0 or earlier.

e.g.

if ( oik_fields_check_oik_version() ) {
  oik_require( "includes/bw_register.php" );
  oik_require( "includes/bw_metadata.php" );
} else {
  oik_require( "includes/bw_register.inc" ); // Yes, we know it's deprecated
  oik_require( "bw_metadata.inc" ); // Yes, we know it's deprecated
}

Also, since includes/oik-contact-form-email.inc is only used by oik and oik-fields, and oik-fields only uses it in the [bw_new] shortcode there is little point in producing a deprecated version of the file. We just need to update both plugins, in either order we choose.

WordPress provides functions such as wp_list_categories() which provides counts of the total number of items in a particular taxonomy by category term. I need to be able to summarise the number of posts with a particular value. e.g. For the custom post type "competitor" there is a taxonomy of playing status. I want to be able to display the total number of competitors for an event by status.
e.g. Yes 19, No 3, TBC 4

Proposed solution

Develop a new shortcode called [bw_group] that will display the results of the query, summarising by the possible or discovered values depending on the grouping field's field type.

e.g.
[bw_group post_type='competitor' meta_key=_event meta_value=123 field='playing_status']

The [bw_fields] shortcode displays each field using HTML like this:

<div class="bw_metadata _field_name">
<span class="label _field_name">Field title</span>
<span class="sep">: </span>
<span class="value">value(s) for the field
</span> 
</div>

The [bw_field] shortcode displays each field without the label or sep, using HTML like this:

<span class="value">value(s) for the field
</span>

I'm migrating a site from one theme to a new one and have found that there are 12 different page templates which are used to display the content. I want to be able to summarise the current status of the template selected for each page.

Proposed solution

Add a new virtual field called template which can be displayed using the [bw_table] shortcode or [bw_field template] on the page.