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

Stream DB tables cannot be trusted to exist #128

Closed
1 task
kadamwhite opened this issue Sep 16, 2021 · 7 comments
Closed
1 task

Stream DB tables cannot be trusted to exist #128

kadamwhite opened this issue Sep 16, 2021 · 7 comments
Labels
bug Existing functionality isn't behaving as expected

Comments

@kadamwhite
Copy link

kadamwhite commented Sep 16, 2021

The Stream plugin only creates its tables on activation, and the way it is used in this project, that step will never necessarily be hit. This means that (especially in local environments) you can end up in a situation where you have no DB tables for stream, and your errors are littered with warnings about it.

Steps to reproduce:

  1. composer server cli -- db clean and reinstall your local install, or import a database
  2. Observe that you begin to see errors like this in your logs:
WordPress database error Table 'wordpress.wp_stream' doesn't exist

I would expect to see no errors of this type, because I would expect the Altis Security module to orchestrate ensuring the tables are present if they did not previously exist.

As a stopgap for now, you can manually recreate these tables by invoking the stream plugin activation directly:

wp_stream_get_instance()->install->check();

Acceptance criteria:

  • Stream tables are created if not present, especially in local environments, with no interaction from the developer

Shout-out to @tomjn for figuring this one out, this issue documents discussion we just had in Slack. Tom has opened a related issue on the upstream Stream repo (two of them, actually), but this is something we could fix at this level, too.

@kadamwhite kadamwhite added the bug Existing functionality isn't behaving as expected label Sep 16, 2021
@roborourke
Copy link
Contributor

This has been added to the wp altis migrate command added in Altis v8, is this affecting an older version of Altis?

@kadamwhite
Copy link
Author

@roborourke I've observed it on a local Altis 8 environment after restoring a production database, from an environment where wp altis migrate was run previously.

@kadamwhite
Copy link
Author

Looks like @tomjn's PR xwp/stream#1286 (which creates these tables if they don't exist when a user visits wp-admin) has been merged, so this should be a non-issue after the next time we upgrade our stream dependency

@roborourke
Copy link
Contributor

I've observed it on a local Altis 8 environment after restoring a production database, from an environment where wp altis migrate was run previously.

Hm, it's possible it was run on v8 before the 8.0.1 patch was released...

It shouldn't be possible now but guess I'm still missing something 🤔

@tomjn
Copy link

tomjn commented Sep 17, 2021

v3.8.1 is out which contains my change xwp/stream#1284 (comment), it looks like this issue was introduced in either 3.7 or 3.8 to fix an issue wth excessive SHOW commands on the frontend from checking for tables

@roborourke
Copy link
Contributor

Altis v8+ tracks XWP stream ^3.7.0 so a composer update can get 3.8.2.

@roborourke
Copy link
Contributor

Closing out as Altis v7 is back on Stream 3.4 on the HM fork.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Existing functionality isn't behaving as expected
Projects
None yet
Development

No branches or pull requests

3 participants