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

Configurable entity ignoring #511

Closed
JanVoracek opened this Issue Oct 26, 2015 · 3 comments

Comments

Projects
None yet
2 participants
@JanVoracek
Copy link
Member

JanVoracek commented Oct 26, 2015

This is an imported issue, original reference WP-511, created on 09 Oct 2015.

A user should be able to configure which entities he/she doesn't want to commit - for example, akismet_spam_count or jetpack_protect_blocked_attempts. Another candidate are not approved / spam comments. See e.g. this history from our blog:

11510_useless-commits

One option is to filter them out on the UI level (#161) but with many things, they might not even go into the Git repo.

@JanVoracek JanVoracek self-assigned this Oct 26, 2015

@JanVoracek JanVoracek added this to the 3.0 milestone Oct 26, 2015

@borekb

This comment has been minimized.

Copy link
Member

borekb commented Oct 26, 2015

Related: #512.

Originally commented on 09 Oct 2015.

@borekb borekb added size: m size: l and removed size: m labels Jan 26, 2016

@borekb

This comment has been minimized.

Copy link
Member

borekb commented Feb 3, 2016

From the discussion today:

Use cases

  • The primary use case is still spam comments. We'll ship this filter out of the box.
  • Plugins that are not properly supported might generate INI files that are unwanted. User configurable system could help with this - users would not depend on us shipping the support.

Format

Filter rules would use the mini query language used by the search & filter feature of VP 3.0 (#586). Another question is where to store these rules. We're thinking about two places:

  1. The schema (schema.neon). This would allow us, and in the future other plugins, to ship the default set of rules.
  2. Some user configurable schema-like files. It would probably be a simplified format, sort of like schema but just with the ignoring rules.

An alternative that was discussed was using straight .gitignore. For example, if spam comments were stored in vpdb/spam-comments, they could be ignored by a gitignore rule. This has several major drawbacks:

  1. Only path can express the gitignore route so it's much less flexible then mini query language that we'll support in the schema approach.
  2. We would need to add explicit support for things that should be ignorable - it kind of defeats the point of user configurability.
  3. The INI files would need to be created on the disk - we don't have this limitation with the schema approach.

Entity life cycle with ignoring

  1. Some DB write operation is captured by VersionPress.
  2. The storage checks whether the entity is ignored (some of the filters apply to it) or not. If not, it behaves as today. If it is ignored, this flow continues.
  3. The storage basically exits - does nothing, no INI file is created. Then, at some later point, the entity might come from the ignored state to a normal state. For example, user approves a spam comment as a valid comment.
  4. The UPDATE query hits the storage again. It sees that the entity should now be stored but there's no INI for it yet. No problem, it will do a single SELECT query into the DB, fetch all the entity data and create the INI file.
@borekb

This comment has been minimized.

Copy link
Member

borekb commented Mar 15, 2016

Two things to still do / check:

  • Update wordpress-schema.yml to ignore spam comments by default
  • Whether we correctly support 'Entity life cycle with ignoring' from #511 (comment)

Reopening.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment