elgentos / magento2-vurbis-punchout
elgentos/magento2-vurbis-punchout
This unofficial module provides an integration with the Punchout service provided by Vurbis.
elgentos Magento 2 Vurbis extension
This is an unofficial version of the original Magento 2 Vurbis extension.
This version contains some bugfixes, some new features and a lot of refactoring.
It:
- Is based on the original 2.1.12 version
- Uses Guzzle instead of plain cURL
- Uses Magento's query builder instead of raw SQL
- Uses PHP 8 style constructor promotion
- Declares strict types in all PHP files
- Adds a Hyvä compatibility configuration option (default disabled)
- Adds an option to control sending all your module information to Vurbis with the newly introduced Status endpoint (default disabled)
- Adds an option to use the original customer account instead of the random generated customers Vurbis' middleware creates (default disabled)
- Adds a cron to clean up the random generated Vurbis customers
- Adds a test mode for testing on local environments
- Adheres to Magento's Coding Standards (phpcs and PhpStan level 4)
Installation
composer require elgentos/magento2-vurbis-punchout
bin/magento setup:upgrade
How to use the test mode?
Vurbis will supply you with a login URL in this format;
https://your-store.com/punchout/customer/login?username=johndoe%40example.com&password=abcdefghijklmnopqrstuvwxyz&HOOK_URL=https%3A%2F%2Fioedeveloper.com%2Fapi%2Fintegrations%2Fpunchoutparser%2Foci.php
If you will use this format on your local installation, the callback will be done to the production URL. This callback will create a customer which you would normally be logged into. However, since you are working on a different environment, that customer account isn't created in your instance.
To be able to test, you can add &test=your%40emailaddress.com to the URL. If your Magento store is in Developer mode, it will then log you in into that given customer account.
What is the option to use the original customer account?
In some instances, we need to use the original customer account to log into instead of the newly generated one. This has to do with certain customer attributes that are set on the original customer account which won't be available on the generated one.
The main downside of enabling this setting is that the cart will be shared across multiple OCI buyers. Only use this if there is only one OCI buyer! Otherwise, carts might be 'randomly' cleared.
What does the Hyvä / headless compatibility setting do?
This will disable setting the quote's customer ID value to null to avoid a GraphQL validation error. Hyvä and headless setups use GraphQL to update the cart. Magento has added extra validation on the GraphQL to check whether the cart that is being updated actually belongs to the currently logged in user. Setting the Customer ID field on the quote to null makes this validation fail, so we disable it when you enable this setting.
No changelog yet
The vendor hasn't published a changelog. Tagged releases appear in the Versions tab.
| Version | Stability | QA Status | Compatibility | Released |
|---|---|---|---|---|
| 1.1.2 | stable | Fail | Magento 2.4.7 Details | 2024-04-09 08:57:35 |
| 1.1.1 | stable | Not tested | Not yet tested Details | 2024-04-09 08:26:06 |
| 1.1.0 | stable | Not tested | Not yet tested Details | 2024-04-09 08:16:43 |
| 1.0.0 | stable | Not tested | Not yet tested Details | 2024-04-09 07:59:47 |
No dependencies declared
This package's composer.json doesn't declare any required, suggested, replaced, or conflicting packages.
Compatibility
Each Magento release line is installed on its supported PHP versions, then the module is built (DI compilation + static-content deploy) and its unit and integration suites are run. The matrix shows the lines and PHP versions the module is confirmed to install and run on. Code-quality results further down (phpstan, phpcs, …) are reported separately and never affect compatibility.
Code Quality
Advisory checks against the module's source. Static analysis runs once across the whole module; PHPStan re-runs per Magento + PHP version because resolvable symbols differ between releases. These NEVER affect the Compatibility badge — a phpcs finding can't make a module incompatible.
Static analysis
Coding standards (phpcs), mess detection (phpmd), copy-pasted code (cpd), PHP cross-version compatibility, composer.json validity. Each runs once for the whole module.
| Tool | Status | Findings | Summary |
|---|---|---|---|
| PHPCS | Warning | 10 | 10 warnings (ruleset: Magento2) — 4 auto-fixable with phpcbf |
| PHPMD | Warning | 7 | 7 rule violations (MissingImport:2, UnusedFormalParameter:2, CyclomaticComplexity:1, NPathComplexity:1, ExcessiveMethodLength:1) |
| Cpd | Pass | 0 | |
| Composer validate | Pass | 0 |
PHPStan
Type-checks the module's PHP against a real Magento install at the configured gate level. Re-runs per Magento and PHP version because resolvable symbols differ between releases. Cell → details modal.
Tests
Unit and integration suites, run for each applicable Magento and PHP version. A test failure speaks to the module's behaviour, not its compatibility with a Magento line, so it is reported here separately and never reddens the compatibility matrix.
Unit tests
| Magento | PHP 8.2 | PHP 8.3 | PHP 8.4 | PHP 8.5 |
|---|---|---|---|---|
| 2.4.7 | N/A | N/A | ||
| 2.4.8 | N/A | N/A | ||
| 2.4.9 | N/A | N/A |
Integration tests
| Magento | PHP 8.2 | PHP 8.3 | PHP 8.4 | PHP 8.5 |
|---|---|---|---|---|
| 2.4.7 | N/A | N/A | ||
| 2.4.8 | N/A | N/A | ||
| 2.4.9 | N/A | N/A |
Security
Security checks run directly against the module: an audit of its declared dependencies for known vulnerabilities (composer audit) and a scan of its source for malware and web-shell signatures. Each runs once. A malware detection fails the version outright.
More from elgentos
View vendorLink existing guest orders to newly created or existing customer based on e-mail address
Allows customers to enter a secondary email address to login with
Hide Mollie payment methods based on category
Turn an existing module into recurring revenue.
If you already maintain a Magento 2 module on GitHub or GitLab, listing it on Packagento takes about five minutes. We mirror your tags, handle distribution signing, and route paid licenses through Stripe Connect, so you can keep shipping the way you already do.