← All changes | includes/abilities/settings/class-update-site-identity-settings.php +24 -1 2.3.0 → 2.9.0 View file →

		@@ -40,9 +40,16 @@
40	40	*/
41	41	public function get_annotations() {
42	42	return [
43	43	'readonly' => false,
44		- 'destructive' => true,
	44	+ // Settings writes are recoverable: the matching get-* ability reads
	45	+ // the previous value, so nothing is lost that cannot be put back.
	46	+ // `destructive` is reserved for calls that lose data or reach
	47	+ // outside the site, and marking routine configuration with it made
	48	+ // MCP clients demand a human approval for every save — which users
	49	+ // reported as a permission bug, because the client's refusal reads
	50	+ // as "No approval received" (#675).
	51	+ 'destructive' => false,
45	52	'idempotent' => true,
46	53	'priority' => 2.0,
47	54	'openWorldHint' => false,
48	55	];
		@@ -124,8 +131,24 @@
124	131
125	132	$result = $mgr->save_settings( 'site', null, $merged );
126	133
127	134	if ( $result ) {
	135	+ // Mirror the REST route (class-site-identity-endpoint.php): a stored
	136	+ // setting is not the served file. When a physical robots.txt exists,
	137	+ // it keeps serving the previous body — and the previous allow/block
	138	+ // set — until it is rewritten, so an agent that blocked GPTBot got
	139	+ // `success: true` while the crawler was still allowed. Worse,
	140	+ // get_robots_txt_delivery() strips the AI block before comparing, on
	141	+ // the assumption the two are identical by construction, so the admin
	142	+ // screen reported "in sync" over the drift. Only the keys that
	143	+ // change the served output trigger the write.
	144	+ if ( array_key_exists( 'robots_txt_content', $patch )
	145	+ || array_key_exists( 'robots_txt_enabled', $patch )
	146	+ || array_key_exists( 'ai_crawler_rules', $patch )
	147	+ ) {
	148	+ $mgr->sync_robots_txt_file();
	149	+ }
	150	+
128	151	return [
129	152	'success' => true,
130	153	'message' => __( 'Site identity settings updated.', 'thinkrank' ),
131	154	];