adamrice
(adamrice)
March 16, 2026, 9:16pm
1
I have a form to update user profiles. The profile has some additional fields (created in Pods), including some booleans; I’ve created equivalent form fields.
I am trying to maps the form fields to the profile fields, and these booleans don’t seem to make it through—in fact, I need to enter the field names by hand as “custom metas” because they do not appear in the popup list.
Hi there,
Could you please share the more details including fields, meta keys, Gravity Forms export copy so I can try to help you out?
If you want to know more about me, I’m here over 3 years and helping peoples, also contributed to the Pods plugin in recent time. You can check from below.
main ← faisalahammad:fix/issue-7465-repeatable-wysiwyg-fields
opened 12:34AM - 31 Jan 26 UTC
## Summary
Fixes #7465 - Repeatable WYSIWYG fields become uneditable after Wo… rdPress content import, causing React error #185 ("Maximum update depth exceeded").
## Problem Analysis
### 🔴 The Bug
When editing a post with repeatable WYSIWYG fields (using Quill editor) that were imported via WordPress XML Import, the fields become completely uneditable and the browser console shows:
```
Minified React error #185; visit https://reactjs.org/docs/error-decoder.html?invariant=185
```
This error means **"Maximum update depth exceeded"** - an infinite re-render loop in React.
### 🔍 Root Cause
The issue is in `ui/js/dfv/src/fields/wysiwyg/index.js` where ReactQuill's `onChange` handler directly calls `setValue`:
```jsx
// ❌ BEFORE - Causes infinite loop
<ReactQuill
value={ value || '' }
onChange={ setValue } // Problem here!
...
/>
```
**Why this causes an infinite loop:**
1. **ReactQuill mounts** with imported HTML content → fires `onChange(content, delta, source)`
2. **`setValue(content)` is called** → updates React state
3. **Component re-renders** with the "new" value (same content, but React sees it as changed)
4. **ReactQuill detects value prop change** → fires `onChange` again
5. **Loop continues indefinitely** → React Error #185
The `source` parameter in ReactQuill's `onChange` tells us *why* the change happened:
- `'user'` = User typed/edited content
- `'api'` = Programmatic change (like setting initial value)
- `'silent'` = Internal change that shouldn't trigger events
### ✅ The Fix
Only call `setValue` when the change was initiated by the user:
```jsx
// ✅ AFTER - No infinite loop
<ReactQuill
value={ value || '' }
onChange={ ( content, delta, source ) => {
// Only update state for user-initiated changes
// to prevent infinite loops on mount/programmatic updates
if ( source === 'user' ) {
setValue( content );
}
} }
...
/>
```
This is the [recommended approach from react-quill documentation](https://github.com/zenoamaro/react-quill#controlled-mode-caveats).
## Code Changes
### Before/After Diff
```diff
<ReactQuill
value={ value || '' }
onBlur={ () => setHasBlurred() }
- onChange={ setValue }
+ onChange={ ( content, delta, source ) => {
+ // Only update state for user-initiated changes
+ // to prevent infinite loops on mount/programmatic updates
+ if ( source === 'user' ) {
+ setValue( content );
+ }
+ } }
theme="snow"
modules={ { toolbar: QUILL_TOOLBAR_OPTIONS } }
readOnly={ toBool( readOnly ) }
/>
```
### Files Changed
| File | Change |
|------|--------|
| `ui/js/dfv/src/fields/wysiwyg/index.js` | Fixed `onChange` handler to check `source` parameter |
## Testing
### Automated Tests
- ✅ All 42 Jest tests pass
- ✅ Production build compiles successfully
### Manual Testing
- ✅ Imported the reporter's Pod configuration and WordPress XML export
- ✅ Verified repeatable WYSIWYG fields are now editable
- ✅ No React errors in browser console
- ✅ Content saves and persists correctly
## How to Test
1. Install [this patched plugin zip](https://github.com/user-attachments/files/24976019/pods-fix-7465.zip)
2. Import the Pod configuration from the issue
3. Import the WordPress XML export from the issue
4. Edit the imported "tuote" post type items
5. Verify WYSIWYG fields are editable with no console errors
## Screenshots
**Before:**
<img width="2554" height="1323" alt="image" src="https://github.com/user-attachments/assets/0226bbd6-faef-4fb9-8604-f35b5ec65b55" />
**After:**
<img width="3840" height="1926" alt="25B26829-6AF3-4ACD-BB01-BA20AD82630A" src="https://github.com/user-attachments/assets/2078e4f3-f1ff-4729-ba00-8010ed8529cc" />
## Related
- Issue: #7465
- React Error Reference: https://reactjs.org/docs/error-decoder.html?invariant=185
- react-quill Controlled Mode: https://github.com/zenoamaro/react-quill#controlled-mode-caveats
release/3.3.5 ← faisalahammad:fix/7477-taxonomy-sync-php-warnings
opened 03:10PM - 30 Jan 26 UTC
## Summary
This PR fixes PHP warnings that flood the log file when saving a p… ost with a relationship field that has the "Sync associated taxonomy with this relationship" option enabled, but no bidirectional relationship (sister_id) is configured.
Fixes #7477
## The Problem
When `pick_sync_taxonomy` is enabled but there is no bidirectional relationship set up:
- `$related_pod` is `null`
- `$related_field` is `null`
The original code at line 1959-1967 had this condition:
```php
if (
(
empty( $related_field )
|| empty( $related_pod )
)
&& empty( $options[ static::$type . '_sync_taxonomy' ] )
) {
return;
}
```
This means the function only returns early if BOTH conditions are true:
1. No bidirectional relationship exists, AND
2. No taxonomy sync is enabled
So when taxonomy sync IS enabled (but no bidirectional relationship exists), the code continues past this check and then tries to access `$related_pod['type']` on line 1974, which triggers the PHP warning.
## The Solution
Move the taxonomy sync logic to run first (it does not need `$related_pod` or `$related_field`), then add an early return if no bidirectional relationship exists.
### Before
```php
if (
(
empty( $related_field )
|| empty( $related_pod )
)
&& empty( $options[ static::$type . '_sync_taxonomy' ] )
) {
return;
}
// Handle the bi-directional relationship updates.
$no_conflict = true;
// Only check no conflict mode if this isn't the current pod type.
if ( $related_pod['type'] !== $pod['type'] ) { // <-- PHP Warning here!
$no_conflict = pods_no_conflict_check( $related_pod['type'] );
}
// ... more bidirectional code ...
// Handle syncing of taxonomy terms.
if ( ! empty( $pod['type'] ) && 'post_type' === $pod['type'] && ! empty( $options[ static::$type . '_sync_taxonomy' ] ) ) {
// taxonomy sync code
}
if ( ! $no_conflict ) {
pods_no_conflict_off( $related_pod['type'] ); // <-- PHP Warning here too!
}
```
### After
```php
// Handle syncing of taxonomy terms first (doesn't require bidirectional relationship).
if ( ! empty( $pod['type'] ) && 'post_type' === $pod['type'] && ! empty( $options[ static::$type . '_sync_taxonomy' ] ) ) {
// taxonomy sync code - runs independently
}
// Exit early if no bidirectional relationship to handle.
if ( empty( $related_field ) || empty( $related_pod ) ) {
return;
}
// Handle the bi-directional relationship updates.
// Now we are sure $related_pod and $related_field are not null
$no_conflict = true;
if ( $related_pod['type'] !== $pod['type'] ) {
$no_conflict = pods_no_conflict_check( $related_pod['type'] );
}
// ... rest of bidirectional code ...
if ( ! $no_conflict ) {
pods_no_conflict_off( $related_pod['type'] );
}
```
## Why This Works
1. Taxonomy sync does not need `$related_pod` or `$related_field` - it only uses `$pod`, `$options`, and `$value_ids`
2. By moving it to the top, it runs first regardless of whether a bidirectional relationship exists
3. The early return after taxonomy sync prevents the bidirectional code from executing when `$related_pod` is null
4. Bidirectional relationships still work exactly as before when properly configured
## Testing Done
- Tested with Pick field related to taxonomy with "Sync taxonomy" enabled
- No bidirectional relationship (sister_id) configured
- Saved post with taxonomy terms selected
- Verified: No PHP warnings in debug.log
- Verified: Taxonomy terms sync correctly to the post
- Also tested with bidirectional relationship enabled to make sure that still works
## Files Changed
- `classes/fields/pick.php` - Reordered logic in the `save()` method
## Plugin zip
[pods-fix-7477.zip](https://github.com/user-attachments/files/24968327/pods-fix-7477.zip)
1 Like
adamrice
(adamrice)
March 18, 2026, 5:10pm
3
Faisal–
Thanks. I am appending a screenshot of the relevant Pods fields. The Gravity Forms export is a little too big to include here, so I’ve uploaded it here .
Although Gravity Forms lets you place multiple checkboxes under a single title, for clarity I’ve created a separate title for each checkbox in the form.
Let me know if I can provide any more information.
Hi @adamrice
Sorry for the delay. I’ve already resolved the issue for the single checkbox item. Could you please share your all Pods by exporting so I can import on my end and give you a complete solution?
Thank you
Hi again,
I’ve resolved the issue. Now you can select the Pods fields under Gravity Forms > Settings > User Registration > User Meta , as shown in the screenshot below.
After a user is created or updated, the user meta will auto-sync and can be found under the user profile.
Please use the following code as an MU-Plugin for now. I plan to release a small plugin later for easier use in the future.
<?php
/**
* Plugin Name: Gravity Forms + Pods Integration
* Description: Automatically adds Pods User fields to the User Registration Add-On meta keys list, and properly casts mapped Checkbox values into strict booleans (1/0) for Pods boolean fields.
* Author: Faisal Ahammad
*/
// 1. Add Pods User fields to the GF User Registration Meta Key dropdown
add_filter( 'gform_user_registration_user_meta_options', function( $keys ) {
if ( ! function_exists( 'pods_api' ) ) {
return $keys;
}
$api = pods_api();
// Load the Extended User pod (if it exists)
$pod = $api->load_pod( [ 'name' => 'user' ], false );
if ( ! empty( $pod ) && ! empty( $pod['fields'] ) ) {
if ( ! is_array( $keys ) ) {
$keys = [];
}
foreach ( $pod['fields'] as $field ) {
$keys[] = [
'label' => '[Pods] ' . $field['label'],
'name' => $field['name'],
'value' => $field['name'],
'required' => false
];
}
}
return $keys;
}, 10, 1 );
// 2. Intercept boolean values to ensure they save as 1/0 for Pods
add_filter( 'gform_user_registration_meta_value', function( $value, $meta_key, $meta, $form, $entry ) {
if ( ! function_exists( 'pods_api' ) ) {
return $value;
}
$api = pods_api();
$pod = $api->load_pod( [ 'name' => 'user' ], false );
if ( empty( $pod ) || empty( $pod['fields'] ) || empty( $pod['fields'][ $meta_key ] ) ) {
return $value; // Not a Pods field or not registered.
}
$field = $pod['fields'][ $meta_key ];
// Only apply processing to boolean fields
if ( 'boolean' === $field['type'] ) {
if ( is_array( $value ) ) {
$value = empty( $value ) ? 0 : 1;
} else {
// In Gravity Forms, an unchecked string is usually empty "".
// A explicitly false string could be "false" or "no".
// Valid labels are considered truthy.
$value = ( empty( $value ) || '0' === $value || false === filter_var( $value, FILTER_VALIDATE_BOOLEAN, FILTER_NULL_ON_FAILURE ) ) ? 0 : 1;
}
}
return $value;
}, 10, 5 );
You can also get the source code from here:
gravity-forms-pods-integration-user-registration.php
<?php
/**
* Plugin Name: Gravity Forms + Pods Integration
* Description: Automatically adds Pods User fields to the User Registration Add-On meta keys list, and properly casts mapped Checkbox values into strict booleans (1/0) for Pods boolean fields.
* Author: Faisal Ahammad <me@faisalahammad.com>
*/
// 1. Add Pods User fields to the GF User Registration Meta Key dropdown
add_filter( 'gform_user_registration_user_meta_options', function( $keys ) {
if ( ! function_exists( 'pods_api' ) ) {
This file has been truncated. show original
MU-Plugin guideline:
Give it a try, and let me know how that goes!
Best regards,
Faisal
1 Like
adamrice
(adamrice)
April 1, 2026, 12:07pm
6
Thanks very much. I haven’t had a chance to try this out yet, but I appreciate your time and expertise.
You’re welcome.
Please keep me posted about the outcome.