phpcs.xml.dist

<?xml version="1.0"?>
<ruleset name="Secrets API">
	<description>Coding standards for the Secrets API feature plugin.</description>

	<file>.</file>

	<exclude-pattern>/vendor/*</exclude-pattern>
	<exclude-pattern>/node_modules/*</exclude-pattern>
	<exclude-pattern>/coverage/*</exclude-pattern>
	<!--
		examples/ holds platform bindings that carry their own SDK dependencies and
		are never loaded by the plugin. Linting them here would mean this project's
		CI installing the AWS and Google SDKs to check code it does not ship.
	-->
	<exclude-pattern>/examples/*</exclude-pattern>
	<!-- site/ is the Astro docs site: JavaScript, no PHP of ours, and a node_modules tree. -->
	<exclude-pattern>/site/*</exclude-pattern>
	<!-- .smoke/ is bin/smoke-install.sh's throwaway install: all of WordPress core, plus a symlink back to this repository that would otherwise send phpcs into a cycle. -->
	<exclude-pattern>/.smoke/*</exclude-pattern>
	<!-- tests/phpstan/ holds a PHPStan extension copied unchanged from wordpress-develop, which keeps it under a different standard. -->
	<exclude-pattern>/tests/phpstan/*</exclude-pattern>

	<arg name="extensions" value="php"/>
	<arg name="basepath" value="."/>
	<arg name="colors"/>
	<arg name="parallel" value="8"/>
	<arg value="ps"/>

	<!--
		Everything is destined for core or written alongside code that is, so core's
		standard is the target rather than a host-specific one. WordPress-Extra is layered onto the
		plugin-only directories further down.
	-->
	<rule ref="WordPress-Core"/>
	<rule ref="WordPress-Docs"/>

	<rule ref="WordPress-Extra">
		<include-pattern>/plugin/*</include-pattern>
		<include-pattern>/cli/*</include-pattern>
		<include-pattern>/secrets-api\.php$</include-pattern>
	</rule>

	<!--
		bin/gen-reference.php is a development tool, not shipped code. It declares one
		class in a file named for what the tool does rather than for the class, which
		is the convention for scripts under bin/.
	-->
	<rule ref="WordPress.Files.FileName">
		<exclude-pattern>/bin/*</exclude-pattern>
	</rule>

	<rule ref="PHPCompatibilityWP"/>
	<config name="testVersion" value="7.4-"/>

	<config name="minimum_wp_version" value="6.6"/>

	<rule ref="WordPress.WP.I18n">
		<properties>
			<!--
				src/ is core-bound, so its calls pass no text domain at all, as core's own
				do. "default" is listed so that omitting the argument is allowed.
				Plugin-only code uses the plugin's own domain. An architectural test
				enforces that src/ never passes a domain.
			-->
			<property name="text_domain" type="array">
				<element value="default"/>
				<element value="secrets-api"/>
			</property>
		</properties>
	</rule>

	<!--
		With text domains configured, the sniff warns about any call that omits one and
		suggests naming "default". In src/ omitting it is the point: core does not pass
		a domain for its own strings, and review on the core patch asked for the same.
	-->
	<rule ref="WordPress.WP.I18n.MissingArgDomainDefault">
		<exclude-pattern>/src/*</exclude-pattern>
	</rule>

	<rule ref="WordPress.NamingConventions.PrefixAllGlobals">
		<properties>
			<property name="prefixes" type="array">
				<element value="wp_secrets"/>
				<element value="wp_secret"/>
				<element value="WP_Secret"/>
				<element value="WP_SECRETS"/>
				<element value="secrets_api"/>
				<element value="Secrets_API"/>
				<element value="WP_CLI_Secret"/>
			</property>
		</properties>
		<!--
			src/ declares wp_*() functions and WP_* classes on purpose: these files are
			meant to be copied into wordpress-develop unchanged, where those names are
			correct rather than unprefixed.
		-->
		<exclude-pattern>/src/*</exclude-pattern>
	</rule>

	<!--
		The test suite follows core's own conventions for its tests, which differ from
		the standard applied to shipped code: PHPUnit assertion methods are camelCase,
		the bootstrap writes to STDOUT before WordPress exists to escape with, and
		harness globals deliberately match the names the core test suite expects.
	-->
	<rule ref="WordPress.NamingConventions.PrefixAllGlobals">
		<exclude-pattern>/tests/*</exclude-pattern>
	</rule>
	<rule ref="WordPress.NamingConventions.ValidFunctionName.MethodNameInvalid">
		<exclude-pattern>/tests/*</exclude-pattern>
	</rule>
	<rule ref="WordPress.Security.EscapeOutput">
		<exclude-pattern>/tests/bootstrap\.php$</exclude-pattern>
	</rule>
	<rule ref="Squiz.Commenting.FunctionComment">
		<exclude-pattern>/tests/*</exclude-pattern>
	</rule>
	<rule ref="Squiz.Commenting.ClassComment">
		<exclude-pattern>/tests/*</exclude-pattern>
	</rule>
	<rule ref="Squiz.Commenting.VariableComment">
		<exclude-pattern>/tests/*</exclude-pattern>
	</rule>
	<rule ref="Squiz.Commenting.FileComment.Missing">
		<exclude-pattern>/tests/*</exclude-pattern>
	</rule>
	<rule ref="Generic.Commenting.DocComment.MissingShort">
		<exclude-pattern>/tests/*</exclude-pattern>
	</rule>

	<!--
		class-mock-wp-cli.php exists specifically to define classes and a namespaced
		function under names an external library (WP-CLI) dictates: WP_CLI,
		WP_CLI\Utils\format_items(). The usual one-object-per-file and
		file-name-matches-class-name conventions do not apply to it.
	-->
	<rule ref="WordPress.Files.FileName.InvalidClassFileName">
		<exclude-pattern>/tests/*</exclude-pattern>
		<exclude-pattern>/docs/reference/drop-in-example\.php$</exclude-pattern>
	</rule>
	<!--
		docs/reference/drop-in-example.php is a single reference file meant to be read and
		copied whole into wp-content/secrets.php: it deliberately shows a provider
		stub, a store, and a keyring side by side, which is the multi-class shape a
		real drop-in can have (see docs/spec/extension-points.md: a drop-in can set
		any of the three globals, or none of them). Splitting it into three files
		would make it harder, not easier, to use as a reference.
	-->
	<rule ref="Generic.Files.OneObjectStructurePerFile">
		<exclude-pattern>/tests/includes/class-mock-wp-cli\.php$</exclude-pattern>
		<exclude-pattern>/docs/reference/drop-in-example\.php$</exclude-pattern>
	</rule>
	<!--
		Bracketed namespace syntax (namespace X { ... }) is otherwise banned, but it
		is the only way to mix global-namespace declarations with a WP_CLI\Utils-
		namespaced function in one file, which is exactly this file's job.
	-->
	<rule ref="Universal.Namespaces.DisallowCurlyBraceSyntax">
		<exclude-pattern>/tests/includes/class-mock-wp-cli\.php$</exclude-pattern>
	</rule>
	<rule ref="Universal.Namespaces.DisallowDeclarationWithoutName">
		<exclude-pattern>/tests/includes/class-mock-wp-cli\.php$</exclude-pattern>
	</rule>
	<rule ref="Universal.Namespaces.OneDeclarationPerFile">
		<exclude-pattern>/tests/includes/class-mock-wp-cli\.php$</exclude-pattern>
	</rule>
</ruleset>