Propose a package
Цей контент ще не доступний вашою мовою.
Propose a useful extension or library for Yii2, Yii3, or framework-independent PHP. Authors and users may submit packages. State your relationship to the project and provide public evidence for its requirements.
What a proposal needs
Section titled “What a proposal needs”- The Composer name, public repository, concise purpose, and documentation URL;
- the maintainer’s name and public project or profile URL;
- the license and a link to its source;
- the exact PHP constraint from the selected revision’s
composer.json; - each claimed framework constraint and a source that supports it;
- the release tag or branch, its full commit ID, and links to the inspected source;
- your relationship to the package and any known compatibility limitations.
A branch name can move. Pin the inspected commit so that reviewers can understand which source supports a claim. Link to requirements, integration documentation, or published test evidence for that revision. Distinguish a declared requirement from a tested combination; a green badge alone does not establish every supported version.
Use the exact framework line when describing Yii compatibility. A package for Yii 22.0 is not automatically compatible with Yii 2.0 or Yii3. A reusable PHP library needs evidence for a claimed framework integration too.
Submit a data pull request
Section titled “Submit a data pull request”The canonical catalog is one JSON record per package under
src/data/catalog/ in the
site repository. Copy an existing record
as a starting point and keep the proposal limited to catalog data.
- Check the catalog for an existing entry. Update that record when the package is already listed.
- Supply the package’s
id,name,summary,family,ecosystems,kind,php,compatibility,docsUrl,repository,license,maintainer,relationship,relationshipEvidence, andprovenancefields using the existing record structure. - Set an independent proposal’s
familyandrelationshiptocommunity. Preserve the real maintainer attribution and provide an immutable HTTPS source inrelationshipEvidence. The other relationship values,maintainedandcontributed, require evidence of the portal maintainer’s role. Project collection membership is reviewed separately. - Include a constraint and evidence link for each compatibility entry. Record
the inspected source and review date in
provenance; do not imply that the portal maintainer has already approved your proposal. - Explain the addition or correction in the pull request and respond to any request for evidence.
The catalog is separate from packages.json and tools.json, which control
documentation imports and executable build work. A package proposal must not add
scripts, Composer dependencies, PHP demos, MDX, or agent skills. The catalog does
not install or execute submitted packages.
Prefer a form?
Section titled “Prefer a form?”Open a package proposal issue and provide the information listed above. The repository’s package proposal form collects the same evidence when available. An accepted issue still needs a reviewed catalog data pull request.
Use public repository links. Do not include credentials, private application code, personal contact details, or uploaded package archives.
How review works
Section titled “How review works”A moderator checks relevance, attribution, license, evidence, and the catalog record. The proposal may need more information or be declined with an explanation. Passing a data validation check does not approve a listing.
Publication requires human approval and the normal site release process. An issue or an open pull request is not a published listing. Review does not certify security, guarantee maintenance, or establish official Yii endorsement. Paid work and sponsorship do not determine acceptance or search ordering.
Correct or remove a listing
Section titled “Correct or remove a listing”Open a data pull request or a catalog issue with the package ID, the affected claim, and the supporting source. The package maintainer can also request a correction or removal through that channel.
Report package bugs to the package’s own tracker. For a security vulnerability, follow the owning project’s security reporting policy and avoid posting sensitive details in a public catalog issue.