Development
Threads by month
- ----- 2026 -----
- June
- May
- April
- March
- February
- January
- ----- 2025 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2024 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2010 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2009 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2008 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2007 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2006 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2005 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
September 2005
- 78 participants
- 615 discussions
[drupal-devel] [bug] input formats, unknown column 'format' when format is removed
by syllance 20 Sep '05
by syllance 20 Sep '05
20 Sep '05
Issue status update for
http://drupal.org/node/31467
Post a follow up:
http://drupal.org/project/comments/add/31467
Project: Drupal
Version: cvs
Component: filter.module
Category: bug reports
-Priority: critical
+Priority: normal
Assigned to: Anonymous
Reported by: syllance
Updated by: syllance
-Status: active
+Status: patch (code needs review)
issue is still there after a fresh update to latest head. having double
checked, i dont see any other fix than the one in the proposed patch
(changing table from node to node_revisions).
moving this to 'normal' bug as input formats are not deleted everyday,
and moving to status patch needs code review to include the fix in the
patch queue.
syllance
Previous comments:
------------------------------------------------------------------------
Sat, 17 Sep 2005 13:39:18 +0000 : syllance
Attachment: http://drupal.org/files/issues/filter_remove.patch (871 bytes)
When removing an input format, the filter.module set all nodes that was
using the removed format to the default one. This cause an error with
current head version :
user error: Unknown column 'format' in 'where clause'
query: UPDATE node SET format = 1 WHERE format = 5 in
/drupal/head/sandbox/database.mysql.inc on line 99
After checking, the new node revision system moves the 'format' column
to the 'node_revisions' table, and filter.module still try to change it
in the 'node' table.
imho, the query should be UPDATE node_revisions SET format=1 ..., at
least from what i understood of the new node revision system :)
A patch is attached to make the table change from node to
node_revisions in filter.module.
1
0
Issue status update for
http://drupal.org/node/28604
Post a follow up:
http://drupal.org/project/comments/add/28604
Project: Drupal
Version: cvs
Component: base system
Category: feature requests
Priority: normal
Assigned to: Anonymous
Reported by: Dries
Updated by: noid
Status: patch (code needs review)
Sorry guys for interrupting your discussion, but just wanted to make
sure that batch processing ( that is, to help guys like me whose host
limits the sending of emails to say, 200 per hour) is still not
implemented in Simplenews? From my shallow understanding this is what
you are working on right now? Raised this issue which Dries marked as
duplicate here: http://drupal.org/node/28311 .
Just wanted to make sure that I didn't miss the release of this
feature. Thanks in advance! :)
noid
Previous comments:
------------------------------------------------------------------------
Wed, 10 Aug 2005 12:35:37 +0000 : Dries
It was suggested that we separate the mail backend from the front-end.
We might want to include the mail backend in core as includes/mail.inc.
Then, other modules like massmailer, subscriptions, notify, pm (private
messages), project (project issues), contact, etc. could reuse this
component. The mail.inc file would implement some kind of mail queue
functionality, and modules just add a mail to the mail queue using a
simple /mail API/. In future, the mail backend could deal with bounces
and report back proper status codes. Moreover, mail.inc would be
pluggable so it could be replaced by a more powerful one, or one that
is build specifically for the underlying mail transport (SMTP server).
Furthermore, this would solve issues with how many mails get send
within a specified interval. Like, when more than one module sends out
e-mails it is hard to enforce limitations/restrictions imposed by the
hosting company.
I'm posting this here so you can keep this in mind when working on
simplenews, and to solicit for feedback. Chances are we'll setup an
IRC meeting to discuss this further. Details to follow.
------------------------------------------------------------------------
Wed, 10 Aug 2005 16:15:16 +0000 : Amazon
A good place to start would be to look at existing Mail API's
Pear Mail: http://pear.php.net/package/Mail
Pear Mail tutorial:
http://www.zend.com/pear/tutorials/Mail.php#Heading2
------------------------------------------------------------------------
Wed, 10 Aug 2005 20:21:57 +0000 : walkah
um. +1 and then some. I think this is good... and some good references
from Amazon. I'll throw in one other :
http://phpmailer.sf.net/ - has great mime handling (i've run into
issues with PEAR::Mail's mime handilng in the past, but that was around
2 years ago, and things may have gotten better since then).
Oh - and you don't mention it - but support for multipart / mime
messages would be lovely :)
I'd be interested in / happy to sit in on any IRC discussion as well.
------------------------------------------------------------------------
Wed, 10 Aug 2005 21:40:34 +0000 : robertDouglass
phpmailer++
I've used it and like how easy it is to send both text and html mail.
Did I say html mail? You bet! It's time that we had the option.
------------------------------------------------------------------------
Thu, 11 Aug 2005 05:47:01 +0000 : cyberchucktx
I'm definitely interested.
Hopefully by adding a post to this I'll get notified on new postings
(?)
If not I may miss the IRC ..
I've been doing a lot of work with safe_mode PHPLIST (have posted to
the drupal site somewhee, can dig out the reference if anyone is
interested).
Charlie in TX
------------------------------------------------------------------------
Wed, 17 Aug 2005 08:42:34 +0000 : Dries
It was suggested that mail.inc also provides a HTML to text services.
Lots of modules (newsletter, notify, project) try converting HTML to
text. Having a reusable function makes sense, and will lead to better
conversion routines. XSLT anyone?
------------------------------------------------------------------------
Wed, 17 Aug 2005 12:31:27 +0000 : Grugnog2
+1 for phpmailer
I found it very easy to use - and most importantly for me - it supports
SMTP authentication. As many ISP's will not let you send mail without
using SMTP-auth nowadays it may be worth this feature is incorporated
into the mail.inc API.
- Grug
------------------------------------------------------------------------
Wed, 17 Aug 2005 15:08:43 +0000 : Robert Castelo
For about a year now I've been working on an email newsletter and
announcement module [1]. There's a version in my sandbox commited about
2 months ago which works fairly well. Dan Robinson and Varr Willis at
CivicActions, Moshe Weitzman plus a few others have been testing it,
and I've had lots of positive feedback and feature and bug reports from
them.
A few months ago a realised that there's not much point in putting so
much effort into creating all this functionality, only for it to be
locked away in my module. Better to
Better to create discreet component modules which provide a particular
service, such as bounced email handling, but which can be used by any
other module that also needs that service.
For the last two months I've been working to split functionality into
component services modules and make these services available to all
modules.
One of the biggest challenges was to make these component modules
independent of each other. The only area where I haven't managed this
is some of the database calls - but thanks to a chat with chx I
realised that db_rewrite_sql could be used to handle this very nicely.
This is what I have:
* bounced_email.module - process bounced emails
* html2text.module - convert HTML to plain text equivalent (e.g. list
item becomes "* item")
* identity_hash.module - manages full and partial loggin based on hash
which can be used in email links
* publication.module - defines and packages content of publication,
which could be any kind of publication
* schedule.module - defines and manages schedules, e.g. email sending
schedule
* subscribed.module - manages subscriptions to publications
* templates.module - manage and define templates
What's great is that the component modules are not limited to email,
they could be used to quickly create RSS newsletters, PDF newsletters,
text message newsletters, or even personalised/filtered website
sections.
I haven't made the new component modules available anywhere yet, but
I'll be happy to upload them to contrib and let others get involved.
What would be the best way to commit them - as a single directory? or
each component module in it's own directory?
[1]
http://www.cortextcommunications.com/development/newsletter/features
------------------------------------------------------------------------
Thu, 15 Sep 2005 02:05:18 +0000 : vwX
Attachment: http://drupal.org/files/issues/mailqueue.tar.gz (3.71 KB)
This is a very basic mail queue system I would like to contribute.
There are some changes to other modules that will have to be made such
as changing user.module to use this instead of directly calling the php
mail function and moving mime_header_encoding to mail.inc.
------------------------------------------------------------------------
Thu, 15 Sep 2005 15:25:11 +0000 : killes(a)www.drop.org
Note: I am moving this to the main project.
VwX: What I see looks very nice for a start. Some polishing is
certainly needed, but I'd like to try this. If I only had the time...
------------------------------------------------------------------------
Fri, 16 Sep 2005 22:10:19 +0000 : killes(a)www.drop.org
Ok, I've been doing some clean-up on this one and made contact.module
use it. The module and the .inc file work.
I've put the files into my sandbox for now. I plan to work on them over
the weekend (unless Dries tells me they are too late for 4.7).
http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/killes/mail/
But I could use some input:
- the sql file defines a column to store the module that generated the
mail. Do we want this? If yes, we need to fix it.
- Do we need a throttle for only sending x mails per cron run?
- can somebody try the files with php5?
- what else do we need?
Please give input, links and what not.
------------------------------------------------------------------------
Sat, 17 Sep 2005 20:34:04 +0000 : Dries
Some of my comments might be false. If so, sorry. I only looked at it
for 5 minutes:
* I wonder why we need per-module settings. I can't think of concrete
use cases.
* For consistency, mailid needs to be mid.
* I don't see an option to send mails immediately?
* I don't see any "messages per hour" accounting?
* I don't understand why mail.inc should be node system aware?
* mailid = '%s' should be mailid = %d.
* Incorrect use of t(): don't translate user input.
* The coding style needs work; inconsistent variable names,
inconsistent spacing, etc.
* Some PHPDoc is rather cryptic: /Updates table mail queue address
table sets sent flag to 1 for a queued msg./.
------------------------------------------------------------------------
Sun, 18 Sep 2005 04:28:11 +0000 : killes(a)www.drop.org
I've fixed a number of things. needs testing.
------------------------------------------------------------------------
Mon, 19 Sep 2005 02:28:25 +0000 : killes(a)www.drop.org
Ok, changed and tested.
Some more changes, taken some concepts from massmailer.module.
Included hacked copies of simplenews and contact module for testing
purposes.
We need to discuss if this should be a module or a part od
system.module.
depending on the outcome we need to put the functions in mail.module
and mail.inc into different files.
Testers welcome.
------------------------------------------------------------------------
Mon, 19 Sep 2005 06:31:04 +0000 : Peter Apockotos
Dries,
Are you talking about something like I request here
http://drupal.org/node/28079 ?
------------------------------------------------------------------------
Mon, 19 Sep 2005 18:15:20 +0000 : m3avrck
Well first off, just wanted to say I'm currently evaluating this and
been sending regular feedback to killes for improvements. So far so
good on PHP5 machines :-)
But in terms of where should this code go, I think mail.module should
be eliminated and those functions should be put in mail.inc which
*should* be seperate from common.inc. This way, as Drupal grows and
more and more modules depend upon mail functions, they will be in their
unqiue spot which can easily be patched and extended instead of
rummaging through the common.inc mess ;-)
As a result, the mail.module settings should be moved to Admin >
Settings with the mail setup there, since the basic Drupal "request new
password" etc framework requires mail functionality and having these
settings there makes the most sense, usability wise.
I think with this setup the code could be organized in the cleanest and
most straightforward method and would be an elegant refinement in mail
handling for 4.7... no new features, just cleaned up and seperate for
other modules to make use of, instead of duplicating code and time.
This also has the benefit of bringing in more patches to the Drupal
core and how it handles mail and making it rock solid.
Just my 2 cents.
------------------------------------------------------------------------
Tue, 20 Sep 2005 03:14:25 +0000 : vwX
Did some testing on Killes changes. Queued ~1000 addresses for one
email. When sending started receiving this message :
"
warning: mail(): Could not execute mail delivery program
'/usr/sbin/sendmail -t -i ' in
/home/webuser/mars/www/drupal/modules/mail.module on line 189.
"
at around message 258.
Looking further seems sendmail got hammered. This is a RH6.2 box
550MHz processor with 256MB memory and sendmail configured to use a
smarthost qmail server. I can share the script to test if anybody
wants to help. Will try a bit more after I do some tuning.
Now about the changes.
I think that the mail_queue_addresses table key structure needs to be
changed. Remove Aid and just use address. Also, I've always used a
primary key structure of parent table primary key + one or more
additional keys for a child table. Originally I had something like
this, but it is now one primary key and an index. I don't think this
is correct and I've been doing database work for 15 odd years.
Also, I agree with what m3avrck says. Orginally when I submitted the
code I had most of the functionality in mail.inc and the module was
primarily for administrative functions. I also functionality to view
what was in the queue and force the sending of messages in the queue.
That has since been removed and I think it should be re-added.
1
0
Issue status update for
http://drupal.org/node/31716
Post a follow up:
http://drupal.org/project/comments/add/31716
Project: Drupal
Version: cvs
Component: drupal.module
Category: bug reports
Priority: normal
Assigned to: Anonymous
Reported by: robertDouglass
Updated by: chx
Status: patch (code needs review)
I agree.
I have looked around for better solutions and pubcookies looks good.
(Google on it. I do not have too much too time to write about it.)
chx
Previous comments:
------------------------------------------------------------------------
Tue, 20 Sep 2005 07:14:52 +0000 : robertDouglass
Attachment: http://drupal.org/files/issues/drupalmod.patch (11.15 KB)
The drupal module does two things; it implements distributed
authentication and it lets you run a "directory server". These sound
great in the features list, but the implementation of both features is
weak and poses the real risk of exposing Drupal users to identity
theft.
Here is an excerpt from my writings on the module:
Distributed authentication
Drupal distributed authentication is a way to save site users the extra
steps of creating redundant accounts on multiple sites.
(snip... we know how it works :-)
There are some limitations and concerns about the current
implementation of distributed authentication. It would be relatively
easy for someone to alter the code of their site to save a record of
the passwords of users who log in. This is true of any website you
visit, Drupal or otherwise. As long as the username and password only
buys access to that very site, there is little incentive to do this.
If, however, it would allow the malicious person to log into other
sites as well, in this case any Drupal site that has the drupal module
enabled, the incentive is greater and the potential loss or damage
greater. The attacker would be able to masquerade on those sites using
your user identity and execute actions on your behalf.
CAUTION Drupal's distributed authentication is inherently insecure. If
you do not know that you can trust the owner(s) of a particular site,
never use your distributed authentication (Drupal id) to log into it.
Running a directory server
The drupal module offers a simple service by which other Drupal sites
can announce their existence, or "ping" a central server on a regular
basis. While there are many possible applications of such a service,
the most prominent use is the now defunct Drupal sites page on
Drupal.org which was simply a long list of sites that run Drupal.
In practice, any site that has the drupal module enabled can function
as a directory server. When another site pings the site, the remote
site's name, slogan and mission are added to the list of sites. A
useful application of a directory server might be on a college or
university where individual labs or departments are setting up many
different Drupal sites. Each one could ping a central server at the
university to compile a list of all the various sites as they spring
up.
In its current state, the service lacks some basic features. There is
no way for the administrator to block a certain site from pinging and
being added to the list. Nor is there a way to limit the incoming pings
to a certain set of domains or IP addresses. The potential to make a
truly useful directory server service exists, though, and anyone is
encouraged to participate in discussions and development at Drupal.org.
-----------------------
I've come to the conclusion that a module that is this weak should be
offered as a contributed module, not as core. If it weren't in core, I
wouldn't bother writing about it because it is too weak, and poses a
real security threat. My recommendation is that it be placed in the
contributions repository as an example of how distributed auth. for
those enterprising individuals who might want to improve upon it.
------------------------------------------------------------------------
Tue, 20 Sep 2005 10:19:32 +0000 : robertDouglass
tasks don't send mail? Setting to bug report.
------------------------------------------------------------------------
Tue, 20 Sep 2005 10:30:42 +0000 : robertDouglass
The more I think about it, the more I conclude that Drupal.org should
also drop dist. auth. support, or find better security solutions.
Here's an example scenerio to provoke discussion. Gerhard always logs
on to drupal.org as killes(a)www.drop.org. AFAIK, these sites are now on
two separate servers, and therefore probably have different security
profiles. Now, just as conjecture, let us suppose that the server on
which drop.org is run gets compromised and someone is able to steal
Gerhard's password. They now have a big cat in the bag: drupal.org.
They'd be able to become site/cvs admins for drupal.org, something
which we probably don't want. In the end, if we have no way to say
which sites can be trusted to do authentication, it is a bad idea
allowing anyone to use this in conjunction with drupal.org.
Another example:
http://kerneltrap.org/user/2524
What if Jeremy's server were compromised (or perhaps Jeremy is just
really evil and nobody knows ;-))? In either case, someone would be
able to log into drupal.org with the UnConeD username - not a really
attractive idea.
PLEASE TELL ME I'M WRONG! Or remove the module.
------------------------------------------------------------------------
Tue, 20 Sep 2005 11:17:00 +0000 : eldarin
Robert, you make perfect sense.
;-)
Other servers could get compromised like you point out, and that could
let someone take control of drupal.org if a siteadmin used the
compromised site with the same account login. This could especially be
true if a site used an earlier Drupal version. And it's not only
current sites using this, but future sites and possible future modules
which can be used to compromise security. Someone could offer
my-cool-module.module and distribute it through some other forums,
thereby getting some backdoor access. Using the distributed login
feature, they could behave like a worm.
Ultimately, it's up to the users to show good thinking and NOT use the
same username or password everywhere .. but that is difficult to
demand. Scenario example: two websites have siteadmins which know each
other well (or same person), and same person registers on both sites.
If the password is very similar or a pattern can be discerned and if
that person is a drupal.org siteadmin, the possibility exists that
drupal.org still could get compromised.
There is no way to be foolproof, but helping users along doesn't hurt.
;-)
1
0
Issue status update for
http://drupal.org/node/31716
Post a follow up:
http://drupal.org/project/comments/add/31716
Project: Drupal
Version: cvs
Component: drupal.module
Category: bug reports
Priority: normal
Assigned to: Anonymous
Reported by: robertDouglass
Updated by: eldarin
Status: patch (code needs review)
Robert, you make perfect sense.
;-)
Other servers could get compromised like you point out, and that could
let someone take control of drupal.org if a siteadmin used the
compromised site with the same account login. This could especially be
true if a site used an earlier Drupal version. And it's not only
current sites using this, but future sites and possible future modules
which can be used to compromise security. Someone could offer
my-cool-module.module and distribute it through some other forums,
thereby getting some backdoor access. Using the distributed login
feature, they could behave like a worm.
Ultimately, it's up to the users to show good thinking and NOT use the
same username or password everywhere .. but that is difficult to
demand. Scenario example: two websites have siteadmins which know each
other well (or same person), and same person registers on both sites.
If the password is very similar or a pattern can be discerned and if
that person is a drupal.org siteadmin, the possibility exists that
drupal.org still could get compromised.
There is no way to be foolproof, but helping users along doesn't hurt.
;-)
eldarin
Previous comments:
------------------------------------------------------------------------
Tue, 20 Sep 2005 07:14:52 +0000 : robertDouglass
Attachment: http://drupal.org/files/issues/drupalmod.patch (11.15 KB)
The drupal module does two things; it implements distributed
authentication and it lets you run a "directory server". These sound
great in the features list, but the implementation of both features is
weak and poses the real risk of exposing Drupal users to identity
theft.
Here is an excerpt from my writings on the module:
Distributed authentication
Drupal distributed authentication is a way to save site users the extra
steps of creating redundant accounts on multiple sites.
(snip... we know how it works :-)
There are some limitations and concerns about the current
implementation of distributed authentication. It would be relatively
easy for someone to alter the code of their site to save a record of
the passwords of users who log in. This is true of any website you
visit, Drupal or otherwise. As long as the username and password only
buys access to that very site, there is little incentive to do this.
If, however, it would allow the malicious person to log into other
sites as well, in this case any Drupal site that has the drupal module
enabled, the incentive is greater and the potential loss or damage
greater. The attacker would be able to masquerade on those sites using
your user identity and execute actions on your behalf.
CAUTION Drupal's distributed authentication is inherently insecure. If
you do not know that you can trust the owner(s) of a particular site,
never use your distributed authentication (Drupal id) to log into it.
Running a directory server
The drupal module offers a simple service by which other Drupal sites
can announce their existence, or "ping" a central server on a regular
basis. While there are many possible applications of such a service,
the most prominent use is the now defunct Drupal sites page on
Drupal.org which was simply a long list of sites that run Drupal.
In practice, any site that has the drupal module enabled can function
as a directory server. When another site pings the site, the remote
site's name, slogan and mission are added to the list of sites. A
useful application of a directory server might be on a college or
university where individual labs or departments are setting up many
different Drupal sites. Each one could ping a central server at the
university to compile a list of all the various sites as they spring
up.
In its current state, the service lacks some basic features. There is
no way for the administrator to block a certain site from pinging and
being added to the list. Nor is there a way to limit the incoming pings
to a certain set of domains or IP addresses. The potential to make a
truly useful directory server service exists, though, and anyone is
encouraged to participate in discussions and development at Drupal.org.
-----------------------
I've come to the conclusion that a module that is this weak should be
offered as a contributed module, not as core. If it weren't in core, I
wouldn't bother writing about it because it is too weak, and poses a
real security threat. My recommendation is that it be placed in the
contributions repository as an example of how distributed auth. for
those enterprising individuals who might want to improve upon it.
------------------------------------------------------------------------
Tue, 20 Sep 2005 10:19:32 +0000 : robertDouglass
tasks don't send mail? Setting to bug report.
------------------------------------------------------------------------
Tue, 20 Sep 2005 10:30:42 +0000 : robertDouglass
The more I think about it, the more I conclude that Drupal.org should
also drop dist. auth. support, or find better security solutions.
Here's an example scenerio to provoke discussion. Gerhard always logs
on to drupal.org as killes(a)www.drop.org. AFAIK, these sites are now on
two separate servers, and therefore probably have different security
profiles. Now, just as conjecture, let us suppose that the server on
which drop.org is run gets compromised and someone is able to steal
Gerhard's password. They now have a big cat in the bag: drupal.org.
They'd be able to become site/cvs admins for drupal.org, something
which we probably don't want. In the end, if we have no way to say
which sites can be trusted to do authentication, it is a bad idea
allowing anyone to use this in conjunction with drupal.org.
Another example:
http://kerneltrap.org/user/2524
What if Jeremy's server were compromised (or perhaps Jeremy is just
really evil and nobody knows ;-))? In either case, someone would be
able to log into drupal.org with the UnConeD username - not a really
attractive idea.
PLEASE TELL ME I'M WRONG! Or remove the module.
1
0
Issue status update for
http://drupal.org/node/31716
Post a follow up:
http://drupal.org/project/comments/add/31716
Project: Drupal
Version: cvs
Component: drupal.module
-Category: tasks
+Category: bug reports
Priority: normal
Assigned to: Anonymous
Reported by: robertDouglass
Updated by: robertDouglass
Status: patch (code needs review)
tasks don't send mail? Setting to bug report.
robertDouglass
Previous comments:
------------------------------------------------------------------------
Tue, 20 Sep 2005 07:14:52 +0000 : robertDouglass
Attachment: http://drupal.org/files/issues/drupalmod.patch (11.15 KB)
The drupal module does two things; it implements distributed
authentication and it lets you run a "directory server". These sound
great in the features list, but the implementation of both features is
weak and poses the real risk of exposing Drupal users to identity
theft.
Here is an excerpt from my writings on the module:
Distributed authentication
Drupal distributed authentication is a way to save site users the extra
steps of creating redundant accounts on multiple sites.
(snip... we know how it works :-)
There are some limitations and concerns about the current
implementation of distributed authentication. It would be relatively
easy for someone to alter the code of their site to save a record of
the passwords of users who log in. This is true of any website you
visit, Drupal or otherwise. As long as the username and password only
buys access to that very site, there is little incentive to do this.
If, however, it would allow the malicious person to log into other
sites as well, in this case any Drupal site that has the drupal module
enabled, the incentive is greater and the potential loss or damage
greater. The attacker would be able to masquerade on those sites using
your user identity and execute actions on your behalf.
CAUTION Drupal's distributed authentication is inherently insecure. If
you do not know that you can trust the owner(s) of a particular site,
never use your distributed authentication (Drupal id) to log into it.
Running a directory server
The drupal module offers a simple service by which other Drupal sites
can announce their existence, or "ping" a central server on a regular
basis. While there are many possible applications of such a service,
the most prominent use is the now defunct Drupal sites page on
Drupal.org which was simply a long list of sites that run Drupal.
In practice, any site that has the drupal module enabled can function
as a directory server. When another site pings the site, the remote
site's name, slogan and mission are added to the list of sites. A
useful application of a directory server might be on a college or
university where individual labs or departments are setting up many
different Drupal sites. Each one could ping a central server at the
university to compile a list of all the various sites as they spring
up.
In its current state, the service lacks some basic features. There is
no way for the administrator to block a certain site from pinging and
being added to the list. Nor is there a way to limit the incoming pings
to a certain set of domains or IP addresses. The potential to make a
truly useful directory server service exists, though, and anyone is
encouraged to participate in discussions and development at Drupal.org.
-----------------------
I've come to the conclusion that a module that is this weak should be
offered as a contributed module, not as core. If it weren't in core, I
wouldn't bother writing about it because it is too weak, and poses a
real security threat. My recommendation is that it be placed in the
contributions repository as an example of how distributed auth. for
those enterprising individuals who might want to improve upon it.
1
0
Issue status update for
http://drupal.org/node/26031
Post a follow up:
http://drupal.org/project/comments/add/26031
Project: Drupal
Version: cvs
Component: comment.module
Category: bug reports
Priority: critical
Assigned to: leafish_dylan
Reported by: leafish_dylan
Updated by: leafish_paul
Status: patch (code needs review)
Agreed on the deleting one comment only ting, here's some links:
http://drupal.org/node/11877
http://www.settingtheworldtorights.com/node/417 (search for 'delete a
single comment')
leafish_paul
Previous comments:
------------------------------------------------------------------------
Wed, 29 Jun 2005 23:43:10 +0000 : leafish_dylan
I've just upgraded a 4.6.1 site to CVS and there's no comment pager on
nodes with more than $comments_per_page. Is this a bug, or it it one of
my modules? I've tested the site with various other themes, including
the defaults.
------------------------------------------------------------------------
Mon, 04 Jul 2005 23:41:03 +0000 : leafish_dylan
Can anybody confirm this? I can't find the problem.
------------------------------------------------------------------------
Fri, 15 Jul 2005 12:35:14 +0000 : leafish_dylan
Hello?
------------------------------------------------------------------------
Tue, 23 Aug 2005 14:12:16 +0000 : Uwe Hermann
Confirmed in HEAD. The problem is here (comment.module,
comment_render()):
if ($pager = theme('pager', NULL, $comments_per_page, 0,
array('comments_per_page' => $comments_per_page))) {
$output .= $pager;
}
The $pager variable is empty (for whatever reason), hence no pager is
generated. I didn't debug this any further...
------------------------------------------------------------------------
Fri, 09 Sep 2005 21:11:26 +0000 : leafish_paul
Confirmed here too - can any one take a look at this?
------------------------------------------------------------------------
Mon, 19 Sep 2005 15:52:20 +0000 : leafish_dylan
Attachment: http://drupal.org/files/issues/comment.module_30.patch (1.02 KB)
Comment paging has been broken in CVS for at least 3 months, yet only
one other person has noticed this?
Here's a patch to fix the bug...
------------------------------------------------------------------------
Mon, 19 Sep 2005 17:21:36 +0000 : tostinni
I also posted a patch there [1].
But there's still some major bug with comments...
[1] http://drupal.org/node/26966#comment-41012
------------------------------------------------------------------------
Mon, 19 Sep 2005 23:00:56 +0000 : leafish_dylan
Oh, okay. I wish I'd seen your patch before I hunted this bug down
myself, but thanks anyway.
You're right, the comment module is very broken right now. Most of the
problems are related to the pager or the comment options box, but there
are limitations with this module that are really quite suprising. Can we
still not delete a single comment in a thread, for example? This is
evil, and wrong.
1
0
Issue status update for
http://drupal.org/node/31326
Post a follow up:
http://drupal.org/project/comments/add/31326
Project: Drupal
Version: cvs
Component: system.module
Category: feature requests
Priority: normal
Assigned to: Anonymous
Reported by: der
Updated by: der
Status: patch (code needs review)
Attachment: http://drupal.org/files/issues/control_panel_2.patch (5.48 KB)
Patch fixing the issue that syllance pointed out and it also fixes the
obvious issue with the drupal_goto function arguments. duh!
der
Previous comments:
------------------------------------------------------------------------
Thu, 15 Sep 2005 17:50:52 +0000 : der
Attachment: http://drupal.org/files/issues/system_9.patch (4.27 KB)
New feature suggestion:
I would like to suggest a couple of enhancments to administration
pages.
First, add a new general settings option to allow the user to specify
the admin home page. Currently the watchdog log view is the default
home page.
Second, add a new control panel page that can be used as the default
admin start page.
I've attached a suggested patch to the CVS head version of the
system.module that implements these two enhancements. The patch does
the following.
Adds a new "default admin page" text field to the general settings
group (just after the "default front page"). It also changes the admin
menu entry to call a new function that examines the default "admin page"
variable and redirects to the appropriate path. For the control panel,
the patch adds a new function (system_admin_controlpanel). This
function basically looks for the admin entry in the menu structure and
then iterates through the child menu items and builds a control panel
page using the path and title information returned from the menu
structure. For the control panel icons it looks for an icon file in the
misc directory that matches the name of the menu item (e.g. user.png,
access.png etc) If it doesn't find an icon it uses a default. I've
also included some 48/48 icons that I borrowed from my
usr/share/icon/gnome directory of my local Linux box. I believe these
are gnome GPL'ed icons but any 48/48 icons could be used.
This patch allows users who prefer the current functionality to keep it
as their default. It provides the option for others to make any admin
page they want to be their admin "home page" including using a
graphical control panel. Module developers that add new admin menu
options can add their own custom icons for the control panel but they
are not "required" to do so as a default will be used if they don't
provide one.
------------------------------------------------------------------------
Thu, 15 Sep 2005 17:52:15 +0000 : der
Attachment: http://drupal.org/files/issues/drupal_controlpanel_icons.zip (39.09 KB)
48x48 icons attached
------------------------------------------------------------------------
Fri, 16 Sep 2005 14:30:16 +0000 : der
Attachment: http://drupal.org/files/issues/system_2_0.patch (4.5 KB)
updated patch. slightly changed the formatting of the control panel
page
------------------------------------------------------------------------
Sat, 17 Sep 2005 00:37:24 +0000 : moggy
I quite like this. It certainly goes some way to making Drupal easier on
the eyes for first time users.
I noticed there's a lot of hard coded style. Would this not be better
in a stylesheet and the code just containing classes and ids?
Also would a dropdown box of possible admin pages be better than trying
to remember how to spell controlpanel (something I'm having trouble with
tonight ;-) )
------------------------------------------------------------------------
Sat, 17 Sep 2005 13:02:08 +0000 : syllance
Nice job :)
the default admin page is a nice feature, and the controlpanel is a
very good idea. This goes in the good direction to make Drupal more
user friendly.
i agree with the dropdown menu and stylesheet additions, but i already
really appreciate the current version.
hope this will go into core soon, as it really makes the first admin
pages contact better :)
i don't mind scrolling through the nav menu and i rarely goes into
admin without checking the logs, but that definitely will help me
converting my wife's site to drupal :p
thanks !
------------------------------------------------------------------------
Sat, 17 Sep 2005 16:09:43 +0000 : der
I'll move the styles off to a style sheet but I'm uncertain about
whether or not make make the default admin page a dropdown. It's an
easy change and it eliminates any typos by the user but it also
restricts the user to a current visible admin menu item. If by chance
someone wanted to write their own admin start page (ie their own control
panel) they would have to hack the core system.module to do it.
Anyone else want to weigh in with their preference?
Also, anyone up for creating drupalized versions of the control panel
icons?
------------------------------------------------------------------------
Sat, 17 Sep 2005 16:16:15 +0000 : chx
Maybe just because I created it, I like my control panel module better.
------------------------------------------------------------------------
Sat, 17 Sep 2005 16:25:30 +0000 : der
If I would have known there was a module I wouldn't have written this
patch although I do think this would be good for core Drupal as the
default.
Is your modules a recent creation? I don't see it on drupal.org nor
could I find in the contribs section of CVS (either the modules or
sandbox sections). I'm I missing something? Is it called something
different?
------------------------------------------------------------------------
Sat, 17 Sep 2005 18:20:15 +0000 : syllance
chx control panel is located in his sandbox (cp.module), and thanks to
him for letting us know there's one :)
it's working fine (tested on HEAD) and provide interesting concept for
navigating through the admin, instead of just add a frontend. the
settings part is the better one, listing all elements in the page makes
quickly forget the standard menu.
der's one looks nice and provide a more immediate access to admin
pages, but the standard menu is still mandatory to access some elements
(dba or store settings for example, still needs to be accessed via left
menu).
to be honest, i like them both :)
being able to change the default admin page is very nice, and icons
make admin looks a lot better, raising the Woman Acceptance Factor by a
huge amount (my wife loves it :). but i also really like the more in
depth admin navigation offered by chx module.
mixing both on my head setup gives a nice result, so may be it would be
a good idea to join forces and mix the 2 panels.
chx, is your module somewhat official and scheduled to hit the core ?
------------------------------------------------------------------------
Sat, 17 Sep 2005 19:24:11 +0000 : Amazon
Hi, I asked Karoly to create the control panel module. It important
that the control panel be tied into the navigation menu block so that
it does not create inconsistent navigation.
The goal is to start a user experience grouping exercise to help the
community categorize administration tasks. The first thing that has
to happen is that administration must be considered a seperate
situation from creating personal content in Drupal. To support this
seperation of personal tasks and administration tasks we broke out
administration to have a separate theme in the CivicSpace theme.
Through research interviews into Drupal administration we need to
discover what the goals and tasks of administrators are. Some early
feedback is that site developers need modules to be evaluated on
Drupal.org. They have also indicated they need better and consistent
administration help ,with incontext list, which we have been adding.
We have also heard administrators want a quick overview. Any change to
provide a control panel like overview must have a dashboard like
overview. You should assume that we will identify a list of 5-7 top
goals for administrators.
Once those those 5-7 top goals are identified we need to ensure
administrators can acommplish tasks to achieve those goals. Some of
those tasks will completed by clicking through to icons or admin
interface links. Sub-goals will be accomplished by providing
effective navigation. We need to consider 4 types of navigation to be
added to the control panel: Global navigation, local navigation,
contextual navigation, and situational navigation. Some of this
navigation can be accomplished through a theme or blocks. Some will
need to be in the page and some need to be added in otherways, such as
interaction techniques.
Keep all this in mind when creating a control panel solution. It also
must respond to the fact that every site will have different
permissions set and different modules. This is a complex problem and
it's going to research and experimentation to get it right. But this
is a big step in the right direction.
Cheers,
Kieran
------------------------------------------------------------------------
Sat, 17 Sep 2005 19:47:55 +0000 : der
Attachment: http://drupal.org/files/issues/system.module_11.patch (5.61 KB)
This has sparked a lot of good discussion. I've taken a look at
cp.module and I think it really is complimentary with my proposed
patch. I've taken my patch one step further and provided the settings
icons in a collapsable group below the main control panel. This would
allow access to all admin functions without referring to the
traditional menu.
Syllance, do you think this addresses the gap you saw in my solution?
------------------------------------------------------------------------
Sat, 17 Sep 2005 20:33:10 +0000 : der
Kieran, I'm glad to see some serious thought going into the user
experience for site administrators. I think separating the user and
admin sections of the site is critical. It will not only allow
extensive usability work to be done for site admins it will also make
it much easier for theme creators as they will be able to focus on the
end user experience. I like the admin theme for civicspace. My only
dislike about the approach is that it's template driven which causes a
sites template to be larger and more complex due to handling all the
logic for user and admin themes. I think a better approach may be to
use a module such as the sections module. This allows you to have
smaller templates focused on user or admin themes.
I agree with your point about making sure the control panel ties into
them menu system. My approach uses the existing menu structure so
modules are added dynamically and all permissions are enforced.
------------------------------------------------------------------------
Sat, 17 Sep 2005 22:21:05 +0000 : chx
<?php
function _system_adminpage () {
drupal_goto($path = variable_get('site_adminpage', 'admin/controlpanel'), $query = NULL, $fragment = NULL);
}
?>
no way. Use menu !$may_cache and set the path based on the variable.
Adding in-line style elements is also a no-go.
The code style is not kept. Never a space between full stop and
apostrophe, always otherwise.
It's not $menuvisible but $menu_visible
I must be blind (it's 0:17am) but // Build the settings section of the
control panel does not seem to differ from the previous section. A
function may be appropriate.
------------------------------------------------------------------------
Sat, 17 Sep 2005 22:39:40 +0000 : der
Thanks for the code feedback. I'm assuming the extracted style info
would get patched to drupal.css?
Your right about the duplicate code. A function would make more sense,
I'll make the change.
I'm not sure about the comment to use "$may_cache" I've never used it
before. What's it's purpose? How should I use it in this situation.
I'll dig around and see if I can figure it out but I thought you might
be able to give me a little insight.
Thanks!
------------------------------------------------------------------------
Sun, 18 Sep 2005 10:41:00 +0000 : syllance
der, i've checked the new version of your control panel, and it does
simplify access to the settings menu (although with a complex setup,
the site config collapsable menu goes a lot more down than the menu,
but this a page and not a small menu so its still better)
however, there other case settings like, such as the ecommerce modules,
which provides a more complex menu tree (ex :
store->settings->payment->adjustments, each with their own admin
pages). these are not taken into account by your panel, leaving the
menu mandatory.
chx control panel handles this nicely with page navigation. going
through the store menu with chx panel is a real pleasure while its a
real pain with the menu. So i think the best would be to mix the two
panels, chx one handling page navigation, and yours providing a
frontend for basic admin pages, and collapsable site config items.
instead of linking to the standard admin pages, icons might link to chx
nav pages where there are sub entries.
i'm running both today, and this already makes the admin really better,
but i'm often switching from der panel to chx one (for store), so mixing
both would be, for me, a very nice solution :p
thanks for the good work :)
------------------------------------------------------------------------
Sun, 18 Sep 2005 12:54:55 +0000 : der
Attachment: http://drupal.org/files/issues/control_panel.patch (5.61 KB)
Here's a new patch with the code reworked per chx's comments with the
exception of his objection to my use of drupal_goto function. chx, I'm
probably missing something really obvious but I'm not understanding your
suggestion. Are you suggesting I use some menu function to do the
redirect? If so, I could not find one that suits my needs. Or are you
suggesting to use the drupal_goto function in a different manner than I
am using it. Like I said, I'm probably missing something really
obvious here but for the life of me I don't know what it is. Any
further advice would be greatly appreciated. The offending code below:
<?php
function _system_adminpage () {
drupal_goto($path = variable_get('site_adminpage', 'admin/controlpanel'), $query = NULL, $fragment = NULL);
}
?>
------------------------------------------------------------------------
Mon, 19 Sep 2005 13:42:57 +0000 : syllance
i think there's a problem with your latest patch. it seems to display
all icons as a vertical list. it may be a problem with my setup, but
i'm using basic themes that comes with head. the administer page is
thus very long, and this is not very useful. previous version was
better, imho :)
thanks
------------------------------------------------------------------------
Mon, 19 Sep 2005 14:10:03 +0000 : der
which theme and which browser are you using?
------------------------------------------------------------------------
Mon, 19 Sep 2005 15:59:16 +0000 : der
Attachment: http://drupal.org/files/issues/control_panel_0.patch (5.32 KB)
I've tested this with IE and FireFox with each of the Drupal shipped
HEAD themes and I'm not seeing the issue you described. Are you sure
the patch applied correctly to drupal.css?
Here's a slightly revised patch. It make the control panel icon group
collapsable but open by default.
------------------------------------------------------------------------
Mon, 19 Sep 2005 18:09:22 +0000 : der
Attachment: http://drupal.org/files/issues/control_panel_1.patch (5.64 KB)
Sorry for the excessive number of patches. I just realized that my
previous patch had an issue with icon image file names if there were
admin and admin/settings menu items that were the same (eg admin/user
and admin/settings/user).
New patch attached to address.
------------------------------------------------------------------------
Tue, 20 Sep 2005 02:13:49 +0000 : syllance
the vertical thing was probably due to a problem with my drupal.css.
i've tested your new patch with a fresh update and the display is fine,
but there's a bug.
the site configuration panel displays store settings items
(checkout,payment,shipping), and not the global settings one. this
might be due to the menus item having the same name 'settings',
although not located at the same level (administer/settings, and
administer/store/settings). ready for another patch ? :)
your panel adds a nice look and enable default administer page setup.
but there's still a lot of menu access needed when other modules are
setup (such as ecommerce), and i'm using it in addition to chx one to
provide a complete admin solution :)
chx one looks just like the theme you're using with no icons, but it
really help accelerating admin navigation. i'm wondering if integrating
both to core wouldn't be the ultimate solution. your panel more targeted
at standard admin needs, and chx one helping users that deals with lots
of modules & settings.
thanks again
------------------------------------------------------------------------
Tue, 20 Sep 2005 02:19:54 +0000 : Amazon
Hi, can you guys post some screen shots as you go along for those of us
who don't want to keep installing new patches.
------------------------------------------------------------------------
Tue, 20 Sep 2005 02:25:06 +0000 : der
Attachment: http://drupal.org/files/issues/Control Panel.png (101.02 KB)
Sure, here's what the current version looks like with the civicspace
admin theme.
1
0
Issue status update for
http://drupal.org/node/28604
Post a follow up:
http://drupal.org/project/comments/add/28604
Project: Drupal
Version: cvs
Component: base system
Category: feature requests
Priority: normal
Assigned to: Anonymous
Reported by: Dries
Updated by: vwX
Status: patch (code needs review)
Did some testing on Killes changes. Queued ~1000 addresses for one
email. When sending started receiving this message :
"
warning: mail(): Could not execute mail delivery program
'/usr/sbin/sendmail -t -i ' in
/home/webuser/mars/www/drupal/modules/mail.module on line 189.
"
at around message 258.
Looking further seems sendmail got hammered. This is a RH6.2 box
550MHz processor with 256MB memory and sendmail configured to use a
smarthost qmail server. I can share the script to test if anybody
wants to help. Will try a bit more after I do some tuning.
Now about the changes.
I think that the mail_queue_addresses table key structure needs to be
changed. Remove Aid and just use address. Also, I've always used a
primary key structure of parent table primary key + one or more
additional keys for a child table. Originally I had something like
this, but it is now one primary key and an index. I don't think this
is correct and I've been doing database work for 15 odd years.
Also, I agree with what m3avrck says. Orginally when I submitted the
code I had most of the functionality in mail.inc and the module was
primarily for administrative functions. I also functionality to view
what was in the queue and force the sending of messages in the queue.
That has since been removed and I think it should be re-added.
vwX
Previous comments:
------------------------------------------------------------------------
Wed, 10 Aug 2005 12:35:37 +0000 : Dries
It was suggested that we separate the mail backend from the front-end.
We might want to include the mail backend in core as includes/mail.inc.
Then, other modules like massmailer, subscriptions, notify, pm (private
messages), project (project issues), contact, etc. could reuse this
component. The mail.inc file would implement some kind of mail queue
functionality, and modules just add a mail to the mail queue using a
simple /mail API/. In future, the mail backend could deal with bounces
and report back proper status codes. Moreover, mail.inc would be
pluggable so it could be replaced by a more powerful one, or one that
is build specifically for the underlying mail transport (SMTP server).
Furthermore, this would solve issues with how many mails get send
within a specified interval. Like, when more than one module sends out
e-mails it is hard to enforce limitations/restrictions imposed by the
hosting company.
I'm posting this here so you can keep this in mind when working on
simplenews, and to solicit for feedback. Chances are we'll setup an
IRC meeting to discuss this further. Details to follow.
------------------------------------------------------------------------
Wed, 10 Aug 2005 16:15:16 +0000 : Amazon
A good place to start would be to look at existing Mail API's
Pear Mail: http://pear.php.net/package/Mail
Pear Mail tutorial:
http://www.zend.com/pear/tutorials/Mail.php#Heading2
------------------------------------------------------------------------
Wed, 10 Aug 2005 20:21:57 +0000 : walkah
um. +1 and then some. I think this is good... and some good references
from Amazon. I'll throw in one other :
http://phpmailer.sf.net/ - has great mime handling (i've run into
issues with PEAR::Mail's mime handilng in the past, but that was around
2 years ago, and things may have gotten better since then).
Oh - and you don't mention it - but support for multipart / mime
messages would be lovely :)
I'd be interested in / happy to sit in on any IRC discussion as well.
------------------------------------------------------------------------
Wed, 10 Aug 2005 21:40:34 +0000 : robertDouglass
phpmailer++
I've used it and like how easy it is to send both text and html mail.
Did I say html mail? You bet! It's time that we had the option.
------------------------------------------------------------------------
Thu, 11 Aug 2005 05:47:01 +0000 : cyberchucktx
I'm definitely interested.
Hopefully by adding a post to this I'll get notified on new postings
(?)
If not I may miss the IRC ..
I've been doing a lot of work with safe_mode PHPLIST (have posted to
the drupal site somewhee, can dig out the reference if anyone is
interested).
Charlie in TX
------------------------------------------------------------------------
Wed, 17 Aug 2005 08:42:34 +0000 : Dries
It was suggested that mail.inc also provides a HTML to text services.
Lots of modules (newsletter, notify, project) try converting HTML to
text. Having a reusable function makes sense, and will lead to better
conversion routines. XSLT anyone?
------------------------------------------------------------------------
Wed, 17 Aug 2005 12:31:27 +0000 : Grugnog2
+1 for phpmailer
I found it very easy to use - and most importantly for me - it supports
SMTP authentication. As many ISP's will not let you send mail without
using SMTP-auth nowadays it may be worth this feature is incorporated
into the mail.inc API.
- Grug
------------------------------------------------------------------------
Wed, 17 Aug 2005 15:08:43 +0000 : Robert Castelo
For about a year now I've been working on an email newsletter and
announcement module [1]. There's a version in my sandbox commited about
2 months ago which works fairly well. Dan Robinson and Varr Willis at
CivicActions, Moshe Weitzman plus a few others have been testing it,
and I've had lots of positive feedback and feature and bug reports from
them.
A few months ago a realised that there's not much point in putting so
much effort into creating all this functionality, only for it to be
locked away in my module. Better to
Better to create discreet component modules which provide a particular
service, such as bounced email handling, but which can be used by any
other module that also needs that service.
For the last two months I've been working to split functionality into
component services modules and make these services available to all
modules.
One of the biggest challenges was to make these component modules
independent of each other. The only area where I haven't managed this
is some of the database calls - but thanks to a chat with chx I
realised that db_rewrite_sql could be used to handle this very nicely.
This is what I have:
* bounced_email.module - process bounced emails
* html2text.module - convert HTML to plain text equivalent (e.g. list
item becomes "* item")
* identity_hash.module - manages full and partial loggin based on hash
which can be used in email links
* publication.module - defines and packages content of publication,
which could be any kind of publication
* schedule.module - defines and manages schedules, e.g. email sending
schedule
* subscribed.module - manages subscriptions to publications
* templates.module - manage and define templates
What's great is that the component modules are not limited to email,
they could be used to quickly create RSS newsletters, PDF newsletters,
text message newsletters, or even personalised/filtered website
sections.
I haven't made the new component modules available anywhere yet, but
I'll be happy to upload them to contrib and let others get involved.
What would be the best way to commit them - as a single directory? or
each component module in it's own directory?
[1]
http://www.cortextcommunications.com/development/newsletter/features
------------------------------------------------------------------------
Thu, 15 Sep 2005 02:05:18 +0000 : vwX
Attachment: http://drupal.org/files/issues/mailqueue.tar.gz (3.71 KB)
This is a very basic mail queue system I would like to contribute.
There are some changes to other modules that will have to be made such
as changing user.module to use this instead of directly calling the php
mail function and moving mime_header_encoding to mail.inc.
------------------------------------------------------------------------
Thu, 15 Sep 2005 15:25:11 +0000 : killes(a)www.drop.org
Note: I am moving this to the main project.
VwX: What I see looks very nice for a start. Some polishing is
certainly needed, but I'd like to try this. If I only had the time...
------------------------------------------------------------------------
Fri, 16 Sep 2005 22:10:19 +0000 : killes(a)www.drop.org
Ok, I've been doing some clean-up on this one and made contact.module
use it. The module and the .inc file work.
I've put the files into my sandbox for now. I plan to work on them over
the weekend (unless Dries tells me they are too late for 4.7).
http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/killes/mail/
But I could use some input:
- the sql file defines a column to store the module that generated the
mail. Do we want this? If yes, we need to fix it.
- Do we need a throttle for only sending x mails per cron run?
- can somebody try the files with php5?
- what else do we need?
Please give input, links and what not.
------------------------------------------------------------------------
Sat, 17 Sep 2005 20:34:04 +0000 : Dries
Some of my comments might be false. If so, sorry. I only looked at it
for 5 minutes:
* I wonder why we need per-module settings. I can't think of concrete
use cases.
* For consistency, mailid needs to be mid.
* I don't see an option to send mails immediately?
* I don't see any "messages per hour" accounting?
* I don't understand why mail.inc should be node system aware?
* mailid = '%s' should be mailid = %d.
* Incorrect use of t(): don't translate user input.
* The coding style needs work; inconsistent variable names,
inconsistent spacing, etc.
* Some PHPDoc is rather cryptic: /Updates table mail queue address
table sets sent flag to 1 for a queued msg./.
------------------------------------------------------------------------
Sun, 18 Sep 2005 04:28:11 +0000 : killes(a)www.drop.org
I've fixed a number of things. needs testing.
------------------------------------------------------------------------
Mon, 19 Sep 2005 02:28:25 +0000 : killes(a)www.drop.org
Ok, changed and tested.
Some more changes, taken some concepts from massmailer.module.
Included hacked copies of simplenews and contact module for testing
purposes.
We need to discuss if this should be a module or a part od
system.module.
depending on the outcome we need to put the functions in mail.module
and mail.inc into different files.
Testers welcome.
------------------------------------------------------------------------
Mon, 19 Sep 2005 06:31:04 +0000 : Peter Apockotos
Dries,
Are you talking about something like I request here
http://drupal.org/node/28079 ?
------------------------------------------------------------------------
Mon, 19 Sep 2005 18:15:20 +0000 : m3avrck
Well first off, just wanted to say I'm currently evaluating this and
been sending regular feedback to killes for improvements. So far so
good on PHP5 machines :-)
But in terms of where should this code go, I think mail.module should
be eliminated and those functions should be put in mail.inc which
*should* be seperate from common.inc. This way, as Drupal grows and
more and more modules depend upon mail functions, they will be in their
unqiue spot which can easily be patched and extended instead of
rummaging through the common.inc mess ;-)
As a result, the mail.module settings should be moved to Admin >
Settings with the mail setup there, since the basic Drupal "request new
password" etc framework requires mail functionality and having these
settings there makes the most sense, usability wise.
I think with this setup the code could be organized in the cleanest and
most straightforward method and would be an elegant refinement in mail
handling for 4.7... no new features, just cleaned up and seperate for
other modules to make use of, instead of duplicating code and time.
This also has the benefit of bringing in more patches to the Drupal
core and how it handles mail and making it rock solid.
Just my 2 cents.
1
0
Issue status update for
http://drupal.org/node/31326
Post a follow up:
http://drupal.org/project/comments/add/31326
Project: Drupal
Version: cvs
Component: system.module
Category: feature requests
Priority: normal
Assigned to: Anonymous
Reported by: der
Updated by: der
Status: patch (code needs review)
Attachment: http://drupal.org/files/issues/Control Panel.png (101.02 KB)
Sure, here's what the current version looks like with the civicspace
admin theme.
der
Previous comments:
------------------------------------------------------------------------
Thu, 15 Sep 2005 17:50:52 +0000 : der
Attachment: http://drupal.org/files/issues/system_9.patch (4.27 KB)
New feature suggestion:
I would like to suggest a couple of enhancments to administration
pages.
First, add a new general settings option to allow the user to specify
the admin home page. Currently the watchdog log view is the default
home page.
Second, add a new control panel page that can be used as the default
admin start page.
I've attached a suggested patch to the CVS head version of the
system.module that implements these two enhancements. The patch does
the following.
Adds a new "default admin page" text field to the general settings
group (just after the "default front page"). It also changes the admin
menu entry to call a new function that examines the default "admin page"
variable and redirects to the appropriate path. For the control panel,
the patch adds a new function (system_admin_controlpanel). This
function basically looks for the admin entry in the menu structure and
then iterates through the child menu items and builds a control panel
page using the path and title information returned from the menu
structure. For the control panel icons it looks for an icon file in the
misc directory that matches the name of the menu item (e.g. user.png,
access.png etc) If it doesn't find an icon it uses a default. I've
also included some 48/48 icons that I borrowed from my
usr/share/icon/gnome directory of my local Linux box. I believe these
are gnome GPL'ed icons but any 48/48 icons could be used.
This patch allows users who prefer the current functionality to keep it
as their default. It provides the option for others to make any admin
page they want to be their admin "home page" including using a
graphical control panel. Module developers that add new admin menu
options can add their own custom icons for the control panel but they
are not "required" to do so as a default will be used if they don't
provide one.
------------------------------------------------------------------------
Thu, 15 Sep 2005 17:52:15 +0000 : der
Attachment: http://drupal.org/files/issues/drupal_controlpanel_icons.zip (39.09 KB)
48x48 icons attached
------------------------------------------------------------------------
Fri, 16 Sep 2005 14:30:16 +0000 : der
Attachment: http://drupal.org/files/issues/system_2_0.patch (4.5 KB)
updated patch. slightly changed the formatting of the control panel
page
------------------------------------------------------------------------
Sat, 17 Sep 2005 00:37:24 +0000 : moggy
I quite like this. It certainly goes some way to making Drupal easier on
the eyes for first time users.
I noticed there's a lot of hard coded style. Would this not be better
in a stylesheet and the code just containing classes and ids?
Also would a dropdown box of possible admin pages be better than trying
to remember how to spell controlpanel (something I'm having trouble with
tonight ;-) )
------------------------------------------------------------------------
Sat, 17 Sep 2005 13:02:08 +0000 : syllance
Nice job :)
the default admin page is a nice feature, and the controlpanel is a
very good idea. This goes in the good direction to make Drupal more
user friendly.
i agree with the dropdown menu and stylesheet additions, but i already
really appreciate the current version.
hope this will go into core soon, as it really makes the first admin
pages contact better :)
i don't mind scrolling through the nav menu and i rarely goes into
admin without checking the logs, but that definitely will help me
converting my wife's site to drupal :p
thanks !
------------------------------------------------------------------------
Sat, 17 Sep 2005 16:09:43 +0000 : der
I'll move the styles off to a style sheet but I'm uncertain about
whether or not make make the default admin page a dropdown. It's an
easy change and it eliminates any typos by the user but it also
restricts the user to a current visible admin menu item. If by chance
someone wanted to write their own admin start page (ie their own control
panel) they would have to hack the core system.module to do it.
Anyone else want to weigh in with their preference?
Also, anyone up for creating drupalized versions of the control panel
icons?
------------------------------------------------------------------------
Sat, 17 Sep 2005 16:16:15 +0000 : chx
Maybe just because I created it, I like my control panel module better.
------------------------------------------------------------------------
Sat, 17 Sep 2005 16:25:30 +0000 : der
If I would have known there was a module I wouldn't have written this
patch although I do think this would be good for core Drupal as the
default.
Is your modules a recent creation? I don't see it on drupal.org nor
could I find in the contribs section of CVS (either the modules or
sandbox sections). I'm I missing something? Is it called something
different?
------------------------------------------------------------------------
Sat, 17 Sep 2005 18:20:15 +0000 : syllance
chx control panel is located in his sandbox (cp.module), and thanks to
him for letting us know there's one :)
it's working fine (tested on HEAD) and provide interesting concept for
navigating through the admin, instead of just add a frontend. the
settings part is the better one, listing all elements in the page makes
quickly forget the standard menu.
der's one looks nice and provide a more immediate access to admin
pages, but the standard menu is still mandatory to access some elements
(dba or store settings for example, still needs to be accessed via left
menu).
to be honest, i like them both :)
being able to change the default admin page is very nice, and icons
make admin looks a lot better, raising the Woman Acceptance Factor by a
huge amount (my wife loves it :). but i also really like the more in
depth admin navigation offered by chx module.
mixing both on my head setup gives a nice result, so may be it would be
a good idea to join forces and mix the 2 panels.
chx, is your module somewhat official and scheduled to hit the core ?
------------------------------------------------------------------------
Sat, 17 Sep 2005 19:24:11 +0000 : Amazon
Hi, I asked Karoly to create the control panel module. It important
that the control panel be tied into the navigation menu block so that
it does not create inconsistent navigation.
The goal is to start a user experience grouping exercise to help the
community categorize administration tasks. The first thing that has
to happen is that administration must be considered a seperate
situation from creating personal content in Drupal. To support this
seperation of personal tasks and administration tasks we broke out
administration to have a separate theme in the CivicSpace theme.
Through research interviews into Drupal administration we need to
discover what the goals and tasks of administrators are. Some early
feedback is that site developers need modules to be evaluated on
Drupal.org. They have also indicated they need better and consistent
administration help ,with incontext list, which we have been adding.
We have also heard administrators want a quick overview. Any change to
provide a control panel like overview must have a dashboard like
overview. You should assume that we will identify a list of 5-7 top
goals for administrators.
Once those those 5-7 top goals are identified we need to ensure
administrators can acommplish tasks to achieve those goals. Some of
those tasks will completed by clicking through to icons or admin
interface links. Sub-goals will be accomplished by providing
effective navigation. We need to consider 4 types of navigation to be
added to the control panel: Global navigation, local navigation,
contextual navigation, and situational navigation. Some of this
navigation can be accomplished through a theme or blocks. Some will
need to be in the page and some need to be added in otherways, such as
interaction techniques.
Keep all this in mind when creating a control panel solution. It also
must respond to the fact that every site will have different
permissions set and different modules. This is a complex problem and
it's going to research and experimentation to get it right. But this
is a big step in the right direction.
Cheers,
Kieran
------------------------------------------------------------------------
Sat, 17 Sep 2005 19:47:55 +0000 : der
Attachment: http://drupal.org/files/issues/system.module_11.patch (5.61 KB)
This has sparked a lot of good discussion. I've taken a look at
cp.module and I think it really is complimentary with my proposed
patch. I've taken my patch one step further and provided the settings
icons in a collapsable group below the main control panel. This would
allow access to all admin functions without referring to the
traditional menu.
Syllance, do you think this addresses the gap you saw in my solution?
------------------------------------------------------------------------
Sat, 17 Sep 2005 20:33:10 +0000 : der
Kieran, I'm glad to see some serious thought going into the user
experience for site administrators. I think separating the user and
admin sections of the site is critical. It will not only allow
extensive usability work to be done for site admins it will also make
it much easier for theme creators as they will be able to focus on the
end user experience. I like the admin theme for civicspace. My only
dislike about the approach is that it's template driven which causes a
sites template to be larger and more complex due to handling all the
logic for user and admin themes. I think a better approach may be to
use a module such as the sections module. This allows you to have
smaller templates focused on user or admin themes.
I agree with your point about making sure the control panel ties into
them menu system. My approach uses the existing menu structure so
modules are added dynamically and all permissions are enforced.
------------------------------------------------------------------------
Sat, 17 Sep 2005 22:21:05 +0000 : chx
<?php
function _system_adminpage () {
drupal_goto($path = variable_get('site_adminpage', 'admin/controlpanel'), $query = NULL, $fragment = NULL);
}
?>
no way. Use menu !$may_cache and set the path based on the variable.
Adding in-line style elements is also a no-go.
The code style is not kept. Never a space between full stop and
apostrophe, always otherwise.
It's not $menuvisible but $menu_visible
I must be blind (it's 0:17am) but // Build the settings section of the
control panel does not seem to differ from the previous section. A
function may be appropriate.
------------------------------------------------------------------------
Sat, 17 Sep 2005 22:39:40 +0000 : der
Thanks for the code feedback. I'm assuming the extracted style info
would get patched to drupal.css?
Your right about the duplicate code. A function would make more sense,
I'll make the change.
I'm not sure about the comment to use "$may_cache" I've never used it
before. What's it's purpose? How should I use it in this situation.
I'll dig around and see if I can figure it out but I thought you might
be able to give me a little insight.
Thanks!
------------------------------------------------------------------------
Sun, 18 Sep 2005 10:41:00 +0000 : syllance
der, i've checked the new version of your control panel, and it does
simplify access to the settings menu (although with a complex setup,
the site config collapsable menu goes a lot more down than the menu,
but this a page and not a small menu so its still better)
however, there other case settings like, such as the ecommerce modules,
which provides a more complex menu tree (ex :
store->settings->payment->adjustments, each with their own admin
pages). these are not taken into account by your panel, leaving the
menu mandatory.
chx control panel handles this nicely with page navigation. going
through the store menu with chx panel is a real pleasure while its a
real pain with the menu. So i think the best would be to mix the two
panels, chx one handling page navigation, and yours providing a
frontend for basic admin pages, and collapsable site config items.
instead of linking to the standard admin pages, icons might link to chx
nav pages where there are sub entries.
i'm running both today, and this already makes the admin really better,
but i'm often switching from der panel to chx one (for store), so mixing
both would be, for me, a very nice solution :p
thanks for the good work :)
------------------------------------------------------------------------
Sun, 18 Sep 2005 12:54:55 +0000 : der
Attachment: http://drupal.org/files/issues/control_panel.patch (5.61 KB)
Here's a new patch with the code reworked per chx's comments with the
exception of his objection to my use of drupal_goto function. chx, I'm
probably missing something really obvious but I'm not understanding your
suggestion. Are you suggesting I use some menu function to do the
redirect? If so, I could not find one that suits my needs. Or are you
suggesting to use the drupal_goto function in a different manner than I
am using it. Like I said, I'm probably missing something really
obvious here but for the life of me I don't know what it is. Any
further advice would be greatly appreciated. The offending code below:
<?php
function _system_adminpage () {
drupal_goto($path = variable_get('site_adminpage', 'admin/controlpanel'), $query = NULL, $fragment = NULL);
}
?>
------------------------------------------------------------------------
Mon, 19 Sep 2005 13:42:57 +0000 : syllance
i think there's a problem with your latest patch. it seems to display
all icons as a vertical list. it may be a problem with my setup, but
i'm using basic themes that comes with head. the administer page is
thus very long, and this is not very useful. previous version was
better, imho :)
thanks
------------------------------------------------------------------------
Mon, 19 Sep 2005 14:10:03 +0000 : der
which theme and which browser are you using?
------------------------------------------------------------------------
Mon, 19 Sep 2005 15:59:16 +0000 : der
Attachment: http://drupal.org/files/issues/control_panel_0.patch (5.32 KB)
I've tested this with IE and FireFox with each of the Drupal shipped
HEAD themes and I'm not seeing the issue you described. Are you sure
the patch applied correctly to drupal.css?
Here's a slightly revised patch. It make the control panel icon group
collapsable but open by default.
------------------------------------------------------------------------
Mon, 19 Sep 2005 18:09:22 +0000 : der
Attachment: http://drupal.org/files/issues/control_panel_1.patch (5.64 KB)
Sorry for the excessive number of patches. I just realized that my
previous patch had an issue with icon image file names if there were
admin and admin/settings menu items that were the same (eg admin/user
and admin/settings/user).
New patch attached to address.
------------------------------------------------------------------------
Tue, 20 Sep 2005 02:13:49 +0000 : syllance
the vertical thing was probably due to a problem with my drupal.css.
i've tested your new patch with a fresh update and the display is fine,
but there's a bug.
the site configuration panel displays store settings items
(checkout,payment,shipping), and not the global settings one. this
might be due to the menus item having the same name 'settings',
although not located at the same level (administer/settings, and
administer/store/settings). ready for another patch ? :)
your panel adds a nice look and enable default administer page setup.
but there's still a lot of menu access needed when other modules are
setup (such as ecommerce), and i'm using it in addition to chx one to
provide a complete admin solution :)
chx one looks just like the theme you're using with no icons, but it
really help accelerating admin navigation. i'm wondering if integrating
both to core wouldn't be the ultimate solution. your panel more targeted
at standard admin needs, and chx one helping users that deals with lots
of modules & settings.
thanks again
------------------------------------------------------------------------
Tue, 20 Sep 2005 02:19:54 +0000 : Amazon
Hi, can you guys post some screen shots as you go along for those of us
who don't want to keep installing new patches.
1
0
Issue status update for
http://drupal.org/node/31326
Post a follow up:
http://drupal.org/project/comments/add/31326
Project: Drupal
Version: cvs
Component: system.module
Category: feature requests
Priority: normal
Assigned to: Anonymous
Reported by: der
Updated by: Amazon
Status: patch (code needs review)
Hi, can you guys post some screen shots as you go along for those of us
who don't want to keep installing new patches.
Amazon
Previous comments:
------------------------------------------------------------------------
Thu, 15 Sep 2005 17:50:52 +0000 : der
Attachment: http://drupal.org/files/issues/system_9.patch (4.27 KB)
New feature suggestion:
I would like to suggest a couple of enhancments to administration
pages.
First, add a new general settings option to allow the user to specify
the admin home page. Currently the watchdog log view is the default
home page.
Second, add a new control panel page that can be used as the default
admin start page.
I've attached a suggested patch to the CVS head version of the
system.module that implements these two enhancements. The patch does
the following.
Adds a new "default admin page" text field to the general settings
group (just after the "default front page"). It also changes the admin
menu entry to call a new function that examines the default "admin page"
variable and redirects to the appropriate path. For the control panel,
the patch adds a new function (system_admin_controlpanel). This
function basically looks for the admin entry in the menu structure and
then iterates through the child menu items and builds a control panel
page using the path and title information returned from the menu
structure. For the control panel icons it looks for an icon file in the
misc directory that matches the name of the menu item (e.g. user.png,
access.png etc) If it doesn't find an icon it uses a default. I've
also included some 48/48 icons that I borrowed from my
usr/share/icon/gnome directory of my local Linux box. I believe these
are gnome GPL'ed icons but any 48/48 icons could be used.
This patch allows users who prefer the current functionality to keep it
as their default. It provides the option for others to make any admin
page they want to be their admin "home page" including using a
graphical control panel. Module developers that add new admin menu
options can add their own custom icons for the control panel but they
are not "required" to do so as a default will be used if they don't
provide one.
------------------------------------------------------------------------
Thu, 15 Sep 2005 17:52:15 +0000 : der
Attachment: http://drupal.org/files/issues/drupal_controlpanel_icons.zip (39.09 KB)
48x48 icons attached
------------------------------------------------------------------------
Fri, 16 Sep 2005 14:30:16 +0000 : der
Attachment: http://drupal.org/files/issues/system_2_0.patch (4.5 KB)
updated patch. slightly changed the formatting of the control panel
page
------------------------------------------------------------------------
Sat, 17 Sep 2005 00:37:24 +0000 : moggy
I quite like this. It certainly goes some way to making Drupal easier on
the eyes for first time users.
I noticed there's a lot of hard coded style. Would this not be better
in a stylesheet and the code just containing classes and ids?
Also would a dropdown box of possible admin pages be better than trying
to remember how to spell controlpanel (something I'm having trouble with
tonight ;-) )
------------------------------------------------------------------------
Sat, 17 Sep 2005 13:02:08 +0000 : syllance
Nice job :)
the default admin page is a nice feature, and the controlpanel is a
very good idea. This goes in the good direction to make Drupal more
user friendly.
i agree with the dropdown menu and stylesheet additions, but i already
really appreciate the current version.
hope this will go into core soon, as it really makes the first admin
pages contact better :)
i don't mind scrolling through the nav menu and i rarely goes into
admin without checking the logs, but that definitely will help me
converting my wife's site to drupal :p
thanks !
------------------------------------------------------------------------
Sat, 17 Sep 2005 16:09:43 +0000 : der
I'll move the styles off to a style sheet but I'm uncertain about
whether or not make make the default admin page a dropdown. It's an
easy change and it eliminates any typos by the user but it also
restricts the user to a current visible admin menu item. If by chance
someone wanted to write their own admin start page (ie their own control
panel) they would have to hack the core system.module to do it.
Anyone else want to weigh in with their preference?
Also, anyone up for creating drupalized versions of the control panel
icons?
------------------------------------------------------------------------
Sat, 17 Sep 2005 16:16:15 +0000 : chx
Maybe just because I created it, I like my control panel module better.
------------------------------------------------------------------------
Sat, 17 Sep 2005 16:25:30 +0000 : der
If I would have known there was a module I wouldn't have written this
patch although I do think this would be good for core Drupal as the
default.
Is your modules a recent creation? I don't see it on drupal.org nor
could I find in the contribs section of CVS (either the modules or
sandbox sections). I'm I missing something? Is it called something
different?
------------------------------------------------------------------------
Sat, 17 Sep 2005 18:20:15 +0000 : syllance
chx control panel is located in his sandbox (cp.module), and thanks to
him for letting us know there's one :)
it's working fine (tested on HEAD) and provide interesting concept for
navigating through the admin, instead of just add a frontend. the
settings part is the better one, listing all elements in the page makes
quickly forget the standard menu.
der's one looks nice and provide a more immediate access to admin
pages, but the standard menu is still mandatory to access some elements
(dba or store settings for example, still needs to be accessed via left
menu).
to be honest, i like them both :)
being able to change the default admin page is very nice, and icons
make admin looks a lot better, raising the Woman Acceptance Factor by a
huge amount (my wife loves it :). but i also really like the more in
depth admin navigation offered by chx module.
mixing both on my head setup gives a nice result, so may be it would be
a good idea to join forces and mix the 2 panels.
chx, is your module somewhat official and scheduled to hit the core ?
------------------------------------------------------------------------
Sat, 17 Sep 2005 19:24:11 +0000 : Amazon
Hi, I asked Karoly to create the control panel module. It important
that the control panel be tied into the navigation menu block so that
it does not create inconsistent navigation.
The goal is to start a user experience grouping exercise to help the
community categorize administration tasks. The first thing that has
to happen is that administration must be considered a seperate
situation from creating personal content in Drupal. To support this
seperation of personal tasks and administration tasks we broke out
administration to have a separate theme in the CivicSpace theme.
Through research interviews into Drupal administration we need to
discover what the goals and tasks of administrators are. Some early
feedback is that site developers need modules to be evaluated on
Drupal.org. They have also indicated they need better and consistent
administration help ,with incontext list, which we have been adding.
We have also heard administrators want a quick overview. Any change to
provide a control panel like overview must have a dashboard like
overview. You should assume that we will identify a list of 5-7 top
goals for administrators.
Once those those 5-7 top goals are identified we need to ensure
administrators can acommplish tasks to achieve those goals. Some of
those tasks will completed by clicking through to icons or admin
interface links. Sub-goals will be accomplished by providing
effective navigation. We need to consider 4 types of navigation to be
added to the control panel: Global navigation, local navigation,
contextual navigation, and situational navigation. Some of this
navigation can be accomplished through a theme or blocks. Some will
need to be in the page and some need to be added in otherways, such as
interaction techniques.
Keep all this in mind when creating a control panel solution. It also
must respond to the fact that every site will have different
permissions set and different modules. This is a complex problem and
it's going to research and experimentation to get it right. But this
is a big step in the right direction.
Cheers,
Kieran
------------------------------------------------------------------------
Sat, 17 Sep 2005 19:47:55 +0000 : der
Attachment: http://drupal.org/files/issues/system.module_11.patch (5.61 KB)
This has sparked a lot of good discussion. I've taken a look at
cp.module and I think it really is complimentary with my proposed
patch. I've taken my patch one step further and provided the settings
icons in a collapsable group below the main control panel. This would
allow access to all admin functions without referring to the
traditional menu.
Syllance, do you think this addresses the gap you saw in my solution?
------------------------------------------------------------------------
Sat, 17 Sep 2005 20:33:10 +0000 : der
Kieran, I'm glad to see some serious thought going into the user
experience for site administrators. I think separating the user and
admin sections of the site is critical. It will not only allow
extensive usability work to be done for site admins it will also make
it much easier for theme creators as they will be able to focus on the
end user experience. I like the admin theme for civicspace. My only
dislike about the approach is that it's template driven which causes a
sites template to be larger and more complex due to handling all the
logic for user and admin themes. I think a better approach may be to
use a module such as the sections module. This allows you to have
smaller templates focused on user or admin themes.
I agree with your point about making sure the control panel ties into
them menu system. My approach uses the existing menu structure so
modules are added dynamically and all permissions are enforced.
------------------------------------------------------------------------
Sat, 17 Sep 2005 22:21:05 +0000 : chx
<?php
function _system_adminpage () {
drupal_goto($path = variable_get('site_adminpage', 'admin/controlpanel'), $query = NULL, $fragment = NULL);
}
?>
no way. Use menu !$may_cache and set the path based on the variable.
Adding in-line style elements is also a no-go.
The code style is not kept. Never a space between full stop and
apostrophe, always otherwise.
It's not $menuvisible but $menu_visible
I must be blind (it's 0:17am) but // Build the settings section of the
control panel does not seem to differ from the previous section. A
function may be appropriate.
------------------------------------------------------------------------
Sat, 17 Sep 2005 22:39:40 +0000 : der
Thanks for the code feedback. I'm assuming the extracted style info
would get patched to drupal.css?
Your right about the duplicate code. A function would make more sense,
I'll make the change.
I'm not sure about the comment to use "$may_cache" I've never used it
before. What's it's purpose? How should I use it in this situation.
I'll dig around and see if I can figure it out but I thought you might
be able to give me a little insight.
Thanks!
------------------------------------------------------------------------
Sun, 18 Sep 2005 10:41:00 +0000 : syllance
der, i've checked the new version of your control panel, and it does
simplify access to the settings menu (although with a complex setup,
the site config collapsable menu goes a lot more down than the menu,
but this a page and not a small menu so its still better)
however, there other case settings like, such as the ecommerce modules,
which provides a more complex menu tree (ex :
store->settings->payment->adjustments, each with their own admin
pages). these are not taken into account by your panel, leaving the
menu mandatory.
chx control panel handles this nicely with page navigation. going
through the store menu with chx panel is a real pleasure while its a
real pain with the menu. So i think the best would be to mix the two
panels, chx one handling page navigation, and yours providing a
frontend for basic admin pages, and collapsable site config items.
instead of linking to the standard admin pages, icons might link to chx
nav pages where there are sub entries.
i'm running both today, and this already makes the admin really better,
but i'm often switching from der panel to chx one (for store), so mixing
both would be, for me, a very nice solution :p
thanks for the good work :)
------------------------------------------------------------------------
Sun, 18 Sep 2005 12:54:55 +0000 : der
Attachment: http://drupal.org/files/issues/control_panel.patch (5.61 KB)
Here's a new patch with the code reworked per chx's comments with the
exception of his objection to my use of drupal_goto function. chx, I'm
probably missing something really obvious but I'm not understanding your
suggestion. Are you suggesting I use some menu function to do the
redirect? If so, I could not find one that suits my needs. Or are you
suggesting to use the drupal_goto function in a different manner than I
am using it. Like I said, I'm probably missing something really
obvious here but for the life of me I don't know what it is. Any
further advice would be greatly appreciated. The offending code below:
<?php
function _system_adminpage () {
drupal_goto($path = variable_get('site_adminpage', 'admin/controlpanel'), $query = NULL, $fragment = NULL);
}
?>
------------------------------------------------------------------------
Mon, 19 Sep 2005 13:42:57 +0000 : syllance
i think there's a problem with your latest patch. it seems to display
all icons as a vertical list. it may be a problem with my setup, but
i'm using basic themes that comes with head. the administer page is
thus very long, and this is not very useful. previous version was
better, imho :)
thanks
------------------------------------------------------------------------
Mon, 19 Sep 2005 14:10:03 +0000 : der
which theme and which browser are you using?
------------------------------------------------------------------------
Mon, 19 Sep 2005 15:59:16 +0000 : der
Attachment: http://drupal.org/files/issues/control_panel_0.patch (5.32 KB)
I've tested this with IE and FireFox with each of the Drupal shipped
HEAD themes and I'm not seeing the issue you described. Are you sure
the patch applied correctly to drupal.css?
Here's a slightly revised patch. It make the control panel icon group
collapsable but open by default.
------------------------------------------------------------------------
Mon, 19 Sep 2005 18:09:22 +0000 : der
Attachment: http://drupal.org/files/issues/control_panel_1.patch (5.64 KB)
Sorry for the excessive number of patches. I just realized that my
previous patch had an issue with icon image file names if there were
admin and admin/settings menu items that were the same (eg admin/user
and admin/settings/user).
New patch attached to address.
------------------------------------------------------------------------
Tue, 20 Sep 2005 02:13:49 +0000 : syllance
the vertical thing was probably due to a problem with my drupal.css.
i've tested your new patch with a fresh update and the display is fine,
but there's a bug.
the site configuration panel displays store settings items
(checkout,payment,shipping), and not the global settings one. this
might be due to the menus item having the same name 'settings',
although not located at the same level (administer/settings, and
administer/store/settings). ready for another patch ? :)
your panel adds a nice look and enable default administer page setup.
but there's still a lot of menu access needed when other modules are
setup (such as ecommerce), and i'm using it in addition to chx one to
provide a complete admin solution :)
chx one looks just like the theme you're using with no icons, but it
really help accelerating admin navigation. i'm wondering if integrating
both to core wouldn't be the ultimate solution. your panel more targeted
at standard admin needs, and chx one helping users that deals with lots
of modules & settings.
thanks again
1
0