Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FIX Allow publishing non-inline-editable blocks #1312

Open
wants to merge 1 commit into
base: 5.3
Choose a base branch
from

Conversation

GuySartorelli
Copy link
Member

@GuySartorelli GuySartorelli commented Jan 30, 2025

@@ -165,12 +167,12 @@ const Element = (props) => {

// Publish action
useEffect(() => {
if (formHasRendered && doPublishElement) {
if (doPublishElement) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like this bit should not be getting removed? Checking the formHasRendered is presumably still required for regular inline editable blocks?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops yup this should be using formRenderedIfNeeded. FWIW it doesn't seem to be needed based on my testing and behat - but presumably it was there for a reason and should remain there for the type of element this bug doesn't affect.

@@ -43,6 +43,8 @@ const Element = (props) => {
const [hasUnsavedChanges, setHasUnsavedChanges] = useState(false);
const [publishBlock] = useMutation(publishBlockMutation);

const formRenderedIfNeeded = () => formHasRendered || !props.type.inlineEditable;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Honestly think it's clearer to not have this new method and just update the one place it's used to check && props.type.inlineEditable

Copy link
Member Author

@GuySartorelli GuySartorelli Feb 2, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's used in two places (after I fix #1312 (comment)) - I'd prefer to keep it since it makes those two places clearer to me, but if you still think it's better inlined after seeing it in situ with both conditions, I'll change it.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have converted it from a function to a variable though. Dunno why I thought it should be a function lol

@GuySartorelli GuySartorelli force-pushed the pulls/5.3/publish-noninline-block branch from d931f0a to 28461ef Compare February 2, 2025 23:14
Copy link
Member

@emteknetnz emteknetnz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I performed and updated kitchen sink CI run where there was a failing behat test with the latest PRs - https://github.com/creative-commoners/recipe-kitchen-sink/actions/runs/13148450879

That is not an existing failure - https://github.com/silverstripe/recipe-kitchen-sink/actions/runs/13148969515

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants