See the Mailing lists or Drupal Issue queue. There are also various working groups on groups.drupal.org

Access Permissions appear to be cached

I have a newish setup (4.6.2) and have encountered an odd caching problem.

If I log in as administrator (account 1) I have access to administration etc. as expected. If I then logout - the administration choice still appears in the navigation menu and when I click on it (logged out at this point) I can still access all the admin pages (although I can't update anything!). If I clear the MYSQL cache ("delete from cache") normal service is resumed and I can't access the admin pages (which is the correct behaviour).

a suggestion: better usability with this Ajax script.. possible?

I was looking to the Modules page
http://drupal.org/project/Modules
It seems its very long list of modules.. which is excellent!, but you have to scroll down a lot.. Could it be any improvement when there is a long list an Ajax fold down can be introduce and people can click on/off the title and they see the teaser/summary and the relevant links and options? -and it feels and works faster than regular scroll down page

Help by closing or verifying old bug reports

You do not need programming skills, just a fair amount of Drupal experience and some time. There are a large number of older bug reports marked CVS that have not been closed out over time ago and may no longer be relevant. Here are the steps:

  1. Download and install Drupal HEAD on a test site.
  2. Visit the pending bugs list and start with the oldest reports.
  3. If a bug is marked as 4.5 or cvs, check if it still applies to the current HEAD version you downloaded.
    • if it still applies, then set the version to cvs (if there is more than one cvs in the version menu, pick the first)
    • Click the follow up link and update the bug report with your findings so that work is not duplicated.
    • if the bug can no longer be reproduced as it is fixed or just no longer applies (several screens are reworked in HEAD), just change the status to fixed and update the comments acordingly.
  4. If bug report version is marked as 4.6, then just follow up whether the bug still exists in HEAD and update accordingly with a comment "exists in current HEAD". If you feel like verifiying if the bug has been corrected in 4.6.2 then go ahead but the current focus is to clean up the oldest ones first.

A newbee tells his story...

Hello @all,

i am very new to Drupal.

Before starting using it I used CMSMadeSimple a short Time, tested out Mambo and started to write my own CMS.

But then I decided reinventing the wheel is not the best idea and went back to Drupal, which I knew already but wanted to test it now...

I want to tell you my impression that you can think about it and maybe implement some of them if you think that's are great (and working) ideas.

I am using Drupal 4.6.2 German

  1. Administration

    • I am missing a Mainsite for the Administration.
      which welcomes you there friendly and gives you a starting point for your dayly job. which shows you some more general statistics.
      about the number of visitors today, the number of errors, the last posts... pot this logger in an own menu-point.
    • Give the Administration-Area a own Theme
      Why?
      because then it doesn't anymore depend on the style of the site.
      some templates are too small for the content of the admin-sites (namely: leaf)
      it coud pe made to fit the admin needs and not to fit the style needs of the officially visible style needs.
    • clean up the admin interface.
      put functions of modules to the modules page and let them be accesed from there. so it would look more clean.

  2. create content

    • I don't get the difference of an Article and a static page...
      maybe I'm just stupid but in the default configuration of Drupal and the Configuration I'm testing now I cant see any differences...
      please make this more visible - from the begining on.
    • make everything except of the most important fields of the create Article/static page collapsable (and collapsed by default)
      as you can see it on the menu_otf-module.
      the create-content site would look more friendly and not so overloaded.
    • maybe seperate it in many different Tabs.

      First one "Main", just for the Title and the Article, with a JavaScript button which inserts this Excerpt-comment-thing (do you know it's nowhere mentioned, that this command exists; that has to be more userfriendly...)
      Second one "Organize", with everything arount Taxonomy, Menu-integration and so on.
      Third one "Style", which let you define some special things around the theme.
      Depends on the theme. Maybe the Theme let you define a custom image in the front of every article (maybe to underline your mood & feel or so)

      where you can define special block-fields (with the correct module)
      and so on...

      The fourth one would I call "SEO" - why? I am too bad to find a better word for this. :D

      what do I mean with this?

      there you should be able to define keywords for the drupal-searchengine and the meta-tags.
      Should be able to write an own new description-text for the meta-tags or use the excerpt
      configuring of other meta-tags which are often used. (give the everytime the option to use the default one which are defined somewhere)

      maybe you know more things which should be integrated...
      And here you can see where an own admin-theme has also its benefits...
  3. The Theme and Module thing...

    what comes now?

    I think it wouldnt be bad to be able to redesign every part of a site.

    beginning from the look and feel of the search-site, the presentation of an coment, taxonomy view, the list of the sides which you see on /nodes,
    and every output a module gives, eg the feedback module and so on...

using the url_alias table and arguments

I don't know if this is a bug, because it doesn't appear to be documented anywhere, but if I specify an alias for a node, eg:

alias1 = node/2005

arguments are not permitted on that alias.

While I could use arg(2) if I accessed the node as node/2005/arg2_here, accessing the node as alias1/arg2_here simply returns a page not found.

Is this the correct, intended behavior?

node permissions and node type permissions

The ambiguity of the title just demonstrates what I'm on about. There is a difference, an overlap but probably it is insufficient with the current permission system.

Pages

Subscribe with RSS Subscribe to RSS - Deprecated - Drupal core