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

Elemental area stop rendering after save/publish clicked #1293

Closed
2 tasks done
satrun77 opened this issue Dec 12, 2024 · 4 comments
Closed
2 tasks done

Elemental area stop rendering after save/publish clicked #1293

satrun77 opened this issue Dec 12, 2024 · 4 comments

Comments

@satrun77
Copy link
Contributor

satrun77 commented Dec 12, 2024

Module version(s) affected

5.3.3

Description

When a content author is too fast to click the save or publish button before the elemental areas are completely rendered, the buttons get stuck in the loading animation and the elemental area fields don't render.

Related issue: silverstripe/silverstripe-admin#1871
The PR #1294 seems to resolve the issue in silverstripe-admin

How to reproduce

  1. Install fresh CMS
  2. Add Elemental module
  3. Create a data object with version and more than one elemental area
use DNADesign\Elemental\Extensions\ElementalPageExtension;
use DNADesign\Elemental\Models\ElementalArea;
use SilverStripe\ORM\DataObject;
use SilverStripe\Versioned\Versioned;

class SomeObject extends DataObject
{
    private static string $table_name = 'SomeObject';

    private static array $db = [
        'Title' => 'Text',
    ];

    private static array $has_one = [
        'BlockArea' => ElementalArea::class,
        'BlockArea2' => ElementalArea::class,
    ];

    private static array $extensions = [
        Versioned::class,
        ElementalPageExtension::class,
    ];
}
  1. Create a model admin for the data object.
use SilverStripe\Admin\ModelAdmin;

class SomeAdmin extends ModelAdmin
{
    private static string $url_segment = 'objects';

    private static string $menu_title = 'Objects';

    private static array $managed_models = [
        SomeObject::class,
    ];
}
  1. Open browser console > Network tab
  2. You will see multiple requests for /admin/graphql for each elemental area
Screenshot 2024-12-11 at 1 50 16 PM
  1. Click publish just before all of the requests are completed, and you will see the pending ones changed to cancelled. The requests may load fast, which makes it hard to replicate. I edited the controller SilverStripe\GraphQL\Controller, and added sleep(1); to index method to slow down the request.
Screenshot 2024-12-11 at 1 50 55 PM
  1. The buttons keep on animating and you can't click it again.
  2. Elemental areas are not rendered in the CMS
  3. The console display errors related to accessing map on null
Screenshot 2024-12-13 at 10 45 33 AM

Possible Solution

#1294

Additional Context

No response

Validations

  • Check that there isn't already an issue that reports the same bug
  • Double check that your reproduction steps work in a fresh installation of silverstripe/installer (with any code examples you've provided)

PRs

@GuySartorelli
Copy link
Member

IS this actually distinct from silverstripe/silverstripe-admin#1871? Or are these two actually the same bug just described in different ways?

@satrun77
Copy link
Contributor Author

IS this actually distinct from silverstripe/silverstripe-admin#1871? Or are these two actually the same bug just described in different ways?

Not sure 😅

The PR for this issue is to ensure the code does not call the method map on null. This does seem to "resolve" the issue in the admin dependency! I feel this change might not be the correct fix for the issue silverstripe/silverstripe-admin#1871 but I could be wrong!

@GuySartorelli
Copy link
Member

Okay. Sounds like this issue is specifically about the elemental areas not loading fully after the publish button is pushed (basically a "workaround" issue) whereas the other issue is about the fact that the buttons shouldn't be pushable at all until the page form is fully ready to be submitted.

As I mentioned on the other issue I don't know if there's a sensible way to fix that with the current architecture - so this issue does seem worth fixing in its own right.

@GuySartorelli
Copy link
Member

PR merged, will be automatically tagged by GitHub Actions

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

No branches or pull requests

2 participants