Given that this module is focused on developer types, I don't see why it's helpful and it is an avenue for security attacks or breaking your site really well.

CommentFileSizeAuthor
#4 1247672_remove_input_of_php.patch4.38 KBgreggles

Comments

dave reid’s picture

Because the module had to give people a way to replace existing custom_url_rewrite functions :/

greggles’s picture

Meh, the README.txt describes other ways.

Maybe a new branch?

dave reid’s picture

It describes other ways for modules to be *compatible* with url_alter, but the only text relevant to replacing existing custom_url_rewrite functions in your settings.php file is:

If your site has custom_url_rewrite functions in your site's settings.php, you
should remove them before installing the module. It should warn you if you have
the functions needing removal. Once you've removed the functions, you should
enter the code from inside the functions into the URL alter module settings at
admin/settings/url-alter.

...

Q: What if I have my own custom_url_rewrite functions in my settings.php?
A: URL alter will not work unless you remove those functions. Luckily, you can
   copy the code inside those functions and paste them into the URL alter
   module settings (admin/settings/url-alter).

I'd be fine renaming the permission to 'use PHP to administer custom_url_rewrite functions' but at some point we're limited by Drupal's ability to add warnings to permissions in Drupal 6.

greggles’s picture

Status: Active » Needs work
StatusFileSize
new4.38 KB

True enough.

Here's a start. The biggest thing that needs work is the dsm's in the update function. They should ideally watchdog instead of dsm and then the dsm should link to the watchdog messages that contain the code.

dave reid’s picture

Ah I get it - a 2.x branch without the PHP input and just the API. Makes sense to me.