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)
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.
