phpcs.xml

<?xml version="1.0"?>
<ruleset name="WP-DBManager">
	<description>WordPress Coding Standards for WP-DBManager.</description>

	<file>.</file>

	<!-- WPCS has no JavaScript sniffs; never let PHPCS touch .js. -->
	<arg name="extensions" value="php"/>
	<arg name="basepath" value="."/>
	<arg name="colors"/>
	<arg value="sp"/>

	<!-- Scanning these makes the CI runner run out of memory. -->
	<exclude-pattern>/vendor/*</exclude-pattern>
	<exclude-pattern>/node_modules/*</exclude-pattern>

	<rule ref="WordPress"/>

	<config name="text_domain" value="wp-dbmanager"/>
	<config name="minimum_wp_version" value="6.8"/>

	<!--
		Everything below relaxes a sniff for the test suite only, and this list
		is closed: it is identical in all nineteen plugins. A sniff firing in
		includes/ is a bug in the code, not a missing exclusion - fix the code.
	-->

	<!-- The tests assert on the plugin's own markup, so they must not escape it. -->
	<rule ref="WordPress.Security.EscapeOutput">
		<exclude-pattern>/tests/*</exclude-pattern>
	</rule>

	<!--
		A test method's name is its documentation - test_a_malformed_range_does_
		not_ban_everyone() gains nothing from a docblock repeating it. Required
		everywhere else.
	-->
	<rule ref="Squiz.Commenting.FunctionComment.Missing">
		<exclude-pattern>/tests/*</exclude-pattern>
	</rule>
	<rule ref="Generic.Commenting.DocComment.MissingShort">
		<exclude-pattern>/tests/*</exclude-pattern>
	</rule>

	<!--
		Test files are named test-*.php by WordPress convention rather than
		class-*.php; the coding standard excepts test classes from that rule.
	-->
	<rule ref="WordPress.Files.FileName.InvalidClassFileName">
		<exclude-pattern>/tests/*</exclude-pattern>
	</rule>

	<!--
		The tests read wp_options directly to assert which rows the migration
		left behind. There is no API for "which rows exist".
	-->
	<rule ref="WordPress.DB.DirectDatabaseQuery">
		<exclude-pattern>/tests/*</exclude-pattern>
	</rule>

	<!--
		The tests drive superglobals to simulate proxy headers and form posts;
		that is the behaviour under test, not unvalidated input.
	-->
	<rule ref="WordPress.Security.ValidatedSanitizedInput">
		<exclude-pattern>/tests/*</exclude-pattern>
	</rule>
	<rule ref="WordPress.Security.NonceVerification">
		<exclude-pattern>/tests/*</exclude-pattern>
	</rule>

	<!-- The tests read the plugin's own source; WP_Filesystem is not appropriate. -->
	<rule ref="WordPress.WP.AlternativeFunctions.file_get_contents_file_get_contents">
		<exclude-pattern>/tests/*</exclude-pattern>
	</rule>

	<!--
		The admin-screen tests install an error handler on purpose: collecting
		the diagnostics is what makes them more than smoke tests.
	-->
	<rule ref="WordPress.PHP.DevelopmentFunctions.error_log_set_error_handler">
		<exclude-pattern>/tests/*</exclude-pattern>
	</rule>

	<!--
		WordPress.DB.DirectDatabaseQuery fires on every $wpdb call and has no
		code-level answer for a plugin that owns a table: wp_ratings, wp_polls,
		the email logs and the useronline table are this plugin family's own
		schema, and core offers no API for them. Seven of the nineteen hit it.

		Scoped to includes/ so it cannot cover a query in a test fixture, and
		deliberately NOT paired with an exclusion for PreparedSQL: interpolating
		into SQL stays an error everywhere, because that one does have an answer.
	-->
	<rule ref="WordPress.DB.DirectDatabaseQuery">
		<exclude-pattern>/includes/*</exclude-pattern>
	</rule>

	<!--
		A WP_List_Table has to read $_GET['orderby'] and $_GET['order'] to sort
		itself. Core builds a sortable column header by swapping those two keys
		on the current URL, so the link carries no nonce and there is nothing to
		verify - every core list table reads them exactly this way.

		The routes to silencing it in code are all worse: filter_input() reads
		the original request rather than $_GET, so the table stops seeing
		anything WordPress or a test has modified; nonce-decorating the sort
		links is theatre; and a POSTed <select> instead of core's sortable
		headers violates 4.3 and 4.4. Sorting changes no state, so this is the
		sniff being wrong rather than the code.

		Scoped to *-table.php so it cannot quietly cover a real handler.
	-->
	<rule ref="WordPress.Security.NonceVerification">
		<exclude-pattern>*-table.php</exclude-pattern>
	</rule>

	<!--
		The settings tests set $hook_suffix, which wp-admin would have set before
		any page callback ran. WP_List_Table's constructor reaches
		WP_Screen::get(), which reads that global, so the test bootstrap has to
		stand in for admin.php.

		Worth re-checking now the floor is WordPress 6.8: this exclusion was
		added for a much older core, and if current WP guards the read, the
		tests can drop the assignment and this rule can go.
	-->
	<rule ref="WordPress.WP.GlobalVariablesOverride">
		<exclude-pattern>/tests/*</exclude-pattern>
	</rule>
</ruleset>