Users getting wiped out

[spaceageliving]

Having an issue since the 3.4 update with user getting clobbered.

I believe this is occurring when running a composer update?

I have a custom user blueprint (to support an avatar field), eg:

name: 'Jason T.'
roles:
  - user
groups:
  - user
avatar: 519noziiujl__sl500_aa300_.jpg
id: 3174a064-b8e0-49ea-b80d-0e54df4daeee
password_hash: -----------------------

Then (I believe) following a composer update, this file gets clobbered down to just the id:

id: 3174a064-b8e0-49ea-b80d-0e54df4daeee

This happens to all of my users....

What is going on here? Is statamic running a post-install script that is doing this? How to avoid?

[duncanmcclean]

Do you have any addons installed - does this happen when updating to any 3.4 version?

[spaceageliving]

These are the addons...I've only updated to 3.4.4, so can't say about previous versions:

[jasonvarga]

What about custom app code? Event listeners, etc?

[spaceageliving]

I setup a public signup page that calls a register method in a UserController, fires a 'UserRegistered' event, assigns user/role, saves the user.

The UserRegistered event invokes $event->user->generateTokenAndSendActivateAccountNotification()...I hijacked the CP user account creation notification email.

That's all so far...

[edalzell]

You can try by removing this line from your composer.json.

[spaceageliving]

I removed that command, ran a composer update, nothing was updated (because I ran it a few hours ago), and Users were untouched.

Are there other consequences I should be aware of in the future by having this command removed?

[spaceageliving]

I've only seen this happen locally....thankfully. I'm pretty sure it is happening after running composer update, because I have been removing and then reinstalling an add-on (Bard Text Align, another issue with 3.4) and that's when this issue pops up. The only other thing I do is run 'please cache:clear' and 'please stache:warm' after pulling/merging.

When deploying via Forge, that script runs composer install (not update), and this is the only difference I can think of why this is occurring locally only so far. I reviewed the latest Forge deployment and it does run the artisan statamic:install command during deployment.

[jasonvarga]

Would you be able to provide access to your 3.3 site so we could try the upgrade ourselves? I've never heard of this before and don't see any reason why it would be happening.

[spaceageliving]

Just sent you an invite, Jason. I’m actually more concerned with the Bard issue and text alignment problem from yesterday ;) I still can’t get the alignment controls for the bard text align add on to appear. I’m leaning towards removing the add on, using the native 3.4 controls and repairing the 75 entries that have the old markup. Maybe you can shed some light on this situation while running the update. Note that the current master head has be updated to 3.4.

[jasonvarga]

@JohnathonKoster Do you know if Meerkat could be causing this?

[spaceageliving]

@jasonvarga @edalzell Hi Jason, Erin. I've been experiencing this issue again. It may not be related to v3.4, but it does seem to be happening frequently now since the update. I thought that there was possibly an issue with my git pull config/merge settings, but now it appears to be more to do with cache clearing and stache warming?

I'm the only dev on this site. My typical workflow when I make any code changes is use the Git tool in utils to push latest changes on production to GitHub, then pull origin/master to my local system. Then make changes, commit, push to GH, deploy to production with Forge.

After a pull from GH to my local system, everything looks fine:

Then clear the statamic cache:

Then warm the stache, and most/all of my users get nuked:

A nuked user goes from a typical yaml look for a statamic user with several fields, eg. id, name, email, types/roles, password hash to just a single line in the yaml with an id (which is newly assigned):

I tried clearing the Laravel cache with artisan cache:clear and that seemed to resolve for a bit, but then same issue resurfaced.

I've only seen this behavior happen on my local dev environment (thankfully!), but my production server is basically doing the same sequence (pull, please cache:clear, please stache:warm)...praying this doesn't start happening on production.

Any ideas/suggestions?

[spaceageliving]

Here's another one to twist your brain...after (again) resetting head to origin/master, I ran 'php artisan statamic:stache:doctor' just for kicks. Got the 'Call to a member function requiresSlugs()' error. Reset the cache with 'php please cache:clear', ran 'php artisan statamic:stache:doctor' again, error is gone, BUT one user gets nuked--mine only! Keep in mind the local site is untouched while this is happening--just the updated head to match origin. Very odd: