[4.x]: Unable to delete Sections or Entry Types

[lindseydiloreto]

What happened?

Description

It seems to be impossible to delete sections and entry types in Craft 4.

By the looks of it, the ‎Sections::deleteEntryType method isn't actually deleting anything...

cms/src/services/Sections.php

Lines 1323 to 1334 in 5d6f656

	public function deleteEntryType(EntryType $entryType): bool
	{
	// Fire a 'beforeDeleteEntryType' event
	if ($this->hasEventHandlers(self::EVENT_BEFORE_DELETE_ENTRY_TYPE)) {
	$this->trigger(self::EVENT_BEFORE_DELETE_ENTRY_TYPE, new EntryTypeEvent([
	'entryType' => $entryType,
	]));
	}
	Craft::$app->getProjectConfig()->remove(ProjectConfig::PATH_ENTRY_TYPES . '.' . $entryType->uid, "Delete the “{$entryType->handle}” entry type");
	return true;
	}

Steps to reproduce

1. In Craft 4, create a section and/or entry type.
2. Try to delete that section and/or entry type.
3. Refresh the page to see that it still exists!

Expected behavior

Deleting a section/entry type should delete the section/entry type.

Actual behavior

Deleting a section/entry type does not delete the section/entry type.

Craft CMS version

4.14.11.1

PHP version

No response

Operating system and version

No response

Database type and version

No response

Image driver and version

No response

Installed plugins and versions

[brandonkelly]

Both are deleting successfully on my end.

By the looks of it, the ‎Sections::deleteEntryType method isn't actually deleting anything...

That method removes the entry type’s config from the project config. craft\services\Sections::handleDeletedEntryType() will end up getting called in turn, which handles the actual database row (soft) deletion.

Refresh the page to see that it still exists!

Sounds like maybe your project config is out of sync with the database somehow. Can happen if the section/database is added to the database directly, for example.

Try running php craft pc/rebuild first, and then delete the section/entry type.

[lindseydiloreto]

Good catch, thanks! This was caused by the project config being out of sync. When I re-sync it, I'm able to then properly delete the section. 👍

In other words, my delete logic was fine. It's my create section logic that is flawed (by not writing to project config).

Weirdly, my "save section" code is pretty straightforward:

// Create the section
$section = new Section($config);

// Always successful, but doesn't update the project config
$success = Craft::$app->getSections()->saveSection($section);

When I trace through the save logic with xdebug, it looks like my problem is happening in the Project Config service...

cms/src/services/ProjectConfig.php

Lines 1521 to 1532 in 4a98471

	/**
	* Save configuration data after the request.
	*/
	private function _saveConfigAfterRequest(): void
	{
	$this->_updateYaml = true;
	// Are we too late for EVENT_AFTER_REQUEST?
	if (Craft::$app->state >= Application::STATE_AFTER_REQUEST) {
	$this->saveModifiedConfigData();
	}
	}

Line 1529 fails, because Craft::$app->state is set to STATE_HANDLING_REQUEST (3) instead of STATE_AFTER_REQUEST (4).

Therefore, $this->saveModifiedConfigData() never gets called, and the new section doesn't get written to the YAML files.

Any thoughts on what I'm missing? It seems like I probably shouldn't be setting Craft::$app->state manually... did I skip an important step?

Should I be calling Craft::$app->getSections()->handleChangedSection() manually somehow?

Thanks for enlightening me on the magic of project config! 🙏

[brandonkelly]

Is your controller aborting the request prematurely?

That condition is just there as a safeguard, in case the config change occurs toward the very end of the request, after the Application::EVENT_AFTER_REQUEST event has already been triggered. If state is still STATE_HANDLING_REQUEST, then it’s expected the condition won‘t pass, and the modified config will be written out when Application::EVENT_AFTER_REQUEST is triggered later on.

[lindseydiloreto]

It isn't happening in a controller, it's being triggered by a service and a static helper function.

Perhaps EVENT_AFTER_REQUEST isn't being called at all?

[brandonkelly]

EVENT_AFTER_REQUEST is definitely triggered on all normal requests, unless something calls Craft::end() / die() / exit() prematurely.

[lindseydiloreto]

Ahh, interesting... I guess it's worth noting that this is happening during an SSE request, where "the line stays open" so to speak.

I recognize that this is a special case. What's my best course of action for a workaround?

[brandonkelly]

I sse. I guess you could start calling Craft::$app->projectConfig->saveModifiedConfigData() after making changes that could affect the config, then.

[lindseydiloreto]

As long as that feels reasonably safe to you, that works for me.

Thanks for your guidance @brandonkelly! 🍺