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

After import database, menu disappears #8307

Closed
kirrg001 opened this issue Apr 11, 2017 · 2 comments · Fixed by TryGhost/Admin#658 or TryGhost/Admin#707
Closed

After import database, menu disappears #8307

kirrg001 opened this issue Apr 11, 2017 · 2 comments · Fixed by TryGhost/Admin#658 or TryGhost/Admin#707
Labels
affects:admin Anything relating to Ghost Admin bug [triage] something behaving unexpectedly

Comments

@kirrg001
Copy link
Contributor

After successfully importing a database, the menu disappears.
I did a refresh rebuild on the client. I can see an error in the browser debug console.

menudis

Ghost: master

@kirrg001 kirrg001 added the bug [triage] something behaving unexpectedly label Apr 11, 2017
@kevinansfield kevinansfield added this to the 1.0.0 Beta Ready milestone Apr 17, 2017
kevinansfield added a commit to kevinansfield/Ghost-Admin that referenced this issue Apr 19, 2017
closes TryGhost/Ghost#8307
- unloading the store and refreshing the session.user attribute after an import was triggering an odd rendering edgecase where the style was re-computed and a re-render was attempted after the sidebar has been destroyed
- rather than binding a style attribute directly to a CP in `gh-nav-menu` we pass in the menu icon and manually set the style attribute on the `didReceiveAttrs` hook so that outside changes don't trigger re-computations when we don't expect them and so we can still react to icons being uploaded or removed
- our usage of `settings.icon` is a bit of an odd situation because it's a link to an external resource that will only resolve correctly after a successful save - if we change `settings.icon` in the local store and the nav menu icon style updates before the save has been completed then the server will give us the old icon. To work around this a `settings.settledIcon` attribute has been added that is only updated when we receive data from the store ensuring that our cache-busting technique works correctly
kevinansfield added a commit to kevinansfield/Ghost-Admin that referenced this issue Apr 19, 2017
- unloading the store and refreshing the `session.user` attribute after an import was triggering a rendering edge case where the style was re-computed and a re-render was attempted after the sidebar has been destroyed
- rather than binding a style attribute directly to a CP in `gh-nav-menu` we pass the menu icon in (using `settings.settledIcon` - see below) and manually set the style attribute via the `didReceiveAttrs` hook so that outside changes don't trigger re-computations when we don't expect them and so we can still react to icons being uploaded or removed
- our usage of `settings.icon` is a bit of an odd situation because it's a link to an external resource that will only resolve correctly after a successful save - if we change `settings.icon` in the local store and the nav menu icon style updates before the save has been completed then the server will give us the old icon. To work around this a `settings.settledIcon` attribute has been added that is only updated when we receive data from the store ensuring that our cache-busting technique works correctly
kirrg001 pushed a commit to TryGhost/Admin that referenced this issue Apr 19, 2017
closes TryGhost/Ghost#8307

- unloading the store and refreshing the `session.user` attribute after an import was triggering a rendering edge case where the style was re-computed and a re-render was attempted after the sidebar has been destroyed
- rather than binding a style attribute directly to a CP in `gh-nav-menu` we pass the menu icon in (using `settings.settledIcon` - see below) and manually set the style attribute via the `didReceiveAttrs` hook so that outside changes don't trigger re-computations when we don't expect them and so we can still react to icons being uploaded or removed
- our usage of `settings.icon` is a bit of an odd situation because it's a link to an external resource that will only resolve correctly after a successful save - if we change `settings.icon` in the local store and the nav menu icon style updates before the save has been completed then the server will give us the old icon. To work around this a `settings.settledIcon` attribute has been added that is only updated when we receive data from the store ensuring that our cache-busting technique works correctly
@kirrg001
Copy link
Contributor Author

I have this again with current master.

Browser: Chrome latest

vendor-31e12f4f0bae6fdbe7f5794679b80357.js:42846 TypeError: Cannot read property 'eachAttribute' of null
    at new Snapshot (vendor-31e12f4f0bae6fdbe7f5794679b80357.js:203971)
    at InternalModel.createSnapshot (vendor-31e12f4f0bae6fdbe7f5794679b80357.js:197924)
    at _find (vendor-31e12f4f0bae6fdbe7f5794679b80357.js:206828)
    at Class._fetchRecord (vendor-31e12f4f0bae6fdbe7f5794679b80357.js:204834)
    at _fetchRecord (vendor-31e12f4f0bae6fdbe7f5794679b80357.js:204895)
    at Class._flushPendingFetchForType (vendor-31e12f4f0bae6fdbe7f5794679b80357.js:204996)
    at cb (vendor-31e12f4f0bae6fdbe7f5794679b80357.js:44417)
    at OrderedSet.forEach (vendor-31e12f4f0bae6fdbe7f5794679b80357.js:44222)
    at MapWithDefault.forEach (vendor-31e12f4f0bae6fdbe7f5794679b80357.js:44425)
    at Class.flushAllPendingFetches (vendor-31e12f4f0bae6fdbe7f5794679b80357.js:204876)

@kirrg001 kirrg001 reopened this May 22, 2017
@kirrg001 kirrg001 removed this from the 1.0.0 Beta Ready milestone May 22, 2017
@kirrg001 kirrg001 added the affects:admin Anything relating to Ghost Admin label May 22, 2017
@kirrg001
Copy link
Contributor Author

kirrg001 commented May 22, 2017

This commit broke the menu after importing again.

TryGhost/Admin@16438f8

Update: With ember 0.12.1 and ember-data 0.12.1 the bug is resolved. See also emberjs/data#4963, this looks very similar.

kevinansfield added a commit to kevinansfield/Ghost-Admin that referenced this issue May 23, 2017
closes TryGhost/Ghost#8307
- Ember 2.13 has a behaviour change to `store.unloadAll` where the records aren't removed until later in the runloop resulting in errors if the store is used to find records before it's completed. See emberjs/data#4963
kirrg001 pushed a commit to TryGhost/Admin that referenced this issue May 23, 2017
closes TryGhost/Ghost#8307

- Ember 2.13 has a behaviour change to `store.unloadAll` where the records aren't removed until later in the runloop resulting in errors if the store is used to find records before it's completed. See emberjs/data#4963
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
affects:admin Anything relating to Ghost Admin bug [triage] something behaving unexpectedly
Projects
None yet
2 participants