Deprecated - Drupal core

I have been using Drupal CVS for a while now. I am very happy to see the way profiles are developing.

One thing that would really increase the usability of profiles was an option for defining the access rights of every field.

Some fields could then be publicly available, while others were only available to users with some specified roles. This would be very usefull together with the new 'Author information' block.

As I understand it, right now it is all-or-nothing. That is, all fields or no fields.

I am new to the Drupal community, but am quite excited by the potential that I see in the work that you have done. I'd like to make a case for better support for multi-lingual sites. I know that quite a lot of work has gone into making the code available in alternate languages, but there are a lot of cases where an organization may want to have more than one.

But first a bit of history. Back-End is a GPL PHP/MySQL CMS which my company, OpenConcept Consulting has been developing now for the last 3-4 years. We initially developed code to make the CMS bilingual because there was a clear need for a few of our clients to have a site which was available in both English & French. We did this by simply adding a few language dependent columns to existing tables. It soon became apparent that although bilingual was good, multi-lingual would be much better, so we began developing a data structure where all of the data could be stored in the language of choice. We have developed English/French, English/Farsi(Persian), English/French/Spanish using this CMS and will be working on an English/French/Farsi/Arabic one shortly.

We have also been developing a number of Take Action tools for this framework. OpenConcept works with a lot of national NGOs, unions & progressive politicians in Canada and the USA.

Hi all,

I was reading a thread in Slashdot about a recent online MD5 Hash Database which can perform hash lookups. To my surprise i've found that some of my drupal password hashes are actually in the database. I thought that drupal performed hashing with some kind of 'salt' element but i've realized this is not true.

I'm wondering if any thought has been given to obscuring the URLs of common net-accessible features, like Trackback and Comments, to make it more difficult to automate comment and trackback spamming?

This works for 4.5 and 4.6 I do believe...it was pretty straightfoward and so far seems to be holding up well. Unfortunately, I couldn't figure out how to do it with hooks - this is a straight edit to pre-existing functions in 4.5 and 4.6's build of node.module. For folks who are heavily using tax terms (especially multiple selections of them), this is as huge help. Also, since it starts saving a tax history at implementation time, it's backward-compatible but not backward-functional.

I have a site with static pages that are also in taxonomy_menu generated menus. For example node/273 is also taxonomy_menu/4/42. drupal_get_path_map() limits us to one alias for each node. There are a couple of possible changes to remove the limitation. here is a description of the one I am using today. Perhaps Drupal code could be changed to allow this extra flexibility.

The main value is for a person with a site that mixes regular pages with pages linked under taxonomy_menu and similar schemes. I have hundreds of pages in a mixture of menus. Part of the problem is the time it takes to convert a static site to a taxonomy based site and part of the problem is that taxonomy does not work everywhere without an assortment of add-on modules and extra code in themes. If a node could have two names, it could be in the static structure until the site is completely taxonimated.