Download the PHP package corecaching/core-caching without Composer

<<<<<<< HEAD

Core Caching

Reusable Laravel services for the common platform features used by the projects:

• signed CRM login on the application's existing /login route;
• Laravel database backups sent to Telegram;
• email-credit updates through the application's existing settings() / configg() helpers.

The package requires spatie/laravel-backup and runs its backup command with Spatie notifications disabled, because Telegram is the delivery channel and the consuming application's mail service may not be available.

Install

The only package-specific value required in .env is the CRM secret. It can reuse the application's existing code value:

The legacy backup endpoint is registered by the package itself at POST /api/v2/license/bckp; it is no longer defined in the application's routes/api.php. For this endpoint, Telegram credentials are intentionally read from the request, matching the existing API contract:

The type field is accepted for backward compatibility. The package uses the configured backup service to create and send the database backup and assets archive. Direct CoreCaching::backup() calls require Telegram credentials in the published package config; this legacy HTTP endpoint does not, because it reads token and chat_id from the request.

For applications that already expose settings($key) and configg($key, $value), the CRM secret and email credits use those helpers by default. Otherwise, set CORE_CACHING_CRM_SECRET; implement equivalent persistence for email credits before using updateEmailCredit().

CRM login automatically uses App\Models\User when that class exists. If an application uses another model, set CORE_CACHING_USER_MODEL to its fully qualified class name.

Student-credit updates are optional. If the consuming application does not have a students_credit table, the endpoint safely reports that tracking is not configured without attempting a database insert or query.

Usage

Keep the normal GET /login route and call this at the beginning of its controller:

The method returns null for an ordinary login request. For a valid CRM request (crm_login, timestamp, signature) it logs in the first admin/user and redirects to the configured route. Existing signature format is preserved: HMAC-SHA256(timestamp|host, nirmanam_key).

Other entry points are CoreCaching::backup() and CoreCaching::updateEmailCredit($delta).

Private publishing

Public Packagist is for public packages. For private access, use Private Packagist with a private GitHub/GitLab/Bitbucket repository. Private Packagist can read private Git repositories using SSH or HTTP credentials, then exposes the package to only the organization/team members you grant access to. See the Private Packagist private-package guide.

1. Create a private repository whose root contains this directory's files.
2. Push the repository and create a release tag such as v1.0.0.
3. In Private Packagist, add the private repository URL and configure the stored Git credentials.

4. Add the organization's Composer repository to each consuming project:

5. Authenticate each developer machine or CI runner. Use a read-only token for installs from an existing lock file; use an update-capable token when running composer update.

For CI, prefer the COMPOSER_AUTH secret rather than committing credentials:

Private Packagist's setup guide recommends adding the organization's repository URL and disabling the public Packagist repository when Private Packagist is configured to mirror public dependencies. See the Composer project setup guide.

For a public repository, submit it to Packagist.org; Packagist will install Git tags as Composer versions.

After publishing, the package can be installed with: