← All changes | Inc/Core/Migrator.php +144 -1 3.1.9 → 3.1.14 View file →

		@@ -1,8 +1,8 @@
1	1	<?php
2	2	/**
3	3	* @package FireBox
4		- * @version 3.1.9 Free
	4	+ * @version 3.1.14 Free
5	5	*
6	6	* @author FirePlugins <[email protected]>
7	7	* @link https://www.fireplugins.com
8	8	* @copyright Copyright © 2026 FirePlugins All Rights Reserved
		@@ -57,8 +57,11 @@
57	57
58	58
59	59	$this->addNewIndexes();
60	60	$this->addSubmissionsIndexes();
	61	+ $this->preserveCampaignRoleAccess();
	62	+ $this->grantExecutePHPCapability();
	63	+ $this->grantExecuteJSCapability();
61	64
62	65	// Update firebox version
63	66	if ($this->run)
64	67	{
		@@ -580,8 +583,148 @@
580	583	$wpdb->query("ALTER TABLE {$wpdb->prefix}firebox_submission_meta ADD INDEX `idx_submission_id` (`submission_id`)");
581	584	}
582	585
583	586	$this->run = true;
	587	+ }
	588	+
	589	+ /**
	590	+ * Keeps existing roles' campaign access working after the campaign post type moved
	591	+ * from core's "post" capabilities to FireBox's own.
	592	+ *
	593	+ * Before this change anyone with edit_posts could edit campaigns. Granting each role
	594	+ * the FireBox capability matching the core capability it already holds preserves
	595	+ * exactly who could do what, so upgrading changes nobody's access.
	596	+ *
	597	+ * Note this deliberately does not grant read_fireboxes: that gates the FireBox admin
	598	+ * screens, was never derived from the post type, and granting it here would hand
	599	+ * roles access they did not previously have.
	600	+ *
	601	+ * Site owners who want to tighten campaign access can now remove these capabilities
	602	+ * and have it actually take effect, which was not previously the case.
	603	+ *
	604	+ * @since 3.1.10
	605	+ *
	606	+ * @return void
	607	+ */
	608	+ private function preserveCampaignRoleAccess()
	609	+ {
	610	+ if (version_compare($this->installedVersion, '3.1.10', '>='))
	611	+ {
	612	+ return;
	613	+ }
	614	+
	615	+ $map = \FireBox\Core\Admin\Includes\Cpts\Firebox::getPostTypeCapabilities();
	616	+
	617	+ // Only the primitive capabilities are assigned to roles.
	618	+ unset($map['edit_post'], $map['read_post'], $map['delete_post'], $map['create_posts']);
	619	+
	620	+ // wp_roles() rather than get_editable_roles(): the latter is admin-only and
	621	+ // undefined on the frontend requests this migration also runs on.
	622	+ foreach (wp_roles()->role_objects as $role)
	623	+ {
	624	+ foreach ($map as $core_cap => $firebox_cap)
	625	+ {
	626	+ if (!empty($role->capabilities[$core_cap]))
	627	+ {
	628	+ $role->add_cap($firebox_cap);
	629	+ }
	630	+ }
	631	+ }
	632	+
	633	+ $this->run = true;
	634	+ }
	635	+
	636	+ /**
	637	+ * Grants the firebox_execute_php capability to administrators.
	638	+ *
	639	+ * This capability gates the PHP display condition and PHP Scripts. It is separate
	640	+ * from the campaign-editing capabilities on purpose, so editing a campaign never
	641	+ * grants the ability to run PHP. Existing installs get it on administrators here;
	642	+ * a site owner can grant it to another role deliberately.
	643	+ *
	644	+ * @since 3.1.11
	645	+ *
	646	+ * @return void
	647	+ */
	648	+ private function grantExecutePHPCapability()
	649	+ {
	650	+ if (version_compare($this->installedVersion, '3.1.11', '>='))
	651	+ {
	652	+ return;
	653	+ }
	654	+
	655	+ $cap = 'firebox_execute_php';
	656	+
	657	+ $admin = get_role('administrator');
	658	+
	659	+ if ($admin)
	660	+ {
	661	+ if (!$admin->has_cap($cap))
	662	+ {
	663	+ $admin->add_cap($cap);
	664	+ $this->run = true;
	665	+ }
	666	+
	667	+ return;
	668	+ }
	669	+
	670	+ // No administrator role on this install: fall back to roles that manage options.
	671	+ foreach (wp_roles()->role_objects as $role)
	672	+ {
	673	+ if (!empty($role->capabilities['manage_options']) && !$role->has_cap($cap))
	674	+ {
	675	+ $role->add_cap($cap);
	676	+ $this->run = true;
	677	+ }
	678	+ }
	679	+ }
	680	+
	681	+ /**
	682	+ * Grants the firebox_execute_js capability to administrators.
	683	+ *
	684	+ * This capability gates campaign-authored JavaScript (the Custom JavaScript
	685	+ * setting and the "Run Javascript" action) alongside unfiltered_html. It exists
	686	+ * so administrators keep custom JS where WordPress withholds unfiltered_html
	687	+ * (multisite site admins, DISALLOW_UNFILTERED_HTML hosts). Like
	688	+ * firebox_execute_php it is separate from the campaign-editing capabilities on
	689	+ * purpose, so editing a campaign never grants it; a site owner can grant it to
	690	+ * another role deliberately.
	691	+ *
	692	+ * @since 3.1.11
	693	+ *
	694	+ * @return void
	695	+ */
	696	+ private function grantExecuteJSCapability()
	697	+ {
	698	+ if (version_compare($this->installedVersion, '3.1.11', '>='))
	699	+ {
	700	+ return;
	701	+ }
	702	+
	703	+ $cap = 'firebox_execute_js';
	704	+
	705	+ $admin = get_role('administrator');
	706	+
	707	+ if ($admin)
	708	+ {
	709	+ if (!$admin->has_cap($cap))
	710	+ {
	711	+ $admin->add_cap($cap);
	712	+ $this->run = true;
	713	+ }
	714	+
	715	+ return;
	716	+ }
	717	+
	718	+ // No administrator role on this install: fall back to roles that manage options.
	719	+ foreach (wp_roles()->role_objects as $role)
	720	+ {
	721	+ if (!empty($role->capabilities['manage_options']) && !$role->has_cap($cap))
	722	+ {
	723	+ $role->add_cap($cap);
	724	+ $this->run = true;
	725	+ }
	726	+ }
584	727	}
585	728
586	729	private function hasIndex($index = '', $table = '')
587	730	{