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 its association to the post type.

Proposed solution

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

Note: The logic to load a noderef field's values ( bw_load_noderef2() ) is actually part of the oik plugin.

I've had a report from someone installing oik-privacy-policy v1.3.2.
When he installed oik v3.0.2 the following message was displayed in the dashboard.

"Plugin could not be activated because it triggered a fatal error. Fatal error: Call to undefined function bw_trace2() in /home1/web2guy/public_html/projectmenudashboard/wp-content/plugins/oik/libs/oik_boot.php on line 190"

The following code in oik_box() produces a Warning message when the $callback parameter is a class method and the $id parameter is null.

if ( $id == NULL ) {
    $id = $callback;
  } 

Workaround

Note: The original code wasn't designed with OO in mind.
Passing a non-null value for $id when using OO code avoids the issue.

Preferred solution

Detect that the $callback is an array and choose the $id accordingly.

The oik base plugin was developed in the UK English language using smart APIs that defer processing until the content is really needed. In some cases translation of language strings is deferred.

In order to create the .pot file we've been using a fork of the WordPress tool that searches for translatable strings and have extended it to handle a super set of APIs.

The WordPress translation tool used at https://translate.wordpress.org/projects/wp-plugins/oik
does not recognise these APIs. Therefore the set of strings to be translated is only a small subset of the actual set.

Two options

1. Change oik to use the WordPress APIs
2. Improve the makepot logic to support additional APIs depending on plugin/theme.

Each of these options have their Pros and Cons.
We'll not discuss these now other than for me to say that my preference is for option 2.
I'm just raising this as an Issue to be resolved.

It's already been done for "oik_plugins", we now need to make admin/oik-themes.inc into a shared library called "oik_themes". This is needed by oik-shortcodes for the _component_version virtual field, where the object being displayed is part of a theme.

Some fields stored in post meta data may contain a lot of data.
Either there are multiple values, each stored separately in a wp_postmeta row, or the data is stored in a textarea field, with each line representing separately displayable content.

The values should be paginatable, ideally with pagination being ajaxified.

For these large fields, it makes sense to add pagination to the [bw_field] / [bw_fields] shortcodes.
Alternatively, the [bw_navi] shortcode could be extended to support selection of the field to be displayed, using a new field=field_name parameter.

Proposed solution

Develop the extension to [bw_navi] first.

Some content may contain output from shortcodes that should not be cached.
It would be nice if we could easily advise caching plugins when this happens.

Requirements

• Ensure that caching does not adversely affect the user experience
• Support popular caching plugins: WP-Super-Cache, w3-super-cache

Proposed solution

tbd

Note: Wordfence no longer supports caching.

I noticed a problem where oik-types was unable to override the definition of post type supports definitions added by the Genesis theme framework. These were also being added in response to 'init' at priority 11, but since the theme is loaded after the plugin Genesis's hook was overriding oik-types' settings.

Solution:

In the oik base plugin, increase the priority for handling the 'init' action, to 20, from 11.

WordPress options data can be stored in multiple ways; plain, serialized, serialized arrays.

When the data is stored as serialized or serialized arrays then the core admin logic simply shows 'serialized data'., Obviously you can't edit data like this.

There are many cases where data benefits from being stored in the wp_options table as serialized data. Often the data is almost self defining.
Each entry has a key and each field has a label and value. Given the label name and the context it should be possible to determine the field type and user friendly label for the field.
It should therefore be possible to provide admin pages which deal with serialized options data.

The oik base plugin, and quite a few of the plugins which are dependent upon it, uses serialized arrays for options data. Users would greatly benefit from a consistent admin UI managed by common code.
Therefore we propose to develop a new BW_Options_List_Table class that extends the BW_List_Table class to provide a admin UI for options fields.

The oik base plugin defers shortcode registration until it's determined that they're needed.
It uses the oik_add_shortcodes action hook to initiate the logic to register shortcodes.
Plugins that respond to this action hook then invoke bw_add_shortcode().
This function currently registers every shortcode, regardless of whether or not the shortcode is going to be used.
If you only want to use one or two shortcodes at the most then the performance of subsequent processing during shortcode expansion can be slightly degraded.
We need a simple solution that will allow the shortcode registration to be overridden.

Proposed solution

Add a filter ( 'oik_add_shortcode' ) to determine the function to register. If the filter returns null then the shortcode will not be registered.
This hook will not necessarily be implemented by the oik base plugin.

For a variety of reasons there may be some plugins for which you neither want updates to be checked nor applied. Some of these reasons are:

1. You need to stick with a particular version until another version has been updated
2. The plugin is installed as a symlinked version

The requirement is to support the disabling of plugin updates on a plugin by plugin basis.

In the latest version, the output of the [bw_show_googlemap] shortcode is messing up google maps controls - particularly the zoom slider. This seems to happen regardless of the theme.
The problem is almost exactly as documented here
http://stackoverflow.com/questions/9904379/google-map-zoom-controls-not-displaying-correctly
In a previous version a fix had been provided in oik-css.
The problem was introduced when I added support for multiple googlemaps.
The fix adds a new class ( bw_map_canvas)
which is then styled by the CSS.
.bw_map_canvas { height: 100%; min-height: 100% } .bw_map_canvas img { max-width: none; }

The bw_form() API is used to create an HTML form tag. We need to extend it, and the form() API, to allow the enctype parameter to be set to multipart/form-data when the form contains a file upload field.

See also

• bobbingwide/oik-media#1
• bobbingwide/oik-fields#14

We want to be able to display the current setting of the PHP memory_limit using the shortcode [wp v p m]. The bw_wp() function, that implements the wp shortcode, is delivered by oik.

This is a pre-requisite change to support bobbingwide/oik-bob-bing-wide#8

Suggestion for the future

One day migrate all the logic for the wp shortcode to oik-bob-bing-wide, or use shared libraries?

There are 3 requirements

• the bw_logo shortcode should use the site_icon image if the option is not set
• if the bw_logo is selected for the Login form this should also use the site_icon.
• Optionally, in WPMS, use the value for the default site, if none is specified for the current site.

Improve the contact form so that the Subject: field is either pre-defined or selectable or otherwise.

For some contact forms we really only need the message.
By default the email produced by the bw_contact_form already shows the page from which the form was submitted but it makes it easier for the user to select.

Optionally we could make use of existing contact form plugins or even the theme's contact form.

In WPMS, although the [bw_logo] shortcode finds the correct image to display as the logo image, using a link='/' parameter does not produce a link to the currently active site.

So if used in the content of the [bw_blogs] shortcode, as below, all the links are to the current site.

[bw_blogs]
[bw_logo link='/'] 
[/bw_blogs]

Proposed solution

It would be nice to support WPMS so that the links are to the "bw_domain" registered for the site.

_bw_get_plugin_version() should check if the plugin file exists before calling get_plugin_data() to avoid warning messages from get_plugin_data().

Similar to a #29, the [bw_domain] shortcode should obtain the domain ( excluding scheme ) when the oik options domain field is not set.

This is for the WP-a2z Sitemap page.

Need to correct the spelling of "internal" from "interal" in a comment in jquery.countdown.js

Discovered when I raised https://core.trac.wordpress.org/ticket/36548

Imagine this scenario.

• Some content contains a [bw_link ID] shortcode, where ID is the post ID of a registered post type.
• Clicking on the link displays the post.
• The post type is then de-registered

How should the link now appear?

Actual Result

It displays an invalid permalink conforming to the custom structure defined in Permalink Settings.

e.g. for post ID 32932, published on 2016/05/25, with slug 'reactjs', using the Day and name permalink structure we get http://example.com/2016/05/25/reactjs/

Clicking on the link displays the 404 page.

Expected result

Good question. Help wanted here.
See also humanmade/WordPress-Importer#38 (comment)

Notes about current implementation

• Currently, when the post ID is NOT found e.g. [bw_link 1010101010101] then no link is shown.
• When the post ID is 0, then it produces a link to the current post.
• When the post ID is negative then no link is shown.

The BW_List_Table class was created to develop the oik-clone pull model. It was built from a copy of WP_List_Table in October 2014, WordPress v4.0

Since BW_List_Table is expected to be used for other functionality in oik / shared library based plugins this needs to be updated.

For oik-ajax we need to be able to cater for shortcode parameters which are stored in the $atts array to be arrays. e.g. meta_query, post__in.

Either oika_flatten_atts() or kv() should convert any array using implode.

For the time being we'll assume that arrays aren't nested.

bw_load_noderef2_flat() uses bw_get_posts() to load a list of posts matching the selected post type.
When the post type is "attachment" and the post_parent is not set then bw_get_posts() will set it to the parent of the current post.

For the [bw_new] shortcode, if we want to select an attached file using a media type field then we need a list of all images, not just those which aren't attached.

One solution to the problem is to trick bw_get_posts() into allowing not setting the value for post_parent. This could be done either by ensuring bw_current_post_id returns null OR
by avoiding the test.

proposed solution

Avoid the test on post_parent by passing an array of post types where the second post type will never return any posts.

If the oik options > options Domain field is not set then for the
[bw_wpadmin] shortcode this should default to the admin_url, for the link
and a simplified version of the web site for the link text.

It should also work for WPMS, with subdirectory or subdomain installs.

When you have a page with multiple paginatable shortcodes and have already paged an earlier shortcode, paginating a shortcode that appears later in the page can cause the pagination of the earlier shortcode to be reset to page 1.

Problem explanation

In bw_navi_paginate_links() the fix introduced for WordPress 4.1.1 ( #13 ) made a permanent change to the value of $_SERVER['REQUEST_URI'], removing the values of the query args for earlier shortcodes. The links for the subsequent shortcodes therefore did not have this query arg, so on the pagination request for a subsequent shortcode the previous shortcodes reset themselves to page 1

Problem solution

Save the value of $_SERVER['REQUEST_URI'] and reset it before leaving the function.

While developing oik-requests I started using textarea fields to store post meta data for information about files loaded, hooks invoked and queries performed. These fields can run to many many lines.
I noticed that in the WordPress edit page, pasting large amounts of data into the textarea fields brought Chrome to a standstill.

Google searches came up with the actual problem https://bugs.chromium.org/p/chromium/issues/detail?id=109587
but they didn't explain the easy workaround, which is to disable spell checking.
See http://stackoverflow.com/questions/254712/disable-spell-checking-on-html-textfields

So now we need a way to add the "spellcheck=false" parameter to selected textarea fields.
The lowest level API that might need changing is iarea(), though we could get away with changing the logic for displaying a sctextarea field using new logic.

As an aside

There are other things that might be good to have for input fields:

<input type="text" placeholder="My Field" name="myfield"
    autocapitalize="off" autocorrect="off" autocomplete="off" />

Some shortcodes accept a parameter which basically contains the same value but has multiple names.
e.g. for the audio shortcode src parameter the aliases are mp3, m4a, ogg, wav, wma.

The oik shortcode syntax logic currently attempts to link to the first parameter name listed, but the shortcode parameter is registered using all the values.

Clicking on a link leads to 404.

Proposed workaround

In bw_form_sc_parm_help(), don't call bw_form_sc_get_first_parm_name()
just assign the value directly.

There are a range of helper functions which are used for displaying the syntax of parameters that are common to many shortcodes. The _sc_classes() function defines

• the 'class' parameter as a set of CSS class names
• the 'id' parameter as a unique identifier.

It's not clear whether the 'id' is a post ID or a CSS ID.
It could be that the ambiguity is acceptable, depending on the context of the shortcode.
We need to check.

While developing tests for #47, I started getting a lot of debug backtrace output in HTML comments.
Having determined that they weren't from the files I originally thought they came from ( which would have indicated a different problem ), I used oik-bwtrace to locate the culprit file.

This turned out to be a deprecated file. ( admin/oik-plugins.inc )

On closer inspection, I realised that even though the file contained

_doing_it_wrong( __FILE__, '<br />Please use oik_require_lib( "oik_plugins" );<br />', "oik v3.0.0" );

this message about the deprecated file wasn't showing in PHPUnit's output.

I need to add some unique identifying mark to the unwanted output.

echo __FILE__;

should do the job.

Like many other plugins and themes the oik base plugin includes logic to allow a plugin or theme to be updated from a repository other than WordPress. For plugins which are a) delivered from an oik-plugins server, and b) already dependent on some part of oik, this logic is enabled through oik_register_plugin_server().

You can also manually enable this logic using http://www.oik-plugins.com/wordpress-plugins-from-oik-plugins/oik-base-plugin/oik-options/oik-options-plugins/oik-options-plugins-add-plugin/

Currently the plugin server has to be running the oik-plugins server logic.

We have a new requirement to be able to update the plugin from a github repository.

Proposed solution

• Allow the "server" to be specified as a github repository e.g. https://github/bobbingwide/bbboing
• The plugin update logic will detect this and direct requests to check for updates from github
• It may have to fetch the .zip file directly from github and perform post processing before the plugin can be successfully installed.

There are multiple stages to this development.

The solution may enable 'local' zip files to be installed, allowing optional/recommended plugins to be delivered as part of another plugin/theme.

As for Twitter, Facebook etc, it would be nice if the [bw_follow_me] shortcode could display a link to the user's GitHub account. All it needs to store is the "owner" part, the rest of the GitHub url can be created.

Whether or not there needs to be a separate shortcode is debatable. If the [github] shortcode exists then we can probably use that? But what happens with the oik-user plugin.

An icon with the GitHub mark will also be needed for 'backward compatibility' when [bw_follow_me] is coded without theme=gener.

oik v2.5.1 should be compatible with oik-bwtrace v2.0.9

Currently, you need a version of oik v3.0.0 in order to be able to run both oik and oik-bwtrace. i.e. oik v2.5 is not compatible with oik-bwtrace v2.0.9.
We want to release a new branch of oik to wordpress.org to deliver a workaround to a problem introduced in WordPress 4.4 ( Issue #13).
We need to apply some changes to make oik compatible with the shared library solution supported by oik-lib, oik-bwtrace and the new version.

In some situations bw_theme_object_property() is not able to load the selected post. To avoid warning message the value of $post should be checked before calling property_exists().

Detected on anchorgolf.com the generated JavaScript produces the Uncaught SyntaxError in the following line generated to display a Google Map.

var latlng = new google.maps.LatLng(,);

Workaround

Enter values for the lat and long.

It would be nice to be able to use [bw_link /#fragment] to provide an on-page link, where fragment is the unique ID to which to link.

When an HTTP request is expecting the response to be in JSON, things can go wrong if the server inadvertently produces PHP Warnings, Notices or other unexpected output.
The oik-clone plugin is rather sensitive to this.
Instead of using json_decode( $result ) we should call bw_json_decode( $result )
This new API will attempt to protect the caller from failing due to unexpected output.
The API will strip off anything before the first { and trace this as a Warning message.

In the first instance the routine will not check for json errors.

Plugins which are currently using the oik-remote.inc file and using json_decode() should be updated to
use bw_json_decode(). Other plugins should wait until the logic is available in a shared library.

Known list of plugins to update

• oik-clone - in oik-save-post.php

In bw_navi_paginate_links() there is code that creates the $args parameter to the paginate_links() function. It currently hardcodes two parameters as "before_page_number" => "[" and "after_page_number" => "]".

This is inconsistent with theme pagination. Should these values be
a. continue to be hardcoded
b. optionally set
c. omitted

In some edge case scenarios it's possible to cause Fatal errors in wp-admin when attempting to activate a plugin for which the folder has been renamed.

This is related to the following WordPress support forum topic.
https://wordpress.org/support/topic/should-update-be-available-for-a-renamed-plugin?replies=1#post-8809638

Steps to reproduce

1. Deactivate the oik-privacy-policy plugin
2. Deactivate the oik plugin
3. Rename the folder for oik-privacy-policy to oik-css
4. Search for, with the intention on installing it, oik-css
5. Find that it appears to be installed and see that you can simply "Activate" it
6. Click on Activate.

Unexpected result

Warning: require_once(C:\apache\htdocs/wp-content/plugins/oik-privacy-policy/admin/oik-privacy-policy.php): failed to open stream: No such file or directory in C:\apache\htdocs\wp-content\plugins\oik\libs\oik_boot.php on line 78

This then becomes an 'unrecoverable' Fatal error. It remains an Unrecoverable error until you rename the folder back to the orginal name at which point you get
The plugin oik-css/oik-privacy-policy.php has been deactivated due to an error: Plugin file does not exist.

It took me a while to notice, but after upgrading to WordPress 4.4, we realised that pagination was not working properly. The x to y of z information and the paging links were correct, but the listed content being displayed was always from page one.

Explanation

The function _bw_get_posts() which is used when we need the total number of posts was passing the default value for offset, 0. It seems that this should now be ''.

Temporary fix

Change the code in _bw_get_posts() from 'offset' => 0 to 'offset' => ''
File oik/includes/bw_posts.inc
This fix has been applied to oik-plugins.com

Permanent fix

Publish a new version of the oik base plugin. Rather than issue v2.5.1 we may decide to officially release version v3.0.0.

The oik-ajax plugin enables pagination of shortcodes via the WordPress AJAX mechanism. In order to support pagination of shortcodes with nested content we need to be able to break the content down into page sized chunks.

Proposed solution

This will require an additional filter oik_shortcode_content which will be applied during bw_shortcode_event(), after oik_shortcode_atts

See also https://github.com/bobbingwide/oik-ajax

Plugins such as justintadlock's registration-honeypot protect the login and registration forms.
We need something that can be used to check [bw_contact_form] and other forms that spambots might try completing
This can probably be achieved by some very simply action hooks, implemented by the oik base plugin.

Proposed solution

• Add oik-honeypot shared library
• Add "oik_add_honeypot" action to allow extension to include the honeypot field in a form
• Add "oik_check_honeypot" action to allow extension to check the honeypot field has not been completed
• Add some defaults for the message to be displayed when the trap has been sprung.
• Change [bw_contact_form] to use the new logic

AND, for the extensions,

• Change oik-squeeze to use the new code in [bw_squeeze]
• Change oik-fields to use the new code in [bw_new]

For paginated ordered lists, it would be nice if we could specify the list start number, rather than having it start from 1. each time.

Proposed solution

• Change sol() to accept the $extra parameter
• Change bw_sl() to pass the start index
• Change bw_navi_posts() to determine the start index when required.

In some instances where textarea fields are being redisplayed by bw_textarea() any backslashes in the content are duplicated. This is seen when the form is being redisplayed, and the value parameter is null, which causes the code to access the current value from $_REQUEST. The value needs to be sanitized before being passed to iarea(). wp_strip_all_tags() already provides a partial solution, but we also need to call stripslashes().

Requirement

Allow [bw_blockquote] to accept $content which includes HTML and/or embedded shortcodes

Solution

bw_blockquote() will first check for $content. If it exists then it will use that in preference to the text parameter, which is used in preference to the positional parameter.

When I first changed [bw_show_googlemap] to use Google maps API v3 it didn't require the API key that was needed in v2. This was in oik v 1.3.

Some time ago Google started displaying Warning messages in the JavaScript console saying.

Google Maps API warning: NoApiKeys https://developers.google.com/maps/documentation/javascript/error-messages#no-api-keys

Google Maps API warning: SensorNotRequired https://developers.google.com/maps/documentation/javascript/error-messages#sensor-not-required

On most of my accounts the Google map is displaying correctly.

On a new 1&1 account however the Google map is displayed briefly before it switches to

Sorry! Something went wrong.
This page didn't load Google Maps correctly. See the JavaScript console for technical details.

Where we see not only the two warnings but also an Error.

Google Maps API error: MissingKeyMapError https://developers.google.com/maps/documentation/javascript/error-messages#missing-key-map-error_.ab @ js?sensor=false&region=GB:32(anonymous function) @ common.js:51(anonymous function) @ common.js:189c @ common.js:45(anonymous function) @ AuthenticationService.Authenticate?1shttp%3A%2F%2Fwww.irenelock.co.uk%2Fcourse_location%2Fbridestow…:1

Workaround

Providing an API key and removing the sensor=false parameter, in a custom version of the code, resolves the problems.

Proposed solution

Add support for specifying the Google maps API key in oik options, reusing the google_maps_api_key option name.

When the path in the [bw_link] shortcode is prefixed with a '/' then the domain is determined to be the local domain. The logic uses the oik option "domain". If that's not set it obtains "siteurl".
The current logic creates a link with two schemes. e.g. http://http://example.com/path
There should only be one. It confuses Chrome.

I was developing a new plugin which handles its own display of a custom column.
During debugging, I registered the field using oik-types
When the column was being shown on a custom post type, bw_custom_column_admin() displayed the value using its own logic.
This was in addition to the custom column being formatted by the new plugin.
bw_custom_column_admin() should have checked that the column was a valid column for the given post type.

Workaround.

Remove the field registration

Background

In September 2015 I started writing up a problem which I had been experiencing for many months. Today ( 2 Nov) I finally published the post.
http://herbmiller.me/2015/11/02/h2gd-part-50-cannot-redeclare-func-previously-declared-in-filexx-in-fileyy/

One of my attempts to fix the seemingly random problems was to attempt to standardize the setting of ABSPATH. There are some situations where ABSPATH is set in shared library files.
This Issue is raised to log the changes to set ABSPATH in oik_boot.php

In a WordPress MultiSite installation, for one of the sites, it's not possible to enable the
Show IDs on admin pages checkbox using oik options > Overview.

I have't debugged it yet, so it could be a problem introduced when importing data directly into the options table.