January 2005 - Development - lists.drupal.org

[drupal-devel] [bug] files folder created with incorrect permissions
by Morbus Iff 21 Jan '05

21 Jan '05

Project: Drupal Version: cvs Component: file system Category: bug reports Priority: normal Assigned to: Morbus Iff Reported by: Anonymous Updated by: Morbus Iff Status: patch This is a list of known possibilities that the proposed patch/UI addresses. In each case, the proposed solution above will, BY DEFAULT, create directories as 771 and files as 640. These possibilities run through a number of ownership possibilities, and any solutions in regards to an FTP user. Possibility #1 (traditional): * Drupal runs as user wwwrun, group nogroup. * FTP user IS NOT a member of group nogroup. * FTP user WILL see a Drupal-created directory. * FTP user WILL NOT be able to modify/view Drupal-created directory. * FTP user WILL NOT be able to modify/view Drupal-created files. * Solution: Toggle "read/write for everybody" for files/directories. * Pro: 777/666 is the only way this problem could be solved for FTP user. Possibility #2 (suexec/suPHP). * Drupal runs as user FTPuser, group users. * FTP user IS a member of group users. * FTP user WILL see a Drupal-created directory. * FTP user WILL be able to modify/view Drupal-created directory. * FTP user WILL be able to modify/view Drupal-created files. * Solution: None necessary. New defaults are fine. Possibility #3 (oddball configuration): * Drupal runs as user wwwrun, group users. * FTP user IS a member of group users. * FTP user WILL see a Drupal-created directory. * FTP user WILL be able to modify/view Drupal-created directories. * FTP user WILL be able to view Drupal-created files. * FTP user WILL NOT be able to modify/delete Drupal-created files. * Solution: Toggle "read/write for everybody" for files/directories. * Con: Gives "everybody" too many permissions. * Pro: This is an oddball config I've never seen. Possibility #4 (oddball configuration): * Drupal runs as user FTPuser, group nogroup. * FTP user IS NOT a member of group nogroup. * FTP user WILL see a Drupal-created directory. * FTP user WILL be able to modify/view Drupal-created directory. * FTP user WILL be able to modify/view Drupal-created files. * Solution: None necessary. New defaults are fine. * Pro: This is an oddball config I've never seen. Morbus Iff Previous comments: ------------------------------------------------------------------------ September 8, 2004 - 13:04 : Anonymous Hi,- > [rreading@tribal html]$ ls -l www/files > total 12 > drwxr----- 2 nobody nobody 4096 Sep 8 12:22 pictures > drwxrwxrwx 2 rreading users 4096 Sep 8 12:33 tmp > drwxr----- 3 nobody nobody 4096 Sep 8 12:33 upload the problem is very strange, and might even be a nasty drupal bug: As of the CVS version we decided to let drupal generate the folders itself, so that Joe User needs not to use ssh or ftp to make /configure various folders. So these were generated by PHP and thus have the wrong permission. The user PHP is a differnet user in this case, and something that PHP created is inacessible to us. I am aware that this is sierverspecific, but its annoying enought for me (and probably others) not to ignore. Regards, Ber ------------------------------------------------------------------------ November 18, 2004 - 21:46 : dtan Any update on this. . ?? I recently installed the 4.5 Head and the problem still exists. Recommendations on how to actually change the permission on the folder? dtan ------------------------------------------------------------------------ November 28, 2004 - 10:53 : killes(a)www.drop.org The apache user did create this directories. So it is natural that they have the apache user "nobody" as owner. Drupal should be able to handle this just file. Can we close this report? ------------------------------------------------------------------------ November 28, 2004 - 10:58 : Bèr Kessels No, please do not close. Its a bug IMO. Because a lot of (v)hosts do not put apache in the same group as the FTP user. It will work, file uplaods etc will work for Drupal, but you, as user, cannot access the files anymore by FTP. But even worse, you cannot remove your drupal installation, without intervention of root (or the server maintainer). I had two "empty" domains with 30 MB of files taking up space for 3 months. Another domain will not let me mirror (backup) anything because of this. ------------------------------------------------------------------------ November 29, 2004 - 22:55 : svemir If PHP/apache can create these folders, it should be able to remove them as well. Perhaps an option somewhere to remove folders created by Drupal? Maybe a button next to the place in administration where the folder is specified. And also maybe the creation of the folders should be optional in the first place... ------------------------------------------------------------------------ January 19, 2005 - 20:52 : Morbus Iff This just bit me today too. Installed the banner.module, and ensured that my files/ directory was 777, with the owner as gangrene:user. Uploaded a new banner, and for various reasons, it didn't work. As I started to investigate, I found that the files/banner directory, which was "successfully" created (success determined by "I can access files uploaded in that folder via a URL) was not visible to my FTP server (at this point, proFTPd, though I've not yet tested on vsftpd). One of ProFTPds feature is to hide folders that do not have the executable bit set. The default permissions of Drupal is not to set these, per file_check_directory in includes/file.inc. So, my newly Drupal-created files/banners folder was given the permissions of (where wwwrun and nogroup are the Apache user/group). drwxrw---- 2 wwwrun nogroup 88 Jan 19 20:03 banners Since there's no execute for everyone, and since the "gangrene" user is not part of "nogroup", I was not able to see, access, or modify the newly created folder. I had to manually issue chmod('files/banners', 0761) to even look at the blasted thing. My recommendation is to change the file_check_directory chmod to 0771, which should create drwxrwx--x permissions. The extra execute permission on the "nogroup" is harmless, and allows ProFTPd to display it (in this case to "nogroup", but also perhaps to the "users" group on other systems), and the execute permission for everyone is absolutely required for me to see it in under ProFTPD. These permissions are giving any extra (or damaging) permissions to anyone, but merely following the expectations of various FTP servers concerning "what a directory is". There's a similar bug related to uploaded files, but I've not yet found the code for that one. ------------------------------------------------------------------------ January 19, 2005 - 20:55 : Morbus Iff Grrrr... "these permissions are NOT giving any extra (or damaging) permissions". ------------------------------------------------------------------------ January 19, 2005 - 21:12 : Morbus Iff To revise my previous statement, it would be best to use perms 0765, which adds "read" access to the "everyone" group. The correction is simple: if we want to /see/ the folder in FTP, then we also want to see /inside/ the folder via FTP. Again, I don't believe this change really gives extra dangerous permissions to anyone, merely grants the same permission to an authenticated FTP user (if a file upload can be seen on the web by people who know its there, then the same access should be applied to FTP users with the right knowledge [ie., un/pw]). ------------------------------------------------------------------------ January 19, 2005 - 21:29 : Morbus Iff Alrighty, hunted down the file (not directory) related problem. Unlike directories, which require us to enter a mode, file uploads are not specified, thus they take on the default umask of the web server's user (in my case, wwwgroup:nogroup, 640). This further causes problems with FTP viewing because "everyone" has no permission (in my case, since I'm a part of the "users" group, I can not view, modify, delete, mirror, etc. files that have been uploaded through Drupal). This has been tracked down to file_copy() (includes/file.inc) and the following lines, which copy the uploaded file from the temp directory ($source) to the final destination ($dest). if (!@copy($source, $dest)) { drupal_set_message(t('File copy failed.'), 'error'); return 0; } My proposal is to add an explicit chmod after the copy, granting read permission to "everyone", something to the effect of the following, which will give read and write to the webserver process, read to the webserver group, and read to everyone (ie., little old me, not of the webserver group). if (!@copy($source, $dest)) { drupal_set_message(t('File copy failed.'), 'error'); return 0; } chmod($dest, 0644). ------------------------------------------------------------------------ January 19, 2005 - 21:40 : Morbus Iff Attachment: http://drupal.org/files/issues/fileperm.patch (606 bytes) Attached is a patch for Drupal 4.5.1 that implements these changes (directory is set for 764, not 765 - the mode in my previous comment was [another] error). Last time I contributed a patch, I created a bug so please review extra carefully. ------------------------------------------------------------------------ January 20, 2005 - 11:27 : Morbus Iff In chatting about this with #drupal, I'm thinking that something more than just "sane defaults" needs to be enabled. The patch I just submitted still has one "fatal" flaw: it doesn't allow write permissions for the FTP user. This was ultimately deliberate (more chance of accepting the patch with less dangerous permission, and the assumption that a Drupal-controlled upload also offered a Drupal-controlled deletion), but still isn't ideal. Unfortunately, with SuEXEC servers and various configurations, there is no SAFE default: on one hand you're giving 666 to everyone because you have to (wwwrun:nogroup) and on the other, 666 is too much (if you're running under SuEXEC, then gangrene:users/640 is right, and 666 is wrong). I think the only way this will be truly solved is with user intervention, which means umask settings for file/directory in the "Files" section of admin/setting. This is also the same solution that Movable Type uses, which allows two special settings in its mt.cfg: # When creating files and directories, Movable Type uses umask settings to # control the permissions set on the files. The default settings for file # creation (HTMLUmask, DBUmask, and UploadUmask) are 0111; for directory # creation (DirUmask), the default is 0000. You should not change these # settings unless you are running MT under cgiwrap or suexec, or some other # scenario where the MT application runs as you; in addition, you should not # change these settings unless you know what they mean, and what they do. # # DBUmask 0022 # HTMLUmask 0022 # UploadUmask 0022 # DirUmask 0022 # # In addition to controlling permissions via umask settings, you can also # use the HTMLPerms and UploadPerms settings to control the default # permissions for files created by the system (either as output files or # uploaded files). The only real use of this is to turn on the executable bit # of files created by the system--for example, if MT is generating PHP files # that need to have the executable bit turned on, you could set HTMLPerms # to 0777. The default is 0666. You should not change these settings unless # you know what they mean, and what they do. # # HTMLPerms 0777 # UploadPerms 0777 For our needs, we'd really only need a DirectoryUmask and a FileUmask option. Is this an amicable solution to anyone? If I get you a patch, will this be implemented in Drupal 4.6? ------------------------------------------------------------------------ January 21, 2005 - 11:58 : Morbus Iff After further reflection, I'm now leaning toward: * leave the current Drupal permissions as they are (ignore my previous patch). * add GUI options to change the directory/file mode (per last comment). The GUI would be two sets of dropdown boxes, one for files and one for directories. The automatically chosen option for Files would be "read/write for Drupal only" (umask: 0640), with another option of "read/write for everybody" (umask: 0666). The directory options would be the same with the following umasks 0771 or 0777. -- View: http://drupal.org/node/10658 Edit: http://drupal.org/project/comments/add/10658

1 0

[drupal-devel] [bug] files folder created with incorrect permissions
by Morbus Iff 21 Jan '05

21 Jan '05

Project: Drupal Version: cvs Component: file system Category: bug reports Priority: normal Assigned to: Morbus Iff Reported by: Anonymous Updated by: Morbus Iff Status: patch After further reflection, I'm now leaning toward: * leave the current Drupal permissions as they are (ignore my previous patch). * add GUI options to change the directory/file mode (per last comment). The GUI would be two sets of dropdown boxes, one for files and one for directories. The automatically chosen option for Files would be "read/write for Drupal only" (umask: 0640), with another option of "read/write for everybody" (umask: 0666). The directory options would be the same with the following umasks 0771 or 0777. Morbus Iff Previous comments: ------------------------------------------------------------------------ September 8, 2004 - 13:04 : Anonymous Hi,- > [rreading@tribal html]$ ls -l www/files > total 12 > drwxr----- 2 nobody nobody 4096 Sep 8 12:22 pictures > drwxrwxrwx 2 rreading users 4096 Sep 8 12:33 tmp > drwxr----- 3 nobody nobody 4096 Sep 8 12:33 upload the problem is very strange, and might even be a nasty drupal bug: As of the CVS version we decided to let drupal generate the folders itself, so that Joe User needs not to use ssh or ftp to make /configure various folders. So these were generated by PHP and thus have the wrong permission. The user PHP is a differnet user in this case, and something that PHP created is inacessible to us. I am aware that this is sierverspecific, but its annoying enought for me (and probably others) not to ignore. Regards, Ber ------------------------------------------------------------------------ November 18, 2004 - 21:46 : dtan Any update on this. . ?? I recently installed the 4.5 Head and the problem still exists. Recommendations on how to actually change the permission on the folder? dtan ------------------------------------------------------------------------ November 28, 2004 - 10:53 : killes(a)www.drop.org The apache user did create this directories. So it is natural that they have the apache user "nobody" as owner. Drupal should be able to handle this just file. Can we close this report? ------------------------------------------------------------------------ November 28, 2004 - 10:58 : Bèr Kessels No, please do not close. Its a bug IMO. Because a lot of (v)hosts do not put apache in the same group as the FTP user. It will work, file uplaods etc will work for Drupal, but you, as user, cannot access the files anymore by FTP. But even worse, you cannot remove your drupal installation, without intervention of root (or the server maintainer). I had two "empty" domains with 30 MB of files taking up space for 3 months. Another domain will not let me mirror (backup) anything because of this. ------------------------------------------------------------------------ November 29, 2004 - 22:55 : svemir If PHP/apache can create these folders, it should be able to remove them as well. Perhaps an option somewhere to remove folders created by Drupal? Maybe a button next to the place in administration where the folder is specified. And also maybe the creation of the folders should be optional in the first place... ------------------------------------------------------------------------ January 19, 2005 - 20:52 : Morbus Iff This just bit me today too. Installed the banner.module, and ensured that my files/ directory was 777, with the owner as gangrene:user. Uploaded a new banner, and for various reasons, it didn't work. As I started to investigate, I found that the files/banner directory, which was "successfully" created (success determined by "I can access files uploaded in that folder via a URL) was not visible to my FTP server (at this point, proFTPd, though I've not yet tested on vsftpd). One of ProFTPds feature is to hide folders that do not have the executable bit set. The default permissions of Drupal is not to set these, per file_check_directory in includes/file.inc. So, my newly Drupal-created files/banners folder was given the permissions of (where wwwrun and nogroup are the Apache user/group). drwxrw---- 2 wwwrun nogroup 88 Jan 19 20:03 banners Since there's no execute for everyone, and since the "gangrene" user is not part of "nogroup", I was not able to see, access, or modify the newly created folder. I had to manually issue chmod('files/banners', 0761) to even look at the blasted thing. My recommendation is to change the file_check_directory chmod to 0771, which should create drwxrwx--x permissions. The extra execute permission on the "nogroup" is harmless, and allows ProFTPd to display it (in this case to "nogroup", but also perhaps to the "users" group on other systems), and the execute permission for everyone is absolutely required for me to see it in under ProFTPD. These permissions are giving any extra (or damaging) permissions to anyone, but merely following the expectations of various FTP servers concerning "what a directory is". There's a similar bug related to uploaded files, but I've not yet found the code for that one. ------------------------------------------------------------------------ January 19, 2005 - 20:55 : Morbus Iff Grrrr... "these permissions are NOT giving any extra (or damaging) permissions". ------------------------------------------------------------------------ January 19, 2005 - 21:12 : Morbus Iff To revise my previous statement, it would be best to use perms 0765, which adds "read" access to the "everyone" group. The correction is simple: if we want to /see/ the folder in FTP, then we also want to see /inside/ the folder via FTP. Again, I don't believe this change really gives extra dangerous permissions to anyone, merely grants the same permission to an authenticated FTP user (if a file upload can be seen on the web by people who know its there, then the same access should be applied to FTP users with the right knowledge [ie., un/pw]). ------------------------------------------------------------------------ January 19, 2005 - 21:29 : Morbus Iff Alrighty, hunted down the file (not directory) related problem. Unlike directories, which require us to enter a mode, file uploads are not specified, thus they take on the default umask of the web server's user (in my case, wwwgroup:nogroup, 640). This further causes problems with FTP viewing because "everyone" has no permission (in my case, since I'm a part of the "users" group, I can not view, modify, delete, mirror, etc. files that have been uploaded through Drupal). This has been tracked down to file_copy() (includes/file.inc) and the following lines, which copy the uploaded file from the temp directory ($source) to the final destination ($dest). if (!@copy($source, $dest)) { drupal_set_message(t('File copy failed.'), 'error'); return 0; } My proposal is to add an explicit chmod after the copy, granting read permission to "everyone", something to the effect of the following, which will give read and write to the webserver process, read to the webserver group, and read to everyone (ie., little old me, not of the webserver group). if (!@copy($source, $dest)) { drupal_set_message(t('File copy failed.'), 'error'); return 0; } chmod($dest, 0644). ------------------------------------------------------------------------ January 19, 2005 - 21:40 : Morbus Iff Attachment: http://drupal.org/files/issues/fileperm.patch (606 bytes) Attached is a patch for Drupal 4.5.1 that implements these changes (directory is set for 764, not 765 - the mode in my previous comment was [another] error). Last time I contributed a patch, I created a bug so please review extra carefully. ------------------------------------------------------------------------ January 20, 2005 - 11:27 : Morbus Iff In chatting about this with #drupal, I'm thinking that something more than just "sane defaults" needs to be enabled. The patch I just submitted still has one "fatal" flaw: it doesn't allow write permissions for the FTP user. This was ultimately deliberate (more chance of accepting the patch with less dangerous permission, and the assumption that a Drupal-controlled upload also offered a Drupal-controlled deletion), but still isn't ideal. Unfortunately, with SuEXEC servers and various configurations, there is no SAFE default: on one hand you're giving 666 to everyone because you have to (wwwrun:nogroup) and on the other, 666 is too much (if you're running under SuEXEC, then gangrene:users/640 is right, and 666 is wrong). I think the only way this will be truly solved is with user intervention, which means umask settings for file/directory in the "Files" section of admin/setting. This is also the same solution that Movable Type uses, which allows two special settings in its mt.cfg: # When creating files and directories, Movable Type uses umask settings to # control the permissions set on the files. The default settings for file # creation (HTMLUmask, DBUmask, and UploadUmask) are 0111; for directory # creation (DirUmask), the default is 0000. You should not change these # settings unless you are running MT under cgiwrap or suexec, or some other # scenario where the MT application runs as you; in addition, you should not # change these settings unless you know what they mean, and what they do. # # DBUmask 0022 # HTMLUmask 0022 # UploadUmask 0022 # DirUmask 0022 # # In addition to controlling permissions via umask settings, you can also # use the HTMLPerms and UploadPerms settings to control the default # permissions for files created by the system (either as output files or # uploaded files). The only real use of this is to turn on the executable bit # of files created by the system--for example, if MT is generating PHP files # that need to have the executable bit turned on, you could set HTMLPerms # to 0777. The default is 0666. You should not change these settings unless # you know what they mean, and what they do. # # HTMLPerms 0777 # UploadPerms 0777 For our needs, we'd really only need a DirectoryUmask and a FileUmask option. Is this an amicable solution to anyone? If I get you a patch, will this be implemented in Drupal 4.6? -- View: http://drupal.org/node/10658 Edit: http://drupal.org/project/comments/add/10658

1 0

Re: [drupal-devel] New sitemap module
by Boris Mann 21 Jan '05

21 Jan '05

Any reason you didn't update the existing sitemap module? This seems very, very similar (yours is better, I think, but e.g. there are RSS links in the other one). I suggest that you combine forces with the other one. Also, I have always wanted an (expanded to some level) view of the book pages available. I would think that those are definitely part of a sitemap (I've never used taxonomy to structure site content, only to categorize). On Thu, 20 Jan 2005 15:30:08 -0500, K B <kbahey(a)gmail.com> wrote: > I have checked into the repository a new simple sitemap module. > > This module allows a taxonomy based overview of the site, in a > hierarchy view.

3 2

[drupal-devel] ShortStat for Drupal
by Chris Messina 21 Jan '05

21 Jan '05

I would love to see ShortStat (http://www.shauninman.com/mentary/past/shortstat_beta_3.php) by Shaun Inman ported to Drupal or for its implementation to *at least* serve as a UI model to follow. I simply love how elegant it is and how easy it is to see, at a glance, what's going on with your site: http://www.flickr.com/photos/factoryjoe/3518872/ No flash: http://photos3.flickr.com/3518872_4622c752af_o.png Live: http://ryanberg.net/shortstat Does watchdog have the right hooks to make this page possible? Could I write it up in PHP and then style it accordingly? Note that I'm more interested with the Tuftesque presentation of the information rather than the analysis done by the actual statistics module. Chris

11 27

[drupal-devel] [feature] Enable themeing of blank calendar days
by Goba 21 Jan '05

21 Jan '05

Project: Drupal Version: cvs Component: archive.module Category: feature requests Priority: normal Assigned to: Goba Reported by: Goba Updated by: Goba Status: patch Good to get input on this :) Either way is fine with me, but making the whole calendar themeable is a lot more work in the code, since now logic and display are very much intermixed in the calendar code. It would be nice, if the CSS solution would work. Goba Previous comments: ------------------------------------------------------------------------ January 15, 2005 - 20:30 : Goba Attachment: http://drupal.org/files/issues/drupalcal.png (16.16 KB) I would like to have a calendar which has stlyes for every blank day, as opposed to what is supported by current Drupal HEAD. It should look something like: I see that it would only be possible if we make the blank days themeable. It would be possible to make the whole calendar themeable, but that would open up a lot more stuff, since then the calendar code would need to be abstracted out from the archive table assembler code. BTW this is a Hungarian Drupal setup, with monday being the first day, and the calendar is for 2005 January. ------------------------------------------------------------------------ January 15, 2005 - 20:38 : Goba Attachment: http://drupal.org/files/issues/Drupal.allow.themeing.blank.days.patch (1.28 KB) Here is a proposed patch, which simply makes the blank days themeable, so that I can use str_repeat("�\n", $blankdays) in my theme. ------------------------------------------------------------------------ January 21, 2005 - 14:58 : Goba What is this patch is waiting for? :) ------------------------------------------------------------------------ January 21, 2005 - 15:07 : Steven I'm leaning towards making the whole calendar themable rather than just the blank days. It seems a bit too shallow. Another thing to consider is to simply output the blank days as individual cells, and use CSS to hide their border in the default themes (it uses border-collapse: collapse; so I think it wouldn't require special handling of the first/last blank cell). -- View: http://drupal.org/node/15655 Edit: http://drupal.org/project/comments/add/15655

1 0

[drupal-devel] [feature] Enable themeing of blank calendar days
by Steven 21 Jan '05

21 Jan '05

Project: Drupal Version: cvs Component: archive.module Category: feature requests Priority: normal Assigned to: Goba Reported by: Goba Updated by: Steven Status: patch I'm leaning towards making the whole calendar themable rather than just the blank days. It seems a bit too shallow. Another thing to consider is to simply output the blank days as individual cells, and use CSS to hide their border in the default themes (it uses border-collapse: collapse; so I think it wouldn't require special handling of the first/last blank cell). Steven Previous comments: ------------------------------------------------------------------------ January 15, 2005 - 20:30 : Goba Attachment: http://drupal.org/files/issues/drupalcal.png (16.16 KB) I would like to have a calendar which has stlyes for every blank day, as opposed to what is supported by current Drupal HEAD. It should look something like: I see that it would only be possible if we make the blank days themeable. It would be possible to make the whole calendar themeable, but that would open up a lot more stuff, since then the calendar code would need to be abstracted out from the archive table assembler code. BTW this is a Hungarian Drupal setup, with monday being the first day, and the calendar is for 2005 January. ------------------------------------------------------------------------ January 15, 2005 - 20:38 : Goba Attachment: http://drupal.org/files/issues/Drupal.allow.themeing.blank.days.patch (1.28 KB) Here is a proposed patch, which simply makes the blank days themeable, so that I can use str_repeat("�\n", $blankdays) in my theme. ------------------------------------------------------------------------ January 21, 2005 - 14:58 : Goba What is this patch is waiting for? :) -- View: http://drupal.org/node/15655 Edit: http://drupal.org/project/comments/add/15655

1 0

[drupal-devel] [feature] Enable themeing of blank calendar days
by Goba 21 Jan '05

21 Jan '05

Project: Drupal -Version: 4.5.0 +Version: cvs Component: archive.module Category: feature requests Priority: normal Assigned to: Goba Reported by: Goba Updated by: Goba Status: patch What is this patch is waiting for? :) Goba Previous comments: ------------------------------------------------------------------------ January 15, 2005 - 20:30 : Goba Attachment: http://drupal.org/files/issues/drupalcal.png (16.16 KB) I would like to have a calendar which has stlyes for every blank day, as opposed to what is supported by current Drupal HEAD. It should look something like: I see that it would only be possible if we make the blank days themeable. It would be possible to make the whole calendar themeable, but that would open up a lot more stuff, since then the calendar code would need to be abstracted out from the archive table assembler code. BTW this is a Hungarian Drupal setup, with monday being the first day, and the calendar is for 2005 January. ------------------------------------------------------------------------ January 15, 2005 - 20:38 : Goba Attachment: http://drupal.org/files/issues/Drupal.allow.themeing.blank.days.patch (1.28 KB) Here is a proposed patch, which simply makes the blank days themeable, so that I can use str_repeat("�\n", $blankdays) in my theme. -- View: http://drupal.org/node/15655 Edit: http://drupal.org/project/comments/add/15655

1 0

Re: [drupal-devel] Dealing with spam (was rel=nofollow)
by mike＠fuckingbrit.com 21 Jan '05

21 Jan '05

> And as smart, and are fighting this for a longer time. Yeah, the new tactic, which we need to be aware of, is targetting a vulnerable site with spam. When a site is found that leaves the spam up, then spamming the URL to /that/ site, that might appear valid to a webmaster, to raise the google ranking of that site and thus the ranking boost the links to the real target get as a result. Nasty little so and so's aren't they? -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web.com/ .

1 0

[drupal-devel] Making Drupal fully 'community-driven': A Proposal for restructuring the Drupal project
by Nedjo Rogers 21 Jan '05

21 Jan '05

Following up (finally!) on a commitment I made some months back, I've prepared a set of concrete proposals for renewing Drupal's (arguably) outdated decision making structure. They are posted as a forum topic at: http://drupal.org/node/15916 Please read and comment! The 'teaser': Drupal - a highly promising and excellently designed open source software - prides itself on being "community-driven". A primary Drupal interest is promoting collaboration and the sharing of views and perspectives. Yet, paradoxically, the project decision-making structure- a relic from its very early days - is notable for its closed, centralized, and fixed nature. Most decisions on the Drupal 'core' are still made personally by the project owner and founder, Dries. The only exceptions are decisions made by one of two close associates of his. This contrasts sharply with many other open source projects, which are build on the basis of community decision making. To fully mature as a project, Drupal arguably needs to bring its structure in line with its community spirit. Hence this set of concrete proposals. Their aim is to set out new, expanded roles for decision making, while ensuring that the current values of rigourous code evaluation and development are maintained.

5 4

Re: [drupal-devel] Dealing with spam (was rel=nofollow)
by Jeremy Andrews 21 Jan '05

21 Jan '05

On Fri, 21 Jan 2005 07:49:08 -0000 "Michael Jervis" <mike(a)fuckingbrit.com> wrote: > I've been thinking, I intend to implement this as a new module that > requires the spam module and works with it to keep the code modular and > separate. I think this is the right way to go as it allows the > functionality to be totally removed if people don't want it. I agree it should be a seperate module. > I've had a swift first look at the spam schema, I'm thinking these need > to go into the custom table as regexes, but also need marking as MT > items for management. I'd add an itemtype column or some such, and > insert MT for moveable type items. This should make it all transparent > to the spam plugin, but allow the MT Blacklist plugin to know which > items it shouldn't touch. The first section of the file contains regexps. Those should go into the spam_custom table as you've described. The second section could either be inserted into spam_custom or spam_tokens with URL* prepended to be treated as URL filters. It's probably easier to keep them all in the custom filter table as you've suggested. > I think the first iteration should provide: > > 1) Manually triggered one shot, load the master list. > 2) Cron managed periodic update of additions and deletions. > 3) Manual trigger of 2. Step one is unnecessary. Cron will kick off the first shot, too. But it can be nice to provide a manual "update now" button to test, etc. The add/update/delete logic in 1 and 2 should be the same. (ie, you'll want to be sure that none of the custom filters have already been manually added by the admin) -Jeremy

1 0