Relationships - inconsistency with metadata and wp_podsrel table

[JoryHogeveen]

Describe the bug

Case: We have a group relationship field to another object. Pods stores the group and _pods_group metakey. But also adds some data in the wp_podsrel table. It seems that Pods relies on the latter for displaying any data in WP admin or anywhere, not the actual group metakey.

I'm updating metadata through a PodsForm on the front-end. The actual form is modified a bit to only show certain options but the data send after submit is the same as usual.

Is this a known issue, and if so, is there a workaround? Why and for what is this table used at all?

Expected behavior I would expect that Pods relationships would work fine with just the regular metakeys (group) as well. Perhaps even as a fallback?

Pods Version

2.7.9

WordPress Environment

``` WordPress Version: 4.9.8

PHP Version: 7.2.8-1+ubuntu16.04.1+deb.sury.org+1

MySQL Version: 5.5.5

Server Software: nginx/1.15.0

Your User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36

Session Save Path: /tmp

Session Save Path Exists: Yes

Session Save Path Writeable: Yes

Session Max Lifetime: 1440

Opcode Cache:

Apc: No Memcached: No OPcache: Yes Redis: No Object Cache:

APC: No APCu: No Memcache: No Memcached: Yes Redis: No WPDB Prefix: wp_

WP Multisite Mode: No

WP Memory Limit: 40M

Pods Network-Wide Activated: No

Pods Install Location: /srv/www/motional.io/releases/20181107113620/web/app/plugins/pods/

Pods Tableless Mode Activated: No

Pods Light Mode Activated: No

Currently Active Theme: WellBeingProfile

Currently Active Plugins:

Admin Columns - Members add-on: 1.1 Admin Columns Pro: 4.3.8 Admin Columns Pro - Pods: 1.2 Beaver Builder Plugin (Pro Version): 2.1.6.3 Gravity Forms: 2.3.6 Gravity PDF: 4.5.0 Intercom: 2.6.1 Members: 2.1.0 Menu Icons: 0.11.2 Motional Snippets: 0.1 Notification: 5.2.4 Pods - Custom Content Types and Fields: 2.7.9 Query Monitor: 3.1.1 SendGrid: 1.11.8 Soil: 3.7.3 TablePress: 1.9.1 View Admin As: 1.8.2 WellBeing Profile (Motional): 1.1.3 WP CLI Login Command Server: 1.2 WPS Hide Login: 1.4.5

</details>

[sc0ttkclark]

wp_podsrel is used mostly for find() requests. It won't fallback to the meta table unless PODS_TABLELESS mode is on.

[JoryHogeveen]

Backlog from Slack:

Jory Hogeveen [16:00] @sc0ttkclark @pglewis I am thinking about extending the pods_tableless usage. Currently the only way to ditch the podsrel table is using pods_tableless. But that also disables some components. What is your thought on an extra constant/function check that allows to ONLY disable the podsrel table and keep everything else as-is. Not alle locations where podsrel is used are fiterable so it's very hard for me to write code to fix issues with this table

Scott Kingsley Clark [16:12] We can re enable the components in pods tableless That’s fine by me, intention was different back then and VIP adoption didn’t happen A separate constant to disable components would be nice though

Phil Lewis [18:24] My first thought is that we should explore the use case. Just considering tableless usage out of context is X/Y to me, I'd like to understand the driving reasons behind bypassing podsrel not uncommon that a better solution is available rather than taping things up VIP compliance was the driving reason before, as VIP vetted plugins can't create tables so, simple reason for the use case there

Scott Kingsley Clark [21:54] we don't even currently test tableless not even in the traversal tests

[JoryHogeveen]

Another note here is that this happens on podsforms on the front end!

[JoryHogeveen]

@sc0ttkclark Just found another weird case related to this. When doing a loop in saving metadata (to fix podsrel table) using update_post_meta it didn't update the podsrel table. But.. when using Pods::save() it did work. To be continued.. ideas welcome!

[jbats3108]

Per the discussion on the Wordpress Support Forum:

I have a script that updates a Taxonomy using add_term_meta(). Image and relationship fields are updated when this runs. The correct values are added into the database, but if the field was empty before the script ran, the images/list of selected relationship values will not be displayed in Admin.

Using the Add Files dialog or setting relationship values in the Edit Term screen to add something in these fields, then re-running the script to add the required values, will ensure that the images in wp_termmeta are reflected in the Admin screens.

Setting define('PODS_TABLELESS', true) fixed this - running the script for a taxonomy with no values for the image fields populated the database and showed the correct images in Admin.

[sc0ttkclark]

@jbats3108 could you post your system health info from WP? That could give us some potential ideas as to what's going on here.

@JoryHogeveen maybe the best thing to do here is to use that example you had about update_post_meta and try and create a new test case for it to show it failing. From there, we can more easily dig into the test results locally using xdebug etc to dig into the problem.

[quasel]

similar issues with wp_podsrel and meta storage see #5858, #5190,

We need to find a way to better keep our storage in sync…

some background how bidirectional stuff is stored (partly due to backward compatibility)

• meta storage, stored on both sides relating each item to each other, one row per related item on each entry,
• meta storage, sort order in the pods<meta_key> as an array
• If podsrel table enabled (default), stored on both sides as different rows (2x)

[jbats3108]

@sc0ttkclark

Debug info from our system:

WordPress Version: 5.7

PHP Version: 7.4.15

MySQL Version: 8.0.20

Server Software: nginx/1.18.0

Your User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.90 Safari/537.36

Session Save Path: /var/lib/php/sessions

Session Save Path Exists: Yes

Session Save Path Writeable: Yes

Session Max Lifetime: 1440

Opcode Cache:

Apc: No Memcached: No OPcache: Yes Redis: No Object Cache:

APC: No APCu: No Memcache: No Memcached: Yes Redis: Yes WPDB Prefix: wp_

WP Multisite Mode: No

WP Memory Limit: 40M

Current Memory Usage: 48.445M

Current Memory Usage (real): 5.563M

Pods Network-Wide Activated: No

Pods Install Location: /home/forge/{{site}}/public/wp-content/plugins/pods/

Pods Tableless Mode Activated: Yes

Pods Light Mode Activated: No

Currently Active Theme:

Currently Active Plugins:

Admin Columns Pro: 5.2.1 Admin Columns Pro - Pods: 1.5.1 Admin Menu Editor: 1.9.9 Editor Full Width Gutenberg: 1.0.5 FacetWP: 3.7.4 FacetWP - Alpha: 1.3.2 FacetWP - Cache: 1.5.1 FacetWP - Conditional Logic: 1.3.0 FacetWP - Hierarchy Select: 0.4.2 FacetWP - Map Facet: 0.9 FacetWP - Multilingual support: 1.0.0 FacetWP - Pods integration: 1.2.2 FacetWP - Range List: 0.6 FacetWP - Relevanssi integration: 0.7.2 FacetWP - Time Since: 1.5.1 JSM's Show Post Metadata: 1.3.0 JSON API: 2.0.0 Listify Customization: 1.0.0 Listing Labels for WP Job Manager: 2.5.1 Ninja Forms: 3.5.1 Ninja Forms - Addon Manager: 3.0.13 Ninja Forms - Conditional Logic: 3.0.28 Ninja Forms - Date Restrictions: Ninja Forms - File Uploads: 3.3.9 Ninja Forms - Layout & Styles: 3.0.28 Ninja Forms - Multi-Part Forms: 3.0.26 Ninja Forms - Webhooks: 3.0.5 Ninja Forms Multilingual: 0.1.2 Pods - Custom Content Types and Fields: 2.7.26 Redirection: 5.0.1 Redis Object Cache: 2.0.17 Regions for WP Job Manager: 1.17.7 Relevanssi: 4.12.4 ShortPixel Image Optimizer: 4.21.1 Stop Spammers: 2021.6 Toolset Types: 3.4.7 User Role Editor: 4.58.3 Vercel Deploy Hooks: 1.1.0 WordPress Importer: 0.7 WP Job Manager: 1.35.0 WP Job Manager Field Editor: 1.10.1 WPML Media: 2.6.3 WPML Multilingual CMS: 4.4.9 WPML String Translation: 3.1.7 WPML Translation Management: 2.10.5 WP OAuth Server - Pro: 4.1.7 WP REST Filter: 1.4.3 WP Rollback: 1.7.1 WP Webhooks: 2.1.2

[Nodws]

define('PODS_TABLELESS', true) in wp-config fixed all the dumb pods meta update behaviour