Deprecated - Drupal core

Very quick (hopefully simple) question.

How can I write a module that will manage the contents of multiple pages and/or wildcard URLs? (So, for example, if "mymodule" manages "mysite.com/mymodule", is there any way for it to also manage "mysite.com/mymodule/random/subsection"?

Alternatively, would it be possible to add wildcard support to the alias system? (Ie: "mymodule/*" resolves to "mymodule"?)

Such things would make my life far easier. ;)

I have a big problem.
Many users after registration didn't got the password on thier mails, after while i discovered that the mails sent from the site detected as SPAM.
Not all mail servers do that and not all users !!
May be a problem in my server! or problem in Drupal.
How can i know that my server is not blocked?
and is there any suggestion if there is a problem in Drupal?

Thank you.

First, I apologize for not being involved in this earlier on. I've been immersed in other projects for the past few months and became vaguely aware of the forms API just recently (only after I posted the Formproc module). Below are my comments. I should mention that Formproc is the third form-handling library I've worked on so I'm very familiar with how these things work and the common problems and I feel it would be irresponsible not to address a few issues directly. I'm worried that some serious mistakes are being made. I should also mention that I have not yet had time to study the new API as thoroughly as I would like to before this posting, but I think time is of the essence right (potential RC in a few days?) so forgive me if I've overlooked anything. I've done my best not to.

1) MAJOR CONCERNS

a) The function-call-by-naming-convention approach to validation and execution is not good. It duplicates a problem (with flexibility and security) that exists in FormKit, a Python-based form-processing project I was hired to work on.

• Firstly, a user can forge a form with arbitrary ID and call any function of the form x_execute() or x_validate().
• Secondly, where Drupal has a policy of clean API over backwards-compatibility the distinction of public vs. private functions is crucial for establishing some stability, and where the only method currently available for specifying public vs private is through function name ('_' prefix), this convention would seem to undermine the ability to choose whether execution and validation functions are public or private.
• It ties functionality to names which reduces flexibility and code readability.
• Lastly, it clutters the function namespace in a more serious way than the existing hook functions which at least don't suddenly come into being with each form that's created.

I fail to see the advantage of this approach. It yields nothing but headaches in FormKit (where the first problem was solved by having to manually register callable functions...ugh). Formproc requires no such naming conventions as all behavior is modular and specifiable in the form-defining array.

Put 'node view' in the search box (including the apostrophies) on drupal.org and hit Search.
You will end-up with http://drupal.org/cvs-account page instead of the search results.
At least I do.

Is this a bug or a feature?
--Josef

banner.module has many problems with drupal 4.6.3 beacuse of a more restrictive data validation. One possible solution would be to apply data validation on a module bassis along with the user data validation option. Has anyone thought on this? How would security be affected?

Regarding the dev on: http://drupal.org/node/28604
Hi all,
So far Gerhard and otherss want to queue mails so that they do not take all of the resources of the server. Although this idea will help those who send newsletters that are can be sent later at night it does not help those who need to send the mail immediately.
In my particular case, users who are press agencies measure the time in minutes if not seconds. Therefore, while optimising resources is good, in my case is the least of my priorities.