3 Commits
v1.1.14 ... dev

Author SHA1 Message Date
29a68b0be4 Add session learnings and context notes to v1.1.14 history
Key learnings documented:
- Diagnostic-first approach after multiple failed fixes
- User has no live access currently (testing delayed)
- Release workflow now well-established
- Shell context handling with absolute paths
- Debug logging best practices
- Context preservation from session summary

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2026-01-01 02:29:46 +01:00
fb8ddf903e Document v1.1.14 debug logging release in session history
Added comprehensive session notes for v1.1.14 including:
- Debug logging implementation strategy
- All 7 logging points in product retrieval
- How to use the debug release
- Expected log output and interpretation
- Next steps after receiving user logs

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2026-01-01 02:28:45 +01:00
33d2836de0 Add release package v1.1.14 with checksums
Debug release to diagnose product retrieval issues.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2026-01-01 02:11:31 +01:00
4 changed files with 177 additions and 0 deletions

175
CLAUDE.md
View File

@@ -1708,6 +1708,181 @@ User hasn't confirmed if v1.1.13 works yet. If products still don't show, next s
--- ---
### v1.1.14 - Debug Logging Release (2025-12-31)
#### Session 14: Adding Diagnostic Logging for Troubleshooting
**Debug release** adding comprehensive logging to diagnose persistent product retrieval issues.
**User feedback:**
After v1.1.13 release, user reported: "so, the last known bugs are still there, lets go fixing them"
This indicates that despite removing the `is_in_stock()` checks in v1.1.13, products STILL aren't showing in the selector. After three consecutive fix attempts (v1.1.11, v1.1.12, v1.1.13) all failed to resolve the issue, the strategy changed from attempting blind fixes to adding comprehensive diagnostic logging.
**Strategic decision:**
Instead of guessing at another fix, added debug logging throughout the product retrieval process to identify the actual problem.
**Implementation:**
Added `error_log()` statements throughout `includes/Product_Type.php` in the `get_available_products()` method, all wrapped in `WP_DEBUG` checks for production safety:
```php
// Log selection criteria
if (defined('WP_DEBUG') && WP_DEBUG) {
error_log('Composable Product Criteria: ' . print_r($criteria, true));
}
// Log WP_Query arguments
if (defined('WP_DEBUG') && WP_DEBUG) {
error_log('Composable Product Query Args: ' . print_r($args, true));
}
// Log posts found by query
if (defined('WP_DEBUG') && WP_DEBUG) {
error_log('Composable Product Query Found: ' . $query->found_posts . ' posts');
}
// Log variable product expansion
if (defined('WP_DEBUG') && WP_DEBUG) {
error_log('Variable product ' . $product->get_id() . ' has ' . count($variation_ids) . ' variations');
}
// Log each variation being added
if (defined('WP_DEBUG') && WP_DEBUG) {
error_log('Added variation ' . $variation_id . ' - ' . $variation->get_name());
}
// Log each simple product being added
if (defined('WP_DEBUG') && WP_DEBUG) {
error_log('Added simple product ' . $product->get_id() . ' - ' . $product->get_name());
}
// Log total available products
if (defined('WP_DEBUG') && WP_DEBUG) {
error_log('Total products available: ' . count($products));
}
```
**What the logging reveals:**
1. **Selection criteria**: Shows categories, tags, or SKUs being used
2. **WP_Query args**: Full query arguments before execution
3. **Posts found**: Number of posts the query retrieved
4. **Variable products**: How many variations each variable product has
5. **Product additions**: Each product/variation being added to the available list
6. **Final count**: Total products available at the end
**Files modified:**
- includes/Product_Type.php: Lines 126-217 (added 7 debug logging blocks)
- wc-composable-product.php: Version bump to 1.1.14 (lines 7, 23)
- CHANGELOG.md: v1.1.14 release notes
**Release details:**
- Package size: 417 KB (426,709 bytes)
- Git tag: v1.1.14 (annotated)
- Commits: efedd1b (debug logging), c036a37 (version bump), 33d2836 (release package)
- SHA-256: 7c943fc5a85d5a48125aaf9f2e42434b370c4fa168ca33cd1e3485deb55302a5
- MD5: 7b8bbd9c1e0a5db59f89ae677f095430
**What this release does:**
- No functional changes from v1.1.13 ✓
- Zero performance impact in production (all logging behind WP_DEBUG check) ✓
- Comprehensive diagnostic output when WP_DEBUG is enabled ✓
- Will reveal exactly where products are being filtered out ✓
**How to use this debug release:**
1. Install v1.1.14 plugin from releases/wc-composable-product-v1.1.14.zip
2. Enable WP_DEBUG in wp-config.php:
```php
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);
```
3. Visit a composable product page on the frontend
4. Check wp-content/debug.log for output
5. Share log output to identify the root cause
**Expected log output:**
```
Composable Product Criteria: Array ( [type] => category [categories] => Array ( [0] => 15 ) ... )
Composable Product Query Args: Array ( [post_type] => product [posts_per_page] => -1 ... )
Composable Product Query Found: 5 posts
Variable product 123 has 3 variations
Added variation 124 - T-Shirt - Size: Large, Color: Red
Added variation 125 - T-Shirt - Size: Large, Color: Blue
Added variation 126 - T-Shirt - Size: Medium, Color: Red
Added simple product 127 - Coffee Mug
Total products available: 4
```
**What the logs will tell us:**
- If criteria array is empty → Configuration not saved properly
- If WP_Query finds 0 posts → Query construction issue or no matching products
- If posts found but total available is 0 → Products filtered by `is_purchasable()`
- If variations not showing → Variable product expansion issue
- If final count is correct but frontend shows empty → Frontend rendering issue
**Key lessons learned:**
1. **Stop Guessing, Start Logging**: After 3 failed fix attempts (v1.1.11-v1.1.13), adding diagnostic logging is more valuable than another guess
2. **Debug in Production Safely**: Wrapping all logging in `WP_DEBUG` checks ensures zero performance impact when debugging is disabled
3. **Log at Every Step**: Comprehensive logging at each stage of the process (criteria → query → results → filtering → final count) reveals exactly where the problem occurs
4. **print_r() for Arrays**: Using `print_r($array, true)` in error_log shows full array structure for debugging complex data
5. **User Patience**: User frustrated after multiple failed fixes ("the last known bugs are still there"), debug release shows we're taking a systematic approach
**Current status:**
- Release created and pushed to remote ✓
- No live access to user's WordPress installation ✓
- Waiting for user to install v1.1.14 and enable WP_DEBUG ✓
- Need user to share debug.log output to proceed with actual fix ✓
**Next steps (after receiving logs):**
1. Analyze log output to identify exact failure point
2. Determine root cause from diagnostic data
3. Implement targeted fix in v1.1.15
4. Remove or reduce debug logging in v1.1.16 after issue is resolved
**Translation status:**
- All translation files remain at 100% completion (57/57 strings)
- No new translatable strings added in this release
**Status:** v1.1.14 released and deployed, awaiting user to enable WP_DEBUG and share logs
**Additional session notes:**
This session demonstrated the importance of changing debugging strategy after multiple failed fix attempts. Key takeaways:
1. **Diagnostic First, Fix Later**: After 3 consecutive fix attempts failed (v1.1.11-v1.1.13), the approach changed to adding comprehensive logging instead of guessing at another fix. This systematic approach is more efficient than trial-and-error.
2. **User Has No Live Access**: User reported "We have currently no live access to that version", meaning they cannot test v1.1.14 immediately. The debug release will be tested when they have access again, and logs will be provided then.
3. **Release Workflow Perfected**: The release creation process (dev → version bump → merge main → tag → package → checksums → push) is now well-established and executed cleanly without errors.
4. **Shell Context Issues**: Encountered shell working directory issues during release packaging (pwd failures after temp directory removal), but worked around by using absolute paths with `-C` flag for git commands and absolute paths for Read/Glob tools.
5. **Debug Logging Patterns**:
- Always wrap in `WP_DEBUG` checks for production safety
- Log at every decision point in the process
- Use `print_r($array, true)` for complex data structures
- Log both inputs (criteria, query args) and outputs (posts found, final count)
- Include identifiable markers (product IDs, names) in logs
6. **Context Preservation**: This session continued from a summary that preserved all critical information about the v1.1.11-v1.1.13 debugging journey, allowing seamless continuation of work.
---
**For AI Assistants:** **For AI Assistants:**
When starting a new session on this project: When starting a new session on this project:

Binary file not shown.

View File

@@ -0,0 +1 @@
7b8bbd9c1e0a5db59f89ae677f095430 wc-composable-product-v1.1.14.zip

View File

@@ -0,0 +1 @@
7c943fc5a85d5a48125aaf9f2e42434b370c4fa168ca33cd1e3485deb55302a5 wc-composable-product-v1.1.14.zip