* fix: address WordPress.org plugin review feedback
- Prefix the session transaction queue transient with the plugin's
graphql_woocommerce_ namespace instead of the generic "woo_" word, to
avoid collisions (Plugin Directory: prefix data storage).
- Declare the WooCommerce dependency via the "Requires Plugins: woocommerce"
plugin header.
- Bump README.txt "Tested up to" to 7.0.
- Ship composer.json in the distributed plugin (drop it, and composer.lock,
from composer archive excludes) so the build is reproducible/reviewable.
* chore: rename plugin to "GraphQL for eCommerce" for trademark compliance
The WordPress.org plugin review flagged the display name/slug for beginning
with the "WPGraphQL" trademark (and the "WooGraphQL" portmanteau of the
WooCommerce mark), which can imply official affiliation.
- Display name (plugin header + readme title) -> "GraphQL for eCommerce".
- Slug/text domain -> "graphql-for-ecommerce" (header, all i18n string
literals, and the PHPCS WordPress.WP.I18n text_domain config).
- Update user-facing notices/errors that named the old plugin.
"WooGraphQL" remains the project's informal nickname (repo, docs, community),
just not in the WordPress.org directory's official name/slug. Internal file
names and GitHub URLs are unchanged.
* fix: keep test-only dev deps out of the committed composer.json
The committed manifest mirrors develop (lint/stan dev deps only); CI adds the
test suite deps at runtime via `composer installTestEnv`. A previous commit
captured the installTestEnv-modified composer.json, desyncing it from
composer.lock and breaking `composer install` in CI.
* chore: regenerate composer.lock (refresh dev dependencies)
Regenerate the lock from the manifest so it is in sync (fixes the CI
`composer install` failure) and refresh dependencies in the process —
firebase/php-jwt v7.0.4 -> v7.1.0 plus 11 others, with vendor-prefixed
re-strauss'd to match. Full wpunit suite passes against the updated deps
(305 tests, 835 assertions).
* chore: rename text domain in createdVia/attribution strings from #1018#1018 (createdVia + order attribution) merged into develop after the rename
commit was authored, so its new i18n strings still used the old
'wp-graphql-woocommerce' text domain. Update them to 'graphql-for-ecommerce'
to match the rename.
* fix: resolve REQUEST_URI fatal error and JWT key length issues in CI
QLSessionHandlerTest::tearDown() was calling unset($_SERVER) which
destroyed the entire superglobal. WordPress cron.php then fataled on
shutdown when accessing $_SERVER['REQUEST_URI']. Changed to only unset
the specific HTTP_WOOCOMMERCE_SESSION key.
Also updated JWT secret keys to meet firebase/php-jwt v7's minimum
32-byte requirement for HS256 in both test config and Docker entrypoint.
* fix: the rest of the files added
* devops: php7.4 removed from matrix
* chore: Linter compliances met
* devops: More broken test updated
* devops: Tests updated for CI
* fix: QLSessionHandlerCest fixed
* fix: QLSessionHandlerCest fixed
* devops: CI fixed
* feat: QL Session Handler functionality expanded to support cookies on non-GraphQL requests
* chore: Linter and PHPStan compliance met
* devops: QLSessionHandlerTest patched for suite testing
* chore: Linter and PHPStan compliance met
* fix: More cart session save triggered implemented
* fix: More cart session save triggered implemented
* chore: Linter compliance met
* chore: Linter compliance met
* feat: forgetSession mutation added
* feat: forgetSession mutation added
* chore: avoid magic constants [PHPCS]
* chore: change ruleset to wp-graphql-cs and lint
* devops: HPOS added back to CI with the release of WC 3.9
---------
Co-authored-by: Geoff Taylor <geoff@axistaylor.com>
There are instances where a stale transaction stays around do to an error in the mutation. As a result, the recursive update_transaction_queue method will continue to run over and over, causing an inifinte loop and potentially crashing the server.
This attempts to add a timestamp once the transaction is validated when checking via the timestamp and will remove it from the queue.
The customer id is stored in the the session_handler instance. As a result the same transient was getting set for all users, which was causing errors when a hanging transaction was left.
