bobbingwide / oik-types

oik custom content type manager

oik-types

• Contributors: bobbingwide
• Donate link: https://www.oik-plugins.com/oik/oik-donate/
• Tags: custom post types, custom fields, and custom taxonomies UI for oik
• Requires at least: 5.2.0
• Tested up to: 6.4.2
• Stable tag: 2.4.1
• License: GPLv2 or later
• License URI: http://www.gnu.org/licenses/gpl-2.0.html

Description

Create custom post types, fields and taxonomies that are integrated with the oik API to bring the power of oik to your website content.

• Define new custom post types
• Extend existing post types
• Define new custom fields
• Define the fields and taxonomy relationships
• Use WordPress admin to create and manage your content
• Use shortcodes from oik and oik-fields to display the content in ingenious ways

Requires:

• No PHP programming
• A bit of thought
• Some creative flair

For advanced users:

• Write CSS to style your content beautifully. Why not use the oik-css plugin?
• Extend your custom post types with action and hook filters
• Develop your own custom field plugins using the oik APIs

Features:

• Advanced API for plugin developers
• Builds on oik and oik-fields extensible architecture
• Extend pre-existing custom post type plugins that use the oik API
• Select post types to be shown on the home page
• Select post types to be publicized by Jetpack

Shortcodes

oik-types does not define any shortcodes of its own. You simply use the shortcodes from oik and oik-fields

Actions and filter hooks

• action "oik_types_box"
• action "oik_fie_edit_field_options"
• action "oik_fie_edit_field_type_$type"
• filter "oik_query_field_types"

Installation

1. Upload the contents of the oik-types plugin to the `/wp-content/plugins/oik-types' directory
2. Activate the oik-types plugin through the 'Plugins' menu in WordPress

• Note: oik-types is dependent upon the oik base plugin and the oik-fields plugin.

If you don't install and activate the oik-fields plugin then oik-types won't be called to apply changes to the post type registrations.

Frequently Asked Questions

What is this plugin for?

To help you define custom content for your website without having to write any code.

How is the data implemented?

oik-types does not create any tables of its own. It records the information in structured arrays in the wp_options table.

• bw_types contains the manually defined custom post types
• bw_fields contains the manually defined custom fields
• bw_f2ts contains the Fields to Types relationships
• bw_x2ts contains the Taxonomies to Types relationships

Each instance of a custom post type is created in the wp_posts table Each instance of a custom field for a custom post type is created in the wp_postmeta table Each instance of a custom taxonomy is created in the wp_taxonomy and related tables

Do I need to flush permalinks?

Yes. When you first create a new custom post type. If you do not then you will most likely receive a 404 message.

What other field types are there?

The following field types are provided by the plugins listed below:

• msoft - oik-msoft
• rating - oik-rating
• userref - oik-user

What is oik-types dependent upon?

This plugin is dependent upon the oik-fields plugin and the oik base plugin.

Can I get support?

Yes. Through the oik-plugins website or GitHub.

Can this plugin be used with other CPT managers?

Yes, it can. But I wouldn't recommend it.

Can this plugin extend other CPTs?

Yes. You can use it to override the definition of existing (custom) post types. You can add fields but you can't remove them.

Is there an import/export facility?

No... but there could be as it's just a case of exporting the data from wp_options using an "Export/import options plugin."

Screenshots

1. Definition of the oik-fields CPT
2. Three instances of the oik-fields CPT
3. Fields defined by oik-types
4. Fields to types relationships
5. Taxonomies to types relationships

Upgrade Notice

2.4.1

Update for a fix for CPT's which include block templates.

Changelog

2.4.1

• Fixed: Don't convert template array back to stdObject #27
• Changed: Display an excerpt of the template with oik_cpt_post_type_template() #27
• Tested: With WordPress 6.4.2 and WordPress Multisite
• Tested: With PHP 8.0, PHP 8.1, PHP 8.2 and PHP 8.3
• Tested: With PHPUnit 9.6

Further reading

Read more about oik plugins and themes

• oik-plugin
• oik-fields

oik-types's Issues

Support for WordPress 4.6

In WordPress 4.6-RC1 and WordPress 4.6-RC2 ( and most likely the beta versions ), if oik-types has been used to override a custom post type (CPT) and then the plugin that registered the CPT in the first place is deactivated ( or otherwise no longer registers the post type), then the subsequent post type that is registered has a cap property which is an array. Because WordPress now expects this to be an object the following Notices are produced on admin pages.

Notice: Try to get property of non-object in wp-admin\menu.php on line 138
Notice: Trying to get property of non-object in wp-admin\menu.php on line 139
Notice: Trying to get property of non-object in wp-admin\menu.php on line 140
Notice: Trying to get property of non-object in wp-includes\admin-bar.php on line 648

Steps to reproduce

1. Activate Jetpack's Custom Content Types module and enable Portfolio projects
2. In oik-types override the definition of the jetpack-portfolio post type
3. Deactivate Jetpack, the Custom Content Type module, or disable Portfolio projects
4. Visit the Dashboard.

Note: I was using Jetpack 3.8.2. I expect the problem could be recreated using a different plugin that registers any original CPT that is overridden by oik-types.

Workaround

• Delete the oik-types CPT
• Re-enable the initial registration
• Set WP_DEBUG( FALSE )

Proposed solution

What we want to do is find a solution for oik-types that'll work regardless of the WordPress version.

Add order by and posts_per_page for taxonomy archive queries

Similar to the change in 44807de, where we provide archive sort and archive posts per page fields, we now require the ability to control what happens on taxonomy archives such as "letter" and "api_letters".

The whole point of having letter selection is to find the contents quickly, so we need to be able to display quite a few per page.

Automatically support CPTs which are attached to the category taxonomy

For the bigram plugin I associated the bigram CPT with the category taxonomy to enable both bigrams and posts to be displayed in the main query for the category archive.

For the wp-secrets.co.uk website I want to attach the category taxonomy to the oik-plugins CPT for a same reason: to be able to list both plugins and posts associated with a particular category term.

It should be possible to extend oik-types to cater for this automatically for any post type which is associated with the category taxonomy. Similarly, it should also be possible to support the post_tag taxonomy ( Tags ).

How much of CMB2 can oik-types make use of?

oik-types and oik-fields were developed independently of many other plugins that implement very similar functionality? Would it be possible to extend oik-types so that it could be a wrapper to shared functionality delivered by plugins such as WebDevStudio's CMB2 plugin?

Uncaught TypeError: t.map is not a function

Uncaught TypeError: t.map is not a function
    at qo (templates.js:53:18)
    at actions.js:53:13
    at thunk-middleware.js:4:11
    at index.js:24:12
    at promise-middleware.js:20:9
    at Object.dispatch (resolvers-cache-middleware.js:51:10)
    at index.js:202:29
    at index.js:85:4
    at Ug (react-dom.js?ver=18:1:207718)
    at Ag (react-dom.js?ver=18:1:209328)
react-dom.js?ver=18:1 

The above error occurred in one of your React components:

at https://blocks.wp.a2z/wp-content/plugins/gutenberg/build/editor/index.min.js?ver=96588d786d072613d4c6:56:3358
at https://blocks.wp.a2z/wp-content/plugins/gutenberg/build/editor/index.min.js?ver=96588d786d072613d4c6:48:734
at WithRegistryProvider(Component)
at qd (https://blocks.wp.a2z/wp-content/plugins/gutenberg/build/components/index.min.js?ver=3426334688a22e73bc0c:1:202446)
at Yd (https://blocks.wp.a2z/wp-content/plugins/gutenberg/build/components/index.min.js?ver=3426334688a22e73bc0c:1:202572)
at Jd (https://blocks.wp.a2z/wp-content/plugins/gutenberg/build/components/index.min.js?ver=3426334688a22e73bc0c:1:204255)
at div
at x (https://blocks.wp.a2z/wp-content/plugins/gutenberg/build/keyboard-shortcuts/index.min.js?ver=cb5377c7040e7e246fc0:1:3493)
at qa (https://blocks.wp.a2z/wp-content/plugins/gutenberg/build/edit-post/index.min.js?ver=feeab9feeb4fa9cd8a33:47:2502)

Consider adding an error boundary to your tree to customize error handling behavior.
Visit https://reactjs.org/link/error-boundaries to learn more about error boundaries.

Originally posted by @bobbingwide in bobbingwide/bobbingwide#104 (comment)

Cater for new labels in CPT registration

Since WordPress 5.8, a variation of the core/navigation-link block is registered in the server for each Custom Post Type and Taxonomy where the show_in_nav_menus attribute is true.

For CPTs registered using bw_register_post_type(), many of these variations were indistiguishable in the block editor. In blocks.wp-a2z.org I had 16 variations of "Post Link".

For more information, and a screenshot, see bobbingwide/oik-blocks#49

This is because the strings being used to generate the variation name and description were not defined in the post type's / taxonomy's labels array.

bobbingwide/oik#183 addresses the problem for post types registered using bw_register_post_type(), but doesn't cater for CPTs and taxonomies that have been created / updated using oik-types.

Requirement

• Ensure core/navigation-link variations for CPTs and taxonomies are identifiable.
• Support oik-types definitions created prior to WordPress 5.8

Solution

• For CPTs which are modified by oik-types merge the labels produced by bw_register_post_type() with those that have been saved in the bw_types option.
• For CPTs created by oik-types unset the saved $args['labels'] and use the values produced by bw_register_post_type().

At this point in time it doesn't seem necessary to remove the old labels from the bw_types option.

Support discovery of unregistered post types

On some sites custom post type data is created in wp_posts using a plugin or theme which is then deactivated. For security reasons the site no longer displays any UI for the content - admin or front-end.

It would be nice if this data could be discovered by oik-types. It would come in handy when upgrading a site and switching between plugins and themes.
In my current example, content was created using an event manager plugin.

The following SQL provided the details of the missing post types.

SELECT count(*), post_type FROM `wp_posts` group by post_type order by 1 desc

It turns out I was looking for tribe_events.

count(*)	post_type
482	revision
71	attachment
47	post
32	bp-email
29	clink
25	page
13	dpw_email
11	nav_menu_item
7	forum
6	topic
6	customize_changeset
4	tribe_events
3	tribe_venue
3	reply
3	tribe_organizer
2	oembed_cache
1	meetup

Should a deregistered CPT or taxonomy continue due to overrides?

The download post type is registered by Easy-Digital-Downloads. I wanted to clone the content so added the capability using oik-types. Having created blocks for EDD, using oik-loader, I no longer need it to be activated. But when EDD is deactivated, the post type is still visible in the admin area. Should it be?

Automatically update permalinks when a change has been noticed

I just activated another plugin that creates a post type and noticed that I needed to visit Settings > Permalinks in order to view the post type that the new plugin created.
oik-types has the same problem.
WIBNI oik-types could detect a change to the registered post types and/or taxonomies and do the permalink flushing automatically?

Add singular_name to custom taxonomies

Custom taxonomies can be defined using oik-types.
The logic does not currently support user entry of a singular label.
When determining the singular version of the label it can produce unwanted results.
e.g. The custom taxonomy "Block Status" ends up with a singular label of "Block Statu".

Requirement

• Add support for entry of singular name
• Display both plural and singular labels in the taxonomy list
• Generate default if not entered by user

Proposed solution

• Change admin\oik-taxonomies.php to accept the singular_name field
• Update oiktax_register_taxonomy() to pass the labels array to bw_register_custom_tags() or bw_register_custom_category().
• May need to move bw_return_singular_name() to admin/oik-types.php

oik-types should be able to turn off options such as `show_in_nav_menus`

In Gutenberg the Navigation link block ( core/navigation ) has a number of custom variations that are dynamically generated for each of the post types that are _builtin and/or support show_in_nav_menus.

A lot of my CPTs are registered with show_in_nav_menus since that is the default for CPTs which are public.

oik-types admin doesn't have the capability of turning off the show_in_nav_menus setting.

Requirement

• Reduce the number of variations of the core/navigation link that are displayed in wp-a2z.org

Proposed solution

One or more of the following:

0. Do nothing
1. Update the plugins that register the CPTs to set show_in_nav_menus to false.
2. Update bw_register_post_type() to set the show_in_nav_menus value to false if it's not set.
3. Change oik-types to support turning off of these boolean fields.

Option 1. may also require the oik-types CPT override to be changed.

Warning message for Add new Type

Warning: Array to string conversion in C:\apache\htdocs\wordpress\wp-includes\formatting.php on line 1104

0. bw_lazy_backtrace C:\apache\htdocs\wordpress\wp-content\plugins\oik-bwtrace\libs\bwtrace.php:108 0
1. bw_backtrace C:\apache\htdocs\wordpress\wp-content\plugins\oik-bwtrace\includes\bwtrace-actions.php:293 0
2. bw_trace_error_handler(2,Array to string conversion,C:\apache\htdocs\wordpress\wp-includes\formatting.php,1104) C:\apache\htdocs\wordpress\wp-includes\formatting.php:1104 4
3. wp_check_invalid_utf8(array) C:\apache\htdocs\wordpress\wp-includes\formatting.php:4690 1
4. esc_attr(array) C:\apache\htdocs\wordpress\wp-content\plugins\oik-bwtrace\libs\bobbforms.php:102 1
5. itext(archive_slug,20,array,null,null,null) C:\apache\htdocs\wordpress\wp-content\plugins\oik-bwtrace\libs\class-BW-.php:173 6
6. bw_textfield(archive_slug,20,Archive slug,array) C:\apache\htdocs\wordpress\wp-content\plugins\oik-types\admin\oik-types.php:670 4
7. oik_cpt_edit_has_archive(array) C:\apache\htdocs\wordpress\wp-content\plugins\oik-types\admin\oik-types.php:485 1
8. oik_cpt_edit_type_fields(array) C:\apache\htdocs\wordpress\wp-content\plugins\oik-types\admin\oik-types.php:364 1
9. oik_cpt_add_oik_cpt C:\apache\htdocs\wordpress\wp-content\plugins\oik-bwtrace\libs\class-BW-.php:97 0
10. oik_box(null,oik_cpt_add_oik_cpt,Add new,oik_cpt_add_oik_cpt) C:\apache\htdocs\wordpress\wp-content\plugins\oik-types\admin\oik-types.php:61 4
11. oikcpt_lazy_types_do_page C:\apache\htdocs\wordpress\wp-content\plugins\oik-types\admin\oik-types-admin.php:59 0
12. oikcpt_types_do_page() C:\apache\htdocs\wordpress\wp-includes\class-wp-hook.php:310 1
13. apply_filters(,array) C:\apache\htdocs\wordpress\wp-includes\class-wp-hook.php:334 2
14. do_action(array) C:\apache\htdocs\wordpress\wp-includes\plugin.php:517 1
15. do_action(types_page_oik_types) C:\apache\htdocs\wordpress\wp-admin\admin.php:259 1

Fatal error when bw_trace2 function not defined

While upgrading oik and oik-bwtrace in a WordPress Multisite installation ( oik-plugins.eu ) I got a Fatal error; produced when oik-types attempted to call bw_trace2.

Expected output

No fatal error.
Oik-types is dependent upon oik and oik-fields so should not be using functions until it’s safe to do so.

Actual output

Fatal error: Uncaught Error: Call to undefined function bw_trace2() in oik-types/oik-types.php:460

Explanation

During an upgrade to the latest version of oik-bwtrace and oik I'd deactivated oik-bwtrace to avoid a compatibility problem between non-final versions. But somehow the oik plugin had also become deactivated. This was unexpected. So bw_trace2 was not being loaded by either of these plugins.

Workaround

Deactivate oik-types prior to updating oik.

Proposed solution

• Remove the offending call(s) to bw_trace2
• Implement test cases for #3

It’s an unexpected situation leading to an unexpected result.
It should be tested in both WPMS and straight WordPress.

Respond to the 'register_post_type_args' filter function in WordPress 4.4

In WordPress TRAC 17447 (see https://core.trac.wordpress.org/ticket/17447#comment:60 ) a new filter called register_post_type_args was added to the register_post_type API. We should take advantage of this filter to apply the oik-types overrides to the post type before it's registered.

This will allow post type overrides, such as setting has_archive to true, to be effective. Before WP 4.4, switching the has_archive flag wasn't easy... if done after the post type registration it would have required changing rewrite rules. So we didn't actually implement it. Now it should be a cinch.

Enable Reusable Blocks in the admin menu

Requirement

To be able to Create and Edit Reusable blocks ( post_type=wp_block ) directly from the WordPress Dashboard.

Proposed solution

Extend oik-types to override _builtin = true and/or adjust the capabilities of a post type.

Alternative solution

Just use Bill Erickson's plugin. https://github.com/billerickson/Reusable-Blocks-UI

Background

Some time ago, when looking at Reusable blocks for the first time, I tried to use oik-types to enable "Blocks" to appear in the admin menu.

I finally achieved it ( in s.b/wordpress ) by updating the administrator role's capabilities.

But I can't remember exactly how I did it.

It could have been a simple edit of the serialised data to add the missing capabilities to wp_user_roles in wp_options.

In unhacked environments I have these 5 capabilities for blocks:

• delete_blocks
• delete_private_blocks
• edit_private_blocks
• publish_blocks
• read_private_blocks

In s.b/wordpress I have 6 more

• create_blocks
• delete_others_blocks
• delete_published_blocks
• edit_blocks
• edit_others_blocks
• edit_published_blocks

or I could have done it programmatically, or with a plugin.
I may even have hacked 'core', which caused it to update the options table for me.

Anyway, in order to be able to clone the content in Reusabe blocks I believe I have this need to reproduce what I did on s.b/wordpress on other sites.

Notes

Using oik-types does enable the New > Block link in the top admin menu
https://s.b/wordpress/wp-admin/post-new.php?post_type=wp_block

You have to select "Show in admin bar", then refresh the page.

but the Blocks and All Blocks link in the side menu is not present
https://s.b/wordpress/wp-admin/edit.php?post_type=wp_block

I've searched code changes for _builtin , traced filter results for register_post_type_args and grepped my daily notes files to no avail.

See also bobbingwide/oik-clone#24 (comment)

Warning: Trying to access array offset on value of type null admin\oik-fields.php

A few warnings displayed visiting oik-types > Fields when no fields are defined.
Happened in s.b/bigram
Warning: Trying to access array offset on value of type null in C:\apache\htdocs\wordpress\wp-content\plugins\oik-types\admin\oik-fields.php on line 278

Warning: Trying to access array offset on value of type null in C:\apache\htdocs\wordpress\wp-content\plugins\oik-types\admin\oik-fields.php on line 278

Warning: Trying to access array offset on value of type null in C:\apache\htdocs\wordpress\wp-content\plugins\oik-types\admin\oik-fields.php on line 283

Warning: Trying to access array offset on value of type null in C:\apache\htdocs\wordpress\wp-content\plugins\oik-types\admin\oik-fields.php on line 283

Warning: Trying to access array offset on value of type null in C:\apache\htdocs\wordpress\wp-content\plugins\oik-types\admin\oik-fields.php on line 284

Warning: Trying to access array offset on value of type null in C:\apache\htdocs\wordpress\wp-content\plugins\oik-types\admin\oik-fields.php on line 284

100% translatable and localizable

Oik-types needs to be internationalised and localised using the same techniques as implemented for oik.

See bobbingwide/oik#9

Improve support for the multi-select "post_type_support" select box

In WordPress TRAC 34009 I raised a requirement for an API called get_all_post_type_supports_features() and a filter called 'post_type_supports'.

Requirement

Improve oik-types implementation to

• provide sample code for this improvement
• implement it using a better solution than the original

Provide CLI for oik-types

IWBNI Custom Post Types, Taxonomies and Fields could be managed using a Command Line Interface.

General requirements

Specific requirement

• Ability to set archive_posts_per_page for the some of the post types created by oik-plugins, oik-themes and oik-shortcodes. This is needed for multiple sites.

Support PHP 7.1.x and PHP 7.2.x

PHP 7.1 is available. The code doesn't yet support it.
The following message is evidence.

Fatal error: Cannot use $this as parameter in /home/bwdesign/public_html/wp-content/plugins/oik-types/oik-types.php on line 384

Simple solution: Rename $this to $thus

See https://wiki.php.net/rfc/this_var

A customized post type prevents new taxonomies from being registered

In blocks.wp-a2z I'd overridden the value for Archive posts per page for the Block CPT.
This override prevented new custom categories from being registered in the initial block registration.

Explanation

A recent change to oik-shortcodes.php was to add the new taxonomies as below.

$post_type_args['taxonomies'] = [ 'block_category', 'block_keyword', 'block_classification' ];

It would appear that the filter logic is re-applying the saved value for the taxonomies parameter.

Workaround

Delete the override then re-apply.

Need to be able to register a CPT with REST API support

Referring to http://v2.wp-api.org/extending/custom-content-types/
I extracted the following text.

When registering a custom post type, if you want it to be available via the REST API, you should set, in the arguments passed to register_post_type an argument for show_in_rest. Setting this argument to true will add a route in the wp/v2 namespace, as long as you use the default post controller (see below.)

You can optionally set the rest_base argument to change the base url, which will otherwise default to the post type’s name. In the example below, “books-api” is used as the value of rest_base. This will make the URL for the route wp-json/v2/books-api instead of wp-json/v2/book/ which would have been the default.

In addition, you can pass an argument for rest_controller_class. This class must be a subclass of WP_REST_Controller. By default, WP_REST_Posts_Controller is used as the controller. If you are using a custom controller, then you likely will not be in the wp/v2 namespace.

Requirement

• oik-types should at least support the show_in_rest parameter.
• we also need to support show_in_rest for custom taxonomies.

Support `has_archive` parameter set to a string value such as `shop`

oik-types allows the definition of a post type to be overridden.
When overriding the product post type the string value of shop for the has_archive parameter was lost.
This led to an incorrect setting of the archive prefix for products.
The result was that the Shop page was not displaying the default shop display.

See bobbingwide/wizzie#10 (comment)

Requirement

• Allow user to set the has_archive parameter to a string value such as shop.

Proposed solution

• The code should cater for existing definitions where the has_archive value is 0 for false and either 1 or on for true
• The string value should only be used when the checkbox is set.

Warning from oik-types.php line 542

This message has been logged quite a few times in php_errorlog on bobbingwide.com since the start of the log ( April 2021 ).

PHP Warning: First parameter must either be an object or the name of an existing class in /home/customer/www/bobbingwide.com/public_html/wp-content/plugins/oik-types/oik-types.php on line 542

Eliminate queries to the wp_options table for 'missing' options fields

oik-types makes use of a range of options fields such as bw_taxonomies. When WordPress starts up it loads all options which are defined with autoload = 'yes'. This is OK as long as the options exist, even if they're just empty. But if they're missing then WordPress will perform another SQL query to attempt to load them. This is an overhead we don't need.

Workaround

Define some dummy taxonomies and relationships and then delete them. This will create empty entries which will be autoloaded.

Now we need to see if this does actually make the system a little faster.

oik-types: Notice: is_home was called incorrectly using WPForms

Notice: is_home was called incorrectly. Conditional query tags do not work before the query is run. Before then, they always return false. Please see Debugging in WordPress for more information. (This message was added in version 3.1.0.) in /home/customer/www/cwiccer.com/public_html/wp-includes/functions.php on line 5768

Warning: Trying to access array offset on value of type null in oik-types\admin\oik-types.php on line 347

Warning produced when attempting to add a new CPT.

Support for WordPress 5.0 and the new editor - Gutenberg

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.

Area	Problem	Reference
show_in_rest	oik-types does not support show_in_rest	See below

Support PHP 8.1, PHP 8.2 & PHP 8.3

Update code to run without problems in PHP 8.1 and 8.2

See bobbingwide/bobbingwide#103

Update strings for the 'post_type_supports' filter

Add US English explanations for additional values for post_type_supports

Value	Translatable string	Reference
clone	Clone content	oik-clone
publicize	Publicize with Jetpack	jetpack
shortlinks	Short links	jetpack
genesis-after-entry-widget-area	Genesis after entry widget area	Genesis theme framework
genesis-adjacent-entry-nav	Genesis adjacent entry nav	Genesis theme framework

See WordPress TRAC 34009

Note: oik-types is not yet internationalized/localized