Bulk delete "Users" should not delete aliases for user/register, user/login or user/password [#1359306]

Title says it all... only user/n where n is an integer, should be deleted. Am using 6.x-1.5 but code looks identical in latest 6.x dev and 7.x branches.

// Problem arises in the case $internal_name and $key = 'user/', in functions pathauto_admin_delete()
// and pathauto_admin_delete_submit().

$count = db_query("SELECT count(1) FROM {url_alias} WHERE source LIKE :src", array(':src' => "$internal_name%"))->fetchField();

...

db_delete('url_alias')
          ->condition('source', db_like($key) . '%', 'LIKE')
          ->execute();

Comments

Comment #0.0

gpk commented 2 December 2011 at 14:03

Issue summary:

View changes

amplify.

Comment #1

dave reid

he/him

English

Nebraska USA

commented 2 December 2011 at 14:35

Category:

support

» bug

Have any ideas on how this should be handled properly?

Comment #2

gpk commented 2 December 2011 at 18:26

Well the current code is very concise - wld be a shame to over-complicate it.

Is it possible to use REGEXP pattern matching instead of LIKE in the query condition?

Alternatively we could explicitly rule out those 3 specific paths... messy but not too hard. I wonder - are there other aliases where the source/src should be excluded from the bulk delete? e.g. node/add/* ??? Unless we can use REGEXP not quite sure how best to handle all this cleanly.

OK a quick look in the MySQL manual suggest the best bet in these cases might be to strip off the node/ or user/ part using SUBSTR function then check if what we have left is an integer. Not sure how to do the latter within a query...... Also would need smarter code to cope with blog/n/feed syntax etc.

Comment #3

dave reid

he/him

English

Nebraska USA

commented 2 December 2011 at 18:24

Likely this just needs to turn into a bulk operation which deletes records by grabbing all the possible UID columns from the {users} table. Same for nodes, etc.