Repository navigation
Fix QPXML::pi($prefix) always returning NULL - #87
Conversation
bc49eac to
57d4105
Compare
|
FYI, the failing checks are not caused by this change. Upstream runners now get The only change in that run is |
57d4105 to
2c1e8ae
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #87 +/- ##
============================================
+ Coverage 89.84% 89.89% +0.05%
Complexity 1430 1430
============================================
Files 26 26
Lines 3189 3186 -3
============================================
- Hits 2865 2864 -1
+ Misses 324 322 -2 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Read the existing round-trip test back by prefix instead of repeating it, and describe the fix by what pi() returns. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
@samipuro thanks so much for the contributions! The CI is fixed up now and I'll get your PRs merged. 👍 |
Pull Request type
What is the current behavior?
Issue Number: #79
pi($prefix)compares againsttagName, whichDOMProcessingInstructiondoes not have, so it always returns NULL with an "Undefined property" warning.What is the new behavior?
pi($prefix)compares against the processing instruction'stargetand returns the matching instructionpi($prefix, $text)can be read back by the same prefixDoes this introduce a breaking change?
Other information
Adds
QPXMLTest::testProcessingInstructionByPrefixand a CHANGELOG entry.