[buddypress-trac] [BuddyPress Trac] #5919: Xprofile field meta values not deleted with field

buddypress-trac noreply at wordpress.org
Mon Oct 6 21:41:59 UTC 2014


#5919: Xprofile field meta values not deleted with field
--------------------------+------------------
 Reporter:  tometzky      |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  high          |   Milestone:  2.2
Component:  XProfile      |     Version:  2.1
 Severity:  major         |  Resolution:
 Keywords:  needs-patch   |
--------------------------+------------------

Comment (by boonebgorges):

 > This regular expression is too write only for me.

 Yes, it's a bit opaque. The idea is to find all instances of quoted text,
 because that's where all input from outside the system will appear. That
 regex is actually pretty simple: `/'(.*+)'/` or something like that. The
 problem is that this quoted text might contain escaped quotes (`...WHERE
 meta_value = 'I said \'hello\' to him'...`). The extra complexity in the
 regular expression is to account for this. I've borrowed it from
 http://stackoverflow.com/questions/5695240/php-regex-to-ignore-escaped-
 quotes-within-quotes.

 > And it assumes that there's only one quoted text, which I'm not
 convinced that it is.

 No, this accounts for all quoted text. See the use of `preg_match_all()`.

 > I'd rather use some random placeholder like uniqid('__QUOTE__').

 I believe this is unnecessary. The only important thing about the
 placeholder text is that it not match any of the substrings we're going to
 replace using str_replace(). In other words, when we translate

 {{{
 UPDATE wp_bp_xprofile_meta SET meta_value = 'PLEASE GO SOMEWHERE ELSE'
 WHERE object_id = '24' AND meta_key = 'validate_with_regex_error_message'
 }}}

 into

 {{{
 UPDATE wp_bp_xprofile_meta SET meta_value = __QUOTE__ WHERE object_id =
 __QUOTE__ AND meta_key = __QUOTE__
 }}}

 we have done enough to assure that things like `str_replace( 'WHERE', ...`
 will not catch any false positives.

 > If I remember correctly, we've only done this because our meta tables
 have a different schema than WP core's post/usermeta tables.

 This is true for `bp_filter_metaid_column_name()`, and it's worth looking
 into. We still need to manipulate the SQL for xprofile clauses in order to
 insert an `object_type = 'field'` clause.

--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/5919#comment:8>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac


More information about the buddypress-trac mailing list