| 1 |
<?php |
| 2 |
/** |
| 3 |
* Client Service Provider Class |
| 4 |
* |
| 5 |
* @package Easy_Invoice |
| 6 |
* @subpackage Providers |
| 7 |
*/ |
| 8 |
|
| 9 |
namespace EasyInvoice\Providers; |
| 10 |
|
| 11 |
use EasyInvoice\Interfaces\ClientRepositoryInterface; |
| 12 |
use EasyInvoice\Repositories\ClientRepository; |
| 13 |
|
| 14 |
/** |
| 15 |
* ClientServiceProvider Class |
| 16 |
* |
| 17 |
* Handles registration of client-related services. |
| 18 |
*/ |
| 19 |
class ClientServiceProvider { |
| 20 |
/** |
| 21 |
* The repository instance |
| 22 |
* |
| 23 |
* @var ClientRepositoryInterface |
| 24 |
*/ |
| 25 |
protected static $repository = null; |
| 26 |
|
| 27 |
/** |
| 28 |
* Register client services |
| 29 |
*/ |
| 30 |
public function register() { |
| 31 |
// Register the `customer` role on init:1. |
| 32 |
// |
| 33 |
// This was previously hooked to `after_setup_theme` from inside |
| 34 |
// a callback that itself only runs on init:10 — so by the time |
| 35 |
// add_action() was called, `after_setup_theme` had already fired |
| 36 |
// and the registration silently never ran. On sites without |
| 37 |
// WooCommerce (which also registers `customer`), the role stayed |
| 38 |
// unregistered, WP_User::roles filtered it out as unknown, and |
| 39 |
// the Clients page fell back to a "Client" label while WC sites |
| 40 |
// showed "Customer" for the same data. |
| 41 |
add_action('init', [$this, 'registerClientRole'], 1); |
| 42 |
|
| 43 |
// Register client repository |
| 44 |
$this->registerClientRepository(); |
| 45 |
} |
| 46 |
|
| 47 |
/** |
| 48 |
* Register client role if it doesn't exist. |
| 49 |
* |
| 50 |
* Idempotent — short-circuits when WooCommerce (or anything else) |
| 51 |
* has already registered the role. Two implications worth knowing: |
| 52 |
* |
| 53 |
* 1. We register WITHOUT the `read` capability. On a site that |
| 54 |
* never had WooCommerce, existing 'customer'-role users had no |
| 55 |
* effective `read` cap because the role wasn't registered at |
| 56 |
* all (and `WP_User::has_cap` couldn't pull `read` from a role |
| 57 |
* that didn't exist). Registering with `['read' => true]` here |
| 58 |
* would silently UPGRADE those users — granting wp-admin access |
| 59 |
* they never had. We pass `[]` so the registration only fixes |
| 60 |
* the display label, not the cap surface. |
| 61 |
* |
| 62 |
* 2. On a site WITH WooCommerce, WC has already registered |
| 63 |
* 'customer' with its full cap set (including `read`). Our |
| 64 |
* add_role() is a no-op there — get_role() returns truthy and |
| 65 |
* we bail. WC customers retain WC's caps unchanged. |
| 66 |
*/ |
| 67 |
public function registerClientRole() { |
| 68 |
if (get_role('customer')) { |
| 69 |
return; |
| 70 |
} |
| 71 |
add_role( |
| 72 |
'customer', |
| 73 |
__('Customer', 'easy-invoice'), |
| 74 |
[] |
| 75 |
); |
| 76 |
} |
| 77 |
|
| 78 |
/** |
| 79 |
* Register client repository |
| 80 |
*/ |
| 81 |
protected function registerClientRepository() { |
| 82 |
// Create and store the repository instance |
| 83 |
self::$repository = new ClientRepository(); |
| 84 |
} |
| 85 |
|
| 86 |
/** |
| 87 |
* Get the client repository |
| 88 |
* |
| 89 |
* @return ClientRepositoryInterface The client repository |
| 90 |
*/ |
| 91 |
public static function getClientRepository() { |
| 92 |
// Create the repository if it doesn't exist |
| 93 |
if (self::$repository === null) { |
| 94 |
self::$repository = new ClientRepository(); |
| 95 |
} |
| 96 |
|
| 97 |
return self::$repository; |
| 98 |
} |
| 99 |
} |