Deprecated - Drupal core

For me it is annoying that web surfers can see the order of nodes created, the actual node ID in the URL, e.g. /node/42 or /node/4711.
I would like to have encrypted IDs, e.g. an URL like /node/x7k392s03fg3tl29fd02, with some non-public encryption key that translates this string to 42 or 4711 again, so that no-one gets a hint on how much content I actually have on my site (unless they hack my server and get the decrypt key of course). Wouldn't this be a simple encryption feature to add to the core?

(This came from a conversation at OSCMS and the explosion of contrib aggregation modules. po)

To support multiple modules for pulling RSS and ATOM (and other) web feeds into Drupal, the following functions need to be supported in a core Aggregator API. In Drupal 5.1, all Aggregator.module functions are internal to the module and cannot be accessed by contributed modules. This results in duplicate code and opens potential security risks.

Below is an outline of the API functions needed by external aggregation modules. These recommendations are based on the Feed handling elements of the contributed MySite module.

feed_form($settings = array('title', 'url'))
A simple form element that returns the TITLE and URL elements for adding a new feed to a Drupal site. Optionally, this function might return all the settings that an administrator has access to (including refresh rate and category settings).

feed_verify($url, $title)
A submit hook that will check a submitted URL to see if it returns a valid XML feed. A necessary stage in processing new feeds before saving.

feed_parse($feed)
Parses the feed into the elements defined by the aggregator API (see feed_store($feed), below).

feed_check($url, $title)
Check a TITLE or URL for duplication against existing feeds.

feed_update($feed)
Updates the requested feed.

feed_title($title)

There is an issue at http://drupal.org/node/124366 outlining the use of correct language codes for the two Norwegian languages. Does anyone know if this will be implemented in 6.x?

Hello,

First at all, i have to apologize for my bad english (I'm not a native speaker :( )...

I searched for some datetime element (not CCk) for Drupal, to get integrated to my custom module. Because I did not find any, I'm now working on a datetime.module. (First step on this was http://drupal.org/node/37405)

My first aim will be to get the module integrated in my own site (it only uses a single uncustomizable timezone).
If there was demand on further development, it would nice to get some feedback and/or help from you.
(The current developping status of datetime.module can be downloaded at http://derhasi.de.3.kunden-server.org/files/datetime.rar)

This datetime.module integrates a datetime element type. It extends the date element with a lot more features.

Some specification of that (plus excerpt of datetime process function description):

• Single child elements ('year','month','day','hour','minute','second') can be disabled
• Default values for each child element can be set
• Prefix and suffix for each child element can be set
• Output array is extended by timestamp, sql-date, sql_datetime and format_date values
• ...

Another possible extensions could be:

• child element: timezone selection field
• output value: timezone


/**

Hi all,
just throwing an idea out to get some opinions. What I would like to suggest is a patch to the translation function t() which would allow end user modification/customization of drupal messages as well as the possibility of drupal's intrinsic search locating hard coded pages with messages matching a specified search criteria. I also envision this has some applications for customizable multilingual message support.

Yes in many ways this is what the php gettext() already provides but this implementation would be db driven, UI customizable and even better, text searchable.

I imagine this would work by patching t() so that messages are hashed and stored into a db message table containing the hash as well as the original message. Users would have an admin UI for customizing any of drupal's messages. Their new modified messages would be stored in the message table alongside the original message where t() would find and return them. The original messages can be reverted to at anytime using a reset option.

Hello,
I have been finding that the options available to customize and alter the search performance are lacking. For instance, my site has node types that I do not want included in my search index. I would think it would be simple and useful to have in the search configuration the ability to exclude certain node types from indexing and searching.