Talk:Drupal/Archives/2008/June

Criticisms, Views module, & Security

Okay, rather than get into an edit war, let's discuss what is appropriate for the criticisms section. In particular I have problems with the "best practices" issue that has been going back and forth. First of all, I want to make clear-- I don't have a particular POV in whether or not the Views module should or should not list unpublished nodes by default. For me the three primary issues for inclusion are:

(1) is this a notable criticism?

(2) Because Views is not a part of Drupal core, is this a criticism of Drupal itself?

(3) Is the criticism valid? Is this a legitimate criticism of a security flaw?

Now, even if (3) is not true, it may be useful to mention the criticism and then note something like "the author of Views, however, defends the current practice because X,Y, and Z." to provide a context for the reader.

Regarding (2) -- I tend to think this criticism belongs in an article about the Views module itself. It is at best a little confusing why it would go in the Drupal article. I understand many people use Views (which the article notes), but to go into detail about a criticism on Drupal's default behavior seems a little oblique and suggests a biased POV. Better to spin off into its own article. The criticisms should be about Drupal itself, not problems in spin-off projects. (unless there's something inherent in Drupal that would result in security problems in spinoffs)

Regarding (1) -- I guess i've touched on it a bit. I think if the problem were inherent to Drupal (assuming it is legitimately a problem), it might arguably be notable. But it's scope is the reason I dont' think it belongs.

Let me also address the second criticism about security in general. I think a "Drupal is insecure" section is fair, but I'd expect it to read something like "The developers of Drupal have generally maintained a cavalier attitude towards security. Zillions of bugs have been documented and remain unpatched. The basic architecture has such-and-such a problem" all with refs to support the assertions (or support that other people have made the assertions and let the reader decide). The current sentence that refers to 30 remote exploits does not give any context-- is this a lot of bugs for a project of its size? Do other similar projects have the same number of bugs? Are these bugs considered especially serious? Is the criticism that these bugs remained unpatched or perhaps undiscovered for some length of time? What is Drupal's security policy? In other words, what is the real criticism? Moreover, I am not especially moved with the ref that included 3rd party modules as "drupal bugs". Drupal core, to my knowledge, has had a few remotely exploitable bugs, but they have been patched w/timely releases. A legitimate criticism should argue a flaw in Drupal core's development, security policy, or patching practice... If there is such a criticism, and it is supported with refs, it should certainly go in the article. But what I've seen so far is basically allegation without substance. --Replysixty (talk) 01:17, 3 June 2008 (UTC)

Drupal is a broad project. Views is made by a key Drupal contributor. Views, along with CCK, are universally cited as the key 2 contributed modules. Even this article says so. They are so key that both modules are tracked for integration as a bona fide part of the Drupal system.

This is very significant because 1. a module considered so key to well-running Drupal installs has such a critical security hole and 2. this hole is defended on basis of the author's popularity or unwillingness to fix the problem is significant. It speaks to Drupal's culture, which may be too laissez faire? Well, THAT is POV, which is why that particular assertion isn't present in the main article. But what is mentioned in the article is very significant and documented.

As for whether it is valid to say this is a security flaw, jeez, wake up! Any use of the module exposes confidential data in its default state. If that's not a security flaw, then what is it? A peanut butter and jelly sandwich?

I'm going to play devil's advocate here. First off, "confidential" and "unpublished" are not quite the same thing. Second, if Views is conceived of essentially a Web-friendly UI built over SQL queries, then its behavior is correct-- an SQL query built out of the view would not filter out unpublished nodes unless explicitly instructed to do so. Third, as one who has personally inadvertently exposed unpublished info in a View, when I realized this, I went "Oh, I've been using Views incorrectly. I need to specify that I want unpublished nodes only." And that was it. Actually my first instinct was not "WHAT?!! THIS IS A BUG?!!" it was more like "oh, I'm such an idiot, I forgot to include published only." --Replysixty (talk) 00:30, 5 June 2008 (UTC)

There is a subset/superset relationship: unpublished is analogous to not intended for public distribution which is a subset of all data that is considered confidential.

It is a gross simplification to suggest that breaching confidentiality is OK because a system is "essentially a Web-friendly UI built over SQL queries". How would you feel about "essentially a Web-friendly UI built over SQL queries" the underlying database was your bank information?

To say the least, it's quite odd that the rest of Drupal seems to embrace security by design, but the Views module has such a wide-open security hole.

Novasource (talk) 02:51, 5 June 2008 (UTC)

As for the security flaws, you are invited to counter. But you can't counter with ad ignorance (i.e., we don't know so it's not a flaw).

If you can neutralize the criticism with documented counterargument, then please use that to neutralize it and maybe delete it if invalid. But don't delete the documented criticism just because it doesn't support your own POV toward Drupal's security.

BTW, yes, criticism of Drupal IS POV. It's a point of view contrary to the prevailing attitude of the Drupal management. It is relevant because it has allowed a major hole that runs contrary to well established, universal security concepts.

Further attempts to summarily delete this referenced content will be considered censorship.

Novasource (talk) 03:30, 3 June 2008 (UTC)

It's debatable as to whether this is a security hole or merely a poor default setting. That said, Views is a user-contributed module, and not part of Drupal. Devoting several paragraphs to a user contributed module's default settings is dubious. There are more obvious, Drupal-core related security issues that could be discussed (For example, full read/write/drop permissions are required for the database account) 72.138.37.233 (talk) 06:25, 3 June 2008 (UTC)

If you think that a criticism of Views is dubious, then please reread the Drupal#Content_Construction_Kit_and_Views_modules section. Drupal's essential character depends on the CCK and Views contributed modules, which is why they are tracked for core integration. Both are not considered critical module for Drupal installations for no reason.

Novasource (talk) 12:44, 3 June 2008 (UTC)

Criticisms, Views module, & Security

Okay, rather than get into an edit war, let's discuss what is appropriate for the criticisms section. In particular I have problems with the "best practices" issue that has been going back and forth. First of all, I want to make clear-- I don't have a particular POV in whether or not the Views module should or should not list unpublished nodes by default. For me the three primary issues for inclusion are:

(1) is this a notable criticism?

(2) Because Views is not a part of Drupal core, is this a criticism of Drupal itself?

(3) Is the criticism valid? Is this a legitimate criticism of a security flaw?

Now, even if (3) is not true, it may be useful to mention the criticism and then note something like "the author of Views, however, defends the current practice because X,Y, and Z." to provide a context for the reader.

Regarding (2) -- I tend to think this criticism belongs in an article about the Views module itself. It is at best a little confusing why it would go in the Drupal article. I understand many people use Views (which the article notes), but to go into detail about a criticism on Drupal's default behavior seems a little oblique and suggests a biased POV. Better to spin off into its own article. The criticisms should be about Drupal itself, not problems in spin-off projects. (unless there's something inherent in Drupal that would result in security problems in spinoffs)

Regarding (1) -- I guess i've touched on it a bit. I think if the problem were inherent to Drupal (assuming it is legitimately a problem), it might arguably be notable. But it's scope is the reason I dont' think it belongs.

Let me also address the second criticism about security in general. I think a "Drupal is insecure" section is fair, but I'd expect it to read something like "The developers of Drupal have generally maintained a cavalier attitude towards security. Zillions of bugs have been documented and remain unpatched. The basic architecture has such-and-such a problem" all with refs to support the assertions (or support that other people have made the assertions and let the reader decide). The current sentence that refers to 30 remote exploits does not give any context-- is this a lot of bugs for a project of its size? Do other similar projects have the same number of bugs? Are these bugs considered especially serious? Is the criticism that these bugs remained unpatched or perhaps undiscovered for some length of time? What is Drupal's security policy? In other words, what is the real criticism? Moreover, I am not especially moved with the ref that included 3rd party modules as "drupal bugs". Drupal core, to my knowledge, has had a few remotely exploitable bugs, but they have been patched w/timely releases. A legitimate criticism should argue a flaw in Drupal core's development, security policy, or patching practice... If there is such a criticism, and it is supported with refs, it should certainly go in the article. But what I've seen so far is basically allegation without substance. --Replysixty (talk) 01:17, 3 June 2008 (UTC)

Drupal is a broad project. Views is made by a key Drupal contributor. Views, along with CCK, are universally cited as the key 2 contributed modules. Even this article says so. They are so key that both modules are tracked for integration as a bona fide part of the Drupal system.

This is very significant because 1. a module considered so key to well-running Drupal installs has such a critical security hole and 2. this hole is defended on basis of the author's popularity or unwillingness to fix the problem is significant. It speaks to Drupal's culture, which may be too laissez faire? Well, THAT is POV, which is why that particular assertion isn't present in the main article. But what is mentioned in the article is very significant and documented.

As for whether it is valid to say this is a security flaw, jeez, wake up! Any use of the module exposes confidential data in its default state. If that's not a security flaw, then what is it? A peanut butter and jelly sandwich?

I'm going to play devil's advocate here. First off, "confidential" and "unpublished" are not quite the same thing. Second, if Views is conceived of essentially a Web-friendly UI built over SQL queries, then its behavior is correct-- an SQL query built out of the view would not filter out unpublished nodes unless explicitly instructed to do so. Third, as one who has personally inadvertently exposed unpublished info in a View, when I realized this, I went "Oh, I've been using Views incorrectly. I need to specify that I want unpublished nodes only." And that was it. Actually my first instinct was not "WHAT?!! THIS IS A BUG?!!" it was more like "oh, I'm such an idiot, I forgot to include published only." --Replysixty (talk) 00:30, 5 June 2008 (UTC)

There is a subset/superset relationship: unpublished is analogous to not intended for public distribution which is a subset of all data that is considered confidential.

It is a gross simplification to suggest that breaching confidentiality is OK because a system is "essentially a Web-friendly UI built over SQL queries". How would you feel about "essentially a Web-friendly UI built over SQL queries" the underlying database was your bank information?

To say the least, it's quite odd that the rest of Drupal seems to embrace security by design, but the Views module has such a wide-open security hole.

Novasource (talk) 02:51, 5 June 2008 (UTC)

As for the security flaws, you are invited to counter. But you can't counter with ad ignorance (i.e., we don't know so it's not a flaw).

If you can neutralize the criticism with documented counterargument, then please use that to neutralize it and maybe delete it if invalid. But don't delete the documented criticism just because it doesn't support your own POV toward Drupal's security.

BTW, yes, criticism of Drupal IS POV. It's a point of view contrary to the prevailing attitude of the Drupal management. It is relevant because it has allowed a major hole that runs contrary to well established, universal security concepts.

Further attempts to summarily delete this referenced content will be considered censorship.

Novasource (talk) 03:30, 3 June 2008 (UTC)

It's debatable as to whether this is a security hole or merely a poor default setting. That said, Views is a user-contributed module, and not part of Drupal. Devoting several paragraphs to a user contributed module's default settings is dubious. There are more obvious, Drupal-core related security issues that could be discussed (For example, full read/write/drop permissions are required for the database account) 72.138.37.233 (talk) 06:25, 3 June 2008 (UTC)

If you think that a criticism of Views is dubious, then please reread the Drupal#Content_Construction_Kit_and_Views_modules section. Drupal's essential character depends on the CCK and Views contributed modules, which is why they are tracked for core integration. Both are not considered critical module for Drupal installations for no reason.

Novasource (talk) 12:44, 3 June 2008 (UTC)

Criticisms, Views module, & Security

Okay, rather than get into an edit war, let's discuss what is appropriate for the criticisms section. In particular I have problems with the "best practices" issue that has been going back and forth. First of all, I want to make clear-- I don't have a particular POV in whether or not the Views module should or should not list unpublished nodes by default. For me the three primary issues for inclusion are:

(1) is this a notable criticism?

(2) Because Views is not a part of Drupal core, is this a criticism of Drupal itself?

(3) Is the criticism valid? Is this a legitimate criticism of a security flaw?

Now, even if (3) is not true, it may be useful to mention the criticism and then note something like "the author of Views, however, defends the current practice because X,Y, and Z." to provide a context for the reader.

Regarding (2) -- I tend to think this criticism belongs in an article about the Views module itself. It is at best a little confusing why it would go in the Drupal article. I understand many people use Views (which the article notes), but to go into detail about a criticism on Drupal's default behavior seems a little oblique and suggests a biased POV. Better to spin off into its own article. The criticisms should be about Drupal itself, not problems in spin-off projects. (unless there's something inherent in Drupal that would result in security problems in spinoffs)

Regarding (1) -- I guess i've touched on it a bit. I think if the problem were inherent to Drupal (assuming it is legitimately a problem), it might arguably be notable. But it's scope is the reason I dont' think it belongs.

Let me also address the second criticism about security in general. I think a "Drupal is insecure" section is fair, but I'd expect it to read something like "The developers of Drupal have generally maintained a cavalier attitude towards security. Zillions of bugs have been documented and remain unpatched. The basic architecture has such-and-such a problem" all with refs to support the assertions (or support that other people have made the assertions and let the reader decide). The current sentence that refers to 30 remote exploits does not give any context-- is this a lot of bugs for a project of its size? Do other similar projects have the same number of bugs? Are these bugs considered especially serious? Is the criticism that these bugs remained unpatched or perhaps undiscovered for some length of time? What is Drupal's security policy? In other words, what is the real criticism? Moreover, I am not especially moved with the ref that included 3rd party modules as "drupal bugs". Drupal core, to my knowledge, has had a few remotely exploitable bugs, but they have been patched w/timely releases. A legitimate criticism should argue a flaw in Drupal core's development, security policy, or patching practice... If there is such a criticism, and it is supported with refs, it should certainly go in the article. But what I've seen so far is basically allegation without substance. --Replysixty (talk) 01:17, 3 June 2008 (UTC)

Drupal is a broad project. Views is made by a key Drupal contributor. Views, along with CCK, are universally cited as the key 2 contributed modules. Even this article says so. They are so key that both modules are tracked for integration as a bona fide part of the Drupal system.

This is very significant because 1. a module considered so key to well-running Drupal installs has such a critical security hole and 2. this hole is defended on basis of the author's popularity or unwillingness to fix the problem is significant. It speaks to Drupal's culture, which may be too laissez faire? Well, THAT is POV, which is why that particular assertion isn't present in the main article. But what is mentioned in the article is very significant and documented.

As for whether it is valid to say this is a security flaw, jeez, wake up! Any use of the module exposes confidential data in its default state. If that's not a security flaw, then what is it? A peanut butter and jelly sandwich?

I'm going to play devil's advocate here. First off, "confidential" and "unpublished" are not quite the same thing. Second, if Views is conceived of essentially a Web-friendly UI built over SQL queries, then its behavior is correct-- an SQL query built out of the view would not filter out unpublished nodes unless explicitly instructed to do so. Third, as one who has personally inadvertently exposed unpublished info in a View, when I realized this, I went "Oh, I've been using Views incorrectly. I need to specify that I want unpublished nodes only." And that was it. Actually my first instinct was not "WHAT?!! THIS IS A BUG?!!" it was more like "oh, I'm such an idiot, I forgot to include published only." --Replysixty (talk) 00:30, 5 June 2008 (UTC)

There is a subset/superset relationship: unpublished is analogous to not intended for public distribution which is a subset of all data that is considered confidential.

It is a gross simplification to suggest that breaching confidentiality is OK because a system is "essentially a Web-friendly UI built over SQL queries". How would you feel about "essentially a Web-friendly UI built over SQL queries" the underlying database was your bank information?

To say the least, it's quite odd that the rest of Drupal seems to embrace security by design, but the Views module has such a wide-open security hole.

Novasource (talk) 02:51, 5 June 2008 (UTC)

As for the security flaws, you are invited to counter. But you can't counter with ad ignorance (i.e., we don't know so it's not a flaw).

If you can neutralize the criticism with documented counterargument, then please use that to neutralize it and maybe delete it if invalid. But don't delete the documented criticism just because it doesn't support your own POV toward Drupal's security.

BTW, yes, criticism of Drupal IS POV. It's a point of view contrary to the prevailing attitude of the Drupal management. It is relevant because it has allowed a major hole that runs contrary to well established, universal security concepts.

Further attempts to summarily delete this referenced content will be considered censorship.

Novasource (talk) 03:30, 3 June 2008 (UTC)

It's debatable as to whether this is a security hole or merely a poor default setting. That said, Views is a user-contributed module, and not part of Drupal. Devoting several paragraphs to a user contributed module's default settings is dubious. There are more obvious, Drupal-core related security issues that could be discussed (For example, full read/write/drop permissions are required for the database account) 72.138.37.233 (talk) 06:25, 3 June 2008 (UTC)

If you think that a criticism of Views is dubious, then please reread the Drupal#Content_Construction_Kit_and_Views_modules section. Drupal's essential character depends on the CCK and Views contributed modules, which is why they are tracked for core integration. Both are not considered critical module for Drupal installations for no reason.

Novasource (talk) 12:44, 3 June 2008 (UTC)

Criticisms, Views module, & Security

Okay, rather than get into an edit war, let's discuss what is appropriate for the criticisms section. In particular I have problems with the "best practices" issue that has been going back and forth. First of all, I want to make clear-- I don't have a particular POV in whether or not the Views module should or should not list unpublished nodes by default. For me the three primary issues for inclusion are:

(1) is this a notable criticism?

(2) Because Views is not a part of Drupal core, is this a criticism of Drupal itself?

(3) Is the criticism valid? Is this a legitimate criticism of a security flaw?

Now, even if (3) is not true, it may be useful to mention the criticism and then note something like "the author of Views, however, defends the current practice because X,Y, and Z." to provide a context for the reader.

Regarding (2) -- I tend to think this criticism belongs in an article about the Views module itself. It is at best a little confusing why it would go in the Drupal article. I understand many people use Views (which the article notes), but to go into detail about a criticism on Drupal's default behavior seems a little oblique and suggests a biased POV. Better to spin off into its own article. The criticisms should be about Drupal itself, not problems in spin-off projects. (unless there's something inherent in Drupal that would result in security problems in spinoffs)

Regarding (1) -- I guess i've touched on it a bit. I think if the problem were inherent to Drupal (assuming it is legitimately a problem), it might arguably be notable. But it's scope is the reason I dont' think it belongs.

Let me also address the second criticism about security in general. I think a "Drupal is insecure" section is fair, but I'd expect it to read something like "The developers of Drupal have generally maintained a cavalier attitude towards security. Zillions of bugs have been documented and remain unpatched. The basic architecture has such-and-such a problem" all with refs to support the assertions (or support that other people have made the assertions and let the reader decide). The current sentence that refers to 30 remote exploits does not give any context-- is this a lot of bugs for a project of its size? Do other similar projects have the same number of bugs? Are these bugs considered especially serious? Is the criticism that these bugs remained unpatched or perhaps undiscovered for some length of time? What is Drupal's security policy? In other words, what is the real criticism? Moreover, I am not especially moved with the ref that included 3rd party modules as "drupal bugs". Drupal core, to my knowledge, has had a few remotely exploitable bugs, but they have been patched w/timely releases. A legitimate criticism should argue a flaw in Drupal core's development, security policy, or patching practice... If there is such a criticism, and it is supported with refs, it should certainly go in the article. But what I've seen so far is basically allegation without substance. --Replysixty (talk) 01:17, 3 June 2008 (UTC)

Drupal is a broad project. Views is made by a key Drupal contributor. Views, along with CCK, are universally cited as the key 2 contributed modules. Even this article says so. They are so key that both modules are tracked for integration as a bona fide part of the Drupal system.

This is very significant because 1. a module considered so key to well-running Drupal installs has such a critical security hole and 2. this hole is defended on basis of the author's popularity or unwillingness to fix the problem is significant. It speaks to Drupal's culture, which may be too laissez faire? Well, THAT is POV, which is why that particular assertion isn't present in the main article. But what is mentioned in the article is very significant and documented.

As for whether it is valid to say this is a security flaw, jeez, wake up! Any use of the module exposes confidential data in its default state. If that's not a security flaw, then what is it? A peanut butter and jelly sandwich?

I'm going to play devil's advocate here. First off, "confidential" and "unpublished" are not quite the same thing. Second, if Views is conceived of essentially a Web-friendly UI built over SQL queries, then its behavior is correct-- an SQL query built out of the view would not filter out unpublished nodes unless explicitly instructed to do so. Third, as one who has personally inadvertently exposed unpublished info in a View, when I realized this, I went "Oh, I've been using Views incorrectly. I need to specify that I want unpublished nodes only." And that was it. Actually my first instinct was not "WHAT?!! THIS IS A BUG?!!" it was more like "oh, I'm such an idiot, I forgot to include published only." --Replysixty (talk) 00:30, 5 June 2008 (UTC)

There is a subset/superset relationship: unpublished is analogous to not intended for public distribution which is a subset of all data that is considered confidential.

It is a gross simplification to suggest that breaching confidentiality is OK because a system is "essentially a Web-friendly UI built over SQL queries". How would you feel about "essentially a Web-friendly UI built over SQL queries" the underlying database was your bank information?

To say the least, it's quite odd that the rest of Drupal seems to embrace security by design, but the Views module has such a wide-open security hole.

Novasource (talk) 02:51, 5 June 2008 (UTC)

As for the security flaws, you are invited to counter. But you can't counter with ad ignorance (i.e., we don't know so it's not a flaw).

If you can neutralize the criticism with documented counterargument, then please use that to neutralize it and maybe delete it if invalid. But don't delete the documented criticism just because it doesn't support your own POV toward Drupal's security.

BTW, yes, criticism of Drupal IS POV. It's a point of view contrary to the prevailing attitude of the Drupal management. It is relevant because it has allowed a major hole that runs contrary to well established, universal security concepts.

Further attempts to summarily delete this referenced content will be considered censorship.

Novasource (talk) 03:30, 3 June 2008 (UTC)

It's debatable as to whether this is a security hole or merely a poor default setting. That said, Views is a user-contributed module, and not part of Drupal. Devoting several paragraphs to a user contributed module's default settings is dubious. There are more obvious, Drupal-core related security issues that could be discussed (For example, full read/write/drop permissions are required for the database account) 72.138.37.233 (talk) 06:25, 3 June 2008 (UTC)

If you think that a criticism of Views is dubious, then please reread the Drupal#Content_Construction_Kit_and_Views_modules section. Drupal's essential character depends on the CCK and Views contributed modules, which is why they are tracked for core integration. Both are not considered critical module for Drupal installations for no reason.

Novasource (talk) 12:44, 3 June 2008 (UTC)

Criticisms, Views module, & Security

Okay, rather than get into an edit war, let's discuss what is appropriate for the criticisms section. In particular I have problems with the "best practices" issue that has been going back and forth. First of all, I want to make clear-- I don't have a particular POV in whether or not the Views module should or should not list unpublished nodes by default. For me the three primary issues for inclusion are:

(1) is this a notable criticism?

(2) Because Views is not a part of Drupal core, is this a criticism of Drupal itself?

(3) Is the criticism valid? Is this a legitimate criticism of a security flaw?

Now, even if (3) is not true, it may be useful to mention the criticism and then note something like "the author of Views, however, defends the current practice because X,Y, and Z." to provide a context for the reader.

Regarding (2) -- I tend to think this criticism belongs in an article about the Views module itself. It is at best a little confusing why it would go in the Drupal article. I understand many people use Views (which the article notes), but to go into detail about a criticism on Drupal's default behavior seems a little oblique and suggests a biased POV. Better to spin off into its own article. The criticisms should be about Drupal itself, not problems in spin-off projects. (unless there's something inherent in Drupal that would result in security problems in spinoffs)

Regarding (1) -- I guess i've touched on it a bit. I think if the problem were inherent to Drupal (assuming it is legitimately a problem), it might arguably be notable. But it's scope is the reason I dont' think it belongs.

Let me also address the second criticism about security in general. I think a "Drupal is insecure" section is fair, but I'd expect it to read something like "The developers of Drupal have generally maintained a cavalier attitude towards security. Zillions of bugs have been documented and remain unpatched. The basic architecture has such-and-such a problem" all with refs to support the assertions (or support that other people have made the assertions and let the reader decide). The current sentence that refers to 30 remote exploits does not give any context-- is this a lot of bugs for a project of its size? Do other similar projects have the same number of bugs? Are these bugs considered especially serious? Is the criticism that these bugs remained unpatched or perhaps undiscovered for some length of time? What is Drupal's security policy? In other words, what is the real criticism? Moreover, I am not especially moved with the ref that included 3rd party modules as "drupal bugs". Drupal core, to my knowledge, has had a few remotely exploitable bugs, but they have been patched w/timely releases. A legitimate criticism should argue a flaw in Drupal core's development, security policy, or patching practice... If there is such a criticism, and it is supported with refs, it should certainly go in the article. But what I've seen so far is basically allegation without substance. --Replysixty (talk) 01:17, 3 June 2008 (UTC)

Drupal is a broad project. Views is made by a key Drupal contributor. Views, along with CCK, are universally cited as the key 2 contributed modules. Even this article says so. They are so key that both modules are tracked for integration as a bona fide part of the Drupal system.

This is very significant because 1. a module considered so key to well-running Drupal installs has such a critical security hole and 2. this hole is defended on basis of the author's popularity or unwillingness to fix the problem is significant. It speaks to Drupal's culture, which may be too laissez faire? Well, THAT is POV, which is why that particular assertion isn't present in the main article. But what is mentioned in the article is very significant and documented.

As for whether it is valid to say this is a security flaw, jeez, wake up! Any use of the module exposes confidential data in its default state. If that's not a security flaw, then what is it? A peanut butter and jelly sandwich?

I'm going to play devil's advocate here. First off, "confidential" and "unpublished" are not quite the same thing. Second, if Views is conceived of essentially a Web-friendly UI built over SQL queries, then its behavior is correct-- an SQL query built out of the view would not filter out unpublished nodes unless explicitly instructed to do so. Third, as one who has personally inadvertently exposed unpublished info in a View, when I realized this, I went "Oh, I've been using Views incorrectly. I need to specify that I want unpublished nodes only." And that was it. Actually my first instinct was not "WHAT?!! THIS IS A BUG?!!" it was more like "oh, I'm such an idiot, I forgot to include published only." --Replysixty (talk) 00:30, 5 June 2008 (UTC)

There is a subset/superset relationship: unpublished is analogous to not intended for public distribution which is a subset of all data that is considered confidential.

It is a gross simplification to suggest that breaching confidentiality is OK because a system is "essentially a Web-friendly UI built over SQL queries". How would you feel about "essentially a Web-friendly UI built over SQL queries" the underlying database was your bank information?

To say the least, it's quite odd that the rest of Drupal seems to embrace security by design, but the Views module has such a wide-open security hole.

Novasource (talk) 02:51, 5 June 2008 (UTC)

As for the security flaws, you are invited to counter. But you can't counter with ad ignorance (i.e., we don't know so it's not a flaw).

If you can neutralize the criticism with documented counterargument, then please use that to neutralize it and maybe delete it if invalid. But don't delete the documented criticism just because it doesn't support your own POV toward Drupal's security.

BTW, yes, criticism of Drupal IS POV. It's a point of view contrary to the prevailing attitude of the Drupal management. It is relevant because it has allowed a major hole that runs contrary to well established, universal security concepts.

Further attempts to summarily delete this referenced content will be considered censorship.

Novasource (talk) 03:30, 3 June 2008 (UTC)

It's debatable as to whether this is a security hole or merely a poor default setting. That said, Views is a user-contributed module, and not part of Drupal. Devoting several paragraphs to a user contributed module's default settings is dubious. There are more obvious, Drupal-core related security issues that could be discussed (For example, full read/write/drop permissions are required for the database account) 72.138.37.233 (talk) 06:25, 3 June 2008 (UTC)

If you think that a criticism of Views is dubious, then please reread the Drupal#Content_Construction_Kit_and_Views_modules section. Drupal's essential character depends on the CCK and Views contributed modules, which is why they are tracked for core integration. Both are not considered critical module for Drupal installations for no reason.

Novasource (talk) 12:44, 3 June 2008 (UTC)

Criticisms, Views module, & Security

Okay, rather than get into an edit war, let's discuss what is appropriate for the criticisms section. In particular I have problems with the "best practices" issue that has been going back and forth. First of all, I want to make clear-- I don't have a particular POV in whether or not the Views module should or should not list unpublished nodes by default. For me the three primary issues for inclusion are:

(1) is this a notable criticism?

(2) Because Views is not a part of Drupal core, is this a criticism of Drupal itself?

(3) Is the criticism valid? Is this a legitimate criticism of a security flaw?

Now, even if (3) is not true, it may be useful to mention the criticism and then note something like "the author of Views, however, defends the current practice because X,Y, and Z." to provide a context for the reader.

Regarding (2) -- I tend to think this criticism belongs in an article about the Views module itself. It is at best a little confusing why it would go in the Drupal article. I understand many people use Views (which the article notes), but to go into detail about a criticism on Drupal's default behavior seems a little oblique and suggests a biased POV. Better to spin off into its own article. The criticisms should be about Drupal itself, not problems in spin-off projects. (unless there's something inherent in Drupal that would result in security problems in spinoffs)

Regarding (1) -- I guess i've touched on it a bit. I think if the problem were inherent to Drupal (assuming it is legitimately a problem), it might arguably be notable. But it's scope is the reason I dont' think it belongs.

Let me also address the second criticism about security in general. I think a "Drupal is insecure" section is fair, but I'd expect it to read something like "The developers of Drupal have generally maintained a cavalier attitude towards security. Zillions of bugs have been documented and remain unpatched. The basic architecture has such-and-such a problem" all with refs to support the assertions (or support that other people have made the assertions and let the reader decide). The current sentence that refers to 30 remote exploits does not give any context-- is this a lot of bugs for a project of its size? Do other similar projects have the same number of bugs? Are these bugs considered especially serious? Is the criticism that these bugs remained unpatched or perhaps undiscovered for some length of time? What is Drupal's security policy? In other words, what is the real criticism? Moreover, I am not especially moved with the ref that included 3rd party modules as "drupal bugs". Drupal core, to my knowledge, has had a few remotely exploitable bugs, but they have been patched w/timely releases. A legitimate criticism should argue a flaw in Drupal core's development, security policy, or patching practice... If there is such a criticism, and it is supported with refs, it should certainly go in the article. But what I've seen so far is basically allegation without substance. --Replysixty (talk) 01:17, 3 June 2008 (UTC)

Drupal is a broad project. Views is made by a key Drupal contributor. Views, along with CCK, are universally cited as the key 2 contributed modules. Even this article says so. They are so key that both modules are tracked for integration as a bona fide part of the Drupal system.

This is very significant because 1. a module considered so key to well-running Drupal installs has such a critical security hole and 2. this hole is defended on basis of the author's popularity or unwillingness to fix the problem is significant. It speaks to Drupal's culture, which may be too laissez faire? Well, THAT is POV, which is why that particular assertion isn't present in the main article. But what is mentioned in the article is very significant and documented.

As for whether it is valid to say this is a security flaw, jeez, wake up! Any use of the module exposes confidential data in its default state. If that's not a security flaw, then what is it? A peanut butter and jelly sandwich?

I'm going to play devil's advocate here. First off, "confidential" and "unpublished" are not quite the same thing. Second, if Views is conceived of essentially a Web-friendly UI built over SQL queries, then its behavior is correct-- an SQL query built out of the view would not filter out unpublished nodes unless explicitly instructed to do so. Third, as one who has personally inadvertently exposed unpublished info in a View, when I realized this, I went "Oh, I've been using Views incorrectly. I need to specify that I want unpublished nodes only." And that was it. Actually my first instinct was not "WHAT?!! THIS IS A BUG?!!" it was more like "oh, I'm such an idiot, I forgot to include published only." --Replysixty (talk) 00:30, 5 June 2008 (UTC)

There is a subset/superset relationship: unpublished is analogous to not intended for public distribution which is a subset of all data that is considered confidential.

It is a gross simplification to suggest that breaching confidentiality is OK because a system is "essentially a Web-friendly UI built over SQL queries". How would you feel about "essentially a Web-friendly UI built over SQL queries" the underlying database was your bank information?

To say the least, it's quite odd that the rest of Drupal seems to embrace security by design, but the Views module has such a wide-open security hole.

Novasource (talk) 02:51, 5 June 2008 (UTC)

As for the security flaws, you are invited to counter. But you can't counter with ad ignorance (i.e., we don't know so it's not a flaw).

If you can neutralize the criticism with documented counterargument, then please use that to neutralize it and maybe delete it if invalid. But don't delete the documented criticism just because it doesn't support your own POV toward Drupal's security.

BTW, yes, criticism of Drupal IS POV. It's a point of view contrary to the prevailing attitude of the Drupal management. It is relevant because it has allowed a major hole that runs contrary to well established, universal security concepts.

Further attempts to summarily delete this referenced content will be considered censorship.

Novasource (talk) 03:30, 3 June 2008 (UTC)

It's debatable as to whether this is a security hole or merely a poor default setting. That said, Views is a user-contributed module, and not part of Drupal. Devoting several paragraphs to a user contributed module's default settings is dubious. There are more obvious, Drupal-core related security issues that could be discussed (For example, full read/write/drop permissions are required for the database account) 72.138.37.233 (talk) 06:25, 3 June 2008 (UTC)

If you think that a criticism of Views is dubious, then please reread the Drupal#Content_Construction_Kit_and_Views_modules section. Drupal's essential character depends on the CCK and Views contributed modules, which is why they are tracked for core integration. Both are not considered critical module for Drupal installations for no reason.

Novasource (talk) 12:44, 3 June 2008 (UTC)

Criticisms, Views module, & Security

Okay, rather than get into an edit war, let's discuss what is appropriate for the criticisms section. In particular I have problems with the "best practices" issue that has been going back and forth. First of all, I want to make clear-- I don't have a particular POV in whether or not the Views module should or should not list unpublished nodes by default. For me the three primary issues for inclusion are:

(1) is this a notable criticism?

(2) Because Views is not a part of Drupal core, is this a criticism of Drupal itself?

(3) Is the criticism valid? Is this a legitimate criticism of a security flaw?

Now, even if (3) is not true, it may be useful to mention the criticism and then note something like "the author of Views, however, defends the current practice because X,Y, and Z." to provide a context for the reader.

Regarding (2) -- I tend to think this criticism belongs in an article about the Views module itself. It is at best a little confusing why it would go in the Drupal article. I understand many people use Views (which the article notes), but to go into detail about a criticism on Drupal's default behavior seems a little oblique and suggests a biased POV. Better to spin off into its own article. The criticisms should be about Drupal itself, not problems in spin-off projects. (unless there's something inherent in Drupal that would result in security problems in spinoffs)

Regarding (1) -- I guess i've touched on it a bit. I think if the problem were inherent to Drupal (assuming it is legitimately a problem), it might arguably be notable. But it's scope is the reason I dont' think it belongs.

Let me also address the second criticism about security in general. I think a "Drupal is insecure" section is fair, but I'd expect it to read something like "The developers of Drupal have generally maintained a cavalier attitude towards security. Zillions of bugs have been documented and remain unpatched. The basic architecture has such-and-such a problem" all with refs to support the assertions (or support that other people have made the assertions and let the reader decide). The current sentence that refers to 30 remote exploits does not give any context-- is this a lot of bugs for a project of its size? Do other similar projects have the same number of bugs? Are these bugs considered especially serious? Is the criticism that these bugs remained unpatched or perhaps undiscovered for some length of time? What is Drupal's security policy? In other words, what is the real criticism? Moreover, I am not especially moved with the ref that included 3rd party modules as "drupal bugs". Drupal core, to my knowledge, has had a few remotely exploitable bugs, but they have been patched w/timely releases. A legitimate criticism should argue a flaw in Drupal core's development, security policy, or patching practice... If there is such a criticism, and it is supported with refs, it should certainly go in the article. But what I've seen so far is basically allegation without substance. --Replysixty (talk) 01:17, 3 June 2008 (UTC)

Drupal is a broad project. Views is made by a key Drupal contributor. Views, along with CCK, are universally cited as the key 2 contributed modules. Even this article says so. They are so key that both modules are tracked for integration as a bona fide part of the Drupal system.

This is very significant because 1. a module considered so key to well-running Drupal installs has such a critical security hole and 2. this hole is defended on basis of the author's popularity or unwillingness to fix the problem is significant. It speaks to Drupal's culture, which may be too laissez faire? Well, THAT is POV, which is why that particular assertion isn't present in the main article. But what is mentioned in the article is very significant and documented.

As for whether it is valid to say this is a security flaw, jeez, wake up! Any use of the module exposes confidential data in its default state. If that's not a security flaw, then what is it? A peanut butter and jelly sandwich?

I'm going to play devil's advocate here. First off, "confidential" and "unpublished" are not quite the same thing. Second, if Views is conceived of essentially a Web-friendly UI built over SQL queries, then its behavior is correct-- an SQL query built out of the view would not filter out unpublished nodes unless explicitly instructed to do so. Third, as one who has personally inadvertently exposed unpublished info in a View, when I realized this, I went "Oh, I've been using Views incorrectly. I need to specify that I want unpublished nodes only." And that was it. Actually my first instinct was not "WHAT?!! THIS IS A BUG?!!" it was more like "oh, I'm such an idiot, I forgot to include published only." --Replysixty (talk) 00:30, 5 June 2008 (UTC)

There is a subset/superset relationship: unpublished is analogous to not intended for public distribution which is a subset of all data that is considered confidential.

It is a gross simplification to suggest that breaching confidentiality is OK because a system is "essentially a Web-friendly UI built over SQL queries". How would you feel about "essentially a Web-friendly UI built over SQL queries" the underlying database was your bank information?

To say the least, it's quite odd that the rest of Drupal seems to embrace security by design, but the Views module has such a wide-open security hole.

Novasource (talk) 02:51, 5 June 2008 (UTC)

As for the security flaws, you are invited to counter. But you can't counter with ad ignorance (i.e., we don't know so it's not a flaw).

If you can neutralize the criticism with documented counterargument, then please use that to neutralize it and maybe delete it if invalid. But don't delete the documented criticism just because it doesn't support your own POV toward Drupal's security.

BTW, yes, criticism of Drupal IS POV. It's a point of view contrary to the prevailing attitude of the Drupal management. It is relevant because it has allowed a major hole that runs contrary to well established, universal security concepts.

Further attempts to summarily delete this referenced content will be considered censorship.

Novasource (talk) 03:30, 3 June 2008 (UTC)

It's debatable as to whether this is a security hole or merely a poor default setting. That said, Views is a user-contributed module, and not part of Drupal. Devoting several paragraphs to a user contributed module's default settings is dubious. There are more obvious, Drupal-core related security issues that could be discussed (For example, full read/write/drop permissions are required for the database account) 72.138.37.233 (talk) 06:25, 3 June 2008 (UTC)

If you think that a criticism of Views is dubious, then please reread the Drupal#Content_Construction_Kit_and_Views_modules section. Drupal's essential character depends on the CCK and Views contributed modules, which is why they are tracked for core integration. Both are not considered critical module for Drupal installations for no reason.

Novasource (talk) 12:44, 3 June 2008 (UTC)

Criticism of learning curve

It seems the points raised in the learning curve criticism are mostly valid for the Drupal 4 line and prior. It doesn't make sense to list criticism whose arguments appear to be completely counterbalanced, so I am moving the criticism here:

Learning Curve

Some developers consider Drupal administration to have a significant learning curve compared to other CMS software. In particular, its configuration options and the appearance of a newly installed site are often compared unfavorably to WordPress and Joomla!.

To address these concerns, Drupal 5.0, released January 15, 2007, shipped with a web-based installer, a newly designed visual theme, a reorganized administration panel, and the use of install profiles with pre-configured site content. Drupal 6.0, released in February 2008, improved the installation and administration experience even further.

There may still be valid learning curve criticisms leveled against the relatively vast number of features and configuration required to get a basic site working, but I'll leave that for someone else.

Novasource (talk) 01:43, 4 June 2008 (UTC)

Is White Screen of Death a valid Drupal Criticism?

First off, despite the name, it's not really an error on the level of the "Blue screen of death" which is a total system failure in Windows. It's not akin to a kernel panic or anything. It's more like a syntax error in BASIC or something. It stops the execution of a thread and sometimes as a result the browser is presented with a white screen. That is, unless you tell PHP to print the errors to the browser, which could constitute a security risk, depending on the situation.

Second, this isn't even a Drupal behavior, it's a PHP behavior. I don't see how this qualifies as a criticism of Drupal. How are they supposed to "fix" this problem? In any event, I've run Drupal for years and never experienced Drupal suddenly white-screening.

If this is truly a Drupal error, please explain what it has to do with Drupal in particular, as opposed to the thousands of other PHP programs out there. And also if this is a fair criticism, is it an inherant flaw or can it be corrected? If the former, the article should say so. If the latter, the article might say this as well. --Replysixty (talk) 19:54, 7 June 2008 (UTC)

I've experienced it a few times. Once I was able to explain with a module that had a bad function name. But compared to other products, such as those based on Java or .Net, the likelihood of a totally opaque error seems far greater. I never get completely opaque errors on Java or .Net.

Regardless of the underlying explanation, the WSOD is so opaque that it can easily mean a wild goose chase for administrators. This is significant.

Significant to you is not notable. This is clearly your opinion that it is significant and is not supported by reliable, third-party sources --Replysixty (talk) 21:50, 8 June 2008 (UTC)

Clap, clap, clap. You've figured out some of the internal thinking required to determine significance. I don't know how you would find a reliable, third-party sources to counter the notion that a WSOD that sends users on wild goose chases is not significant. Novasource (talk) 03:22, 9 June 2008 (UTC)

The fact that I get 559 hits to "white screen of death" at drupal.org suggests this isn't trivial.

Drupal's use of PHP means Drupal inherits PHP's weaknesses. This could be solved in a few ways. Two are:

1. Move to a different foundation with better error handling.
2. Put a "shim" that facilitates better error handling between the "public" part of the Drupal codebase and the PHP subsystem.

Until something is done to minimize WSODs, I think this is a valid criticism.

Novasource (talk) 01:40, 8 June 2008 (UTC)

"Valid" criticism belongs in drupal's issue tracker. "Significant" criticisms belong in the issue tracker too. Notable criticism belong in this article. You have cited nothing that suggests this is in any way a notable criticism. I am removing accordingly. If you can demonstrate from reliable third party sources that this is a notable criticism, you've won me over. --Replysixty (talk) 21:44, 8 June 2008 (UTC)

Presence in Drupal's issue tracker has no bearing on factual accuracy of a criticism. Novasource (talk) 03:22, 9 June 2008 (UTC)

Replysixty's edits

I have lost confidence in User:Replysixty's edits.

He's simply restoring old text that is not substantiatable (such as how OOP is not being used in Drupal for backwards compatibility--that was only in a Drupal API document incepted in the days of Drupal 4 and PHP 4), is deleting references, and is wholesale deleting a criticism concerning White Screen of Death apparently because I cannot find independent third party references that a completely opaque error is a significant flaw.

From here on out, I will more freely revert Replysixty's changes if I have any doubt of their veracity.

Novasource (talk) 03:22, 9 June 2008 (UTC)

Waaaaaah. When you provide refs, substantiate, and balance notable criticisms, I will leave your edits alone. When you assert that standard PHP security-minded behavior is a flaw in Drupal, you better substantiate that assertion with a neutral, third-party reference. References, not Google search counts, not your own personal experience, but a real unbiased source. Even your own explanation of when this "bug" occurs relates to non-Drupal core modules. If the scope of your BSOD criticism is to third-party products, I don't think it belongs here. But even if it did, any criticism should provide that context-- the behavior you've experienced has been known to occur when third-party modules are used with Drupal, and this behavior is deemed correct for a PHP error when PHP errors are configured NOT TO APPEAR ON SCREEN.

I have seen a strong tendency on your part to cite your own personal issues and experiences-- arguments on drupal.org, opinions you have on certain modules design, and behavior you've personally experienced with who-knows-what third party modules-- as notable "criticisms". Yes, these are criticisms, they are YOUR criticisms. They are not sufficiently notable just because you think they're problems. That's not to say they aren't problems, or that they aren't notable problems. But your criticisms must be supported with objective, reliable, and independent references. Not original research. --Replysixty (talk) 06:25, 9 June 2008 (UTC)

Stop censoring the WSOD section until we finish discussing it here.'

I already documented that WSOD is a problem with Drupal. The Google search turned it up 559 references (oops, now 590) to that phrase on drupal.org alone. I have experienced it on several occasions. It's significant.

It is valid to criticize how easy it is to create a WSOD under the current Drupal framework.

Casting universal problems as original research is not how you're going to win me over. Please help me understand how hundreds of hits on Drupal.org concerning "white screen of death" is not significant?

And until you do so, stop censoring WSOD content.

By the way, the criticisms have to be factual. Simply arguing that few people experience the problem (which is not the case here) does not counter factual accuracy.

As promised, I have reverted your latest, continued nonconstructive edits.

Novasource (talk) 13:25, 9 June 2008 (UTC)

I am done discussing this with you. From your comments it is very clear you have no interest in reaching consensus, and I will revise as necessary to maintain the encyclopedic standards of this site. Google search counts do not qualify as valid refs, as the links I have provided clearly demonstrate. Anyone can do a search for bug descriptions and count the # of results devoid of any context. "crashing" - 599 hits, "database corruption" - 66 hits, "viruses" - 135 hits, "endless loop" 248 hits. By my google count, Drupal caused "headache"s 783 times. Are you now going to add "headache" as a criticism?

The burden of proof is not on me. It's on you to justify inclusion. And one final thought before I revert your changes. You need to look up "censorship". --16:37, 9 June 2008 (UTC)

You have been warned of vandalism on your talk page. Novasource (talk) 16:46, 9 June 2008 (UTC)

Substantiating my claim of vandalism for ReplySixty

This is why I believe ReplySixty's edits are collectively rising to the level of vandalism. They are generally wholesale elimination of contributed content, including:

• Deletion of referenced content, variously making poorly-based accusations of POV and original research.[1][2][3][4]

"making poorly-based accusations of POV and original research" does not fit the definition of Wikipedia:vandalism. On top of that, my "accusations" are well-founded and correct. You have very clear POV and rely on your personal experience as evidence for notability. This is poor-editing, and I will invite a third party to ascertain for themselves. When this site is called Novasourcepedia, you can be the final decider, but as Wikipedia belongs to everyone, everyone gets to decide. --Replysixty (talk) 04:18, 10 June 2008 (UTC)

• Reverting to prior versions which contained data which was either not referenced or not substantiable.[5][6][7][8]

What "data" is not referenced or substantiated? In fact, what I did here was revert to previous versions which are factually correct and are referenced. You are 100% wrong, and I invite any admin to look for themselves. --Replysixty (talk) 04:18, 10 June 2008 (UTC)

• Removing a reference.[9][10][11]

If you look at these refs, you will notice the links are moved, not removed. --Replysixty (talk) 04:18, 10 June 2008 (UTC)

• Confusing the issue with irrelevant arguments. [12] (aspect oriented programming does not address the flaws Drupal experiences by not implementing OOP)

First of all, the aspect-oriented programming was not written by me. It is not my "argument". Second, Drupal does not "experience" flaws. Third, not implementing true OOP is not a "flaw", and your calling it so is yet another indication of your own POV. You have yet to cite any verifiable, notable third-party sources for your allegation that lack of OOP is a "flaw", nor even that it has the consequences you claim it has. In fact, the one source cited offers a very positive view of Drupal's design with respect to OOP:

"Drupal often gets criticized by newcomers who believe that object-oriented programming (OOP) is always the best way to design software architecture, and since they do not see the word "class" in the Drupal code, it must be inferior to other solutions. In fact, it is true that Drupal does not use many of the OOP features of PHP, but it is a mistake to think that the use of classes is synonymous with object-oriented design."

What *IS* in the article is *your own* unfounded, biased POV. When you can cite a legitimate outside (that means NOT YOU) source of criticism, and convince us it is notable, we're off to the races. --Replysixty (talk) 04:18, 10 June 2008 (UTC)

• Simultaneously reverting edits of two authors, including several cleanup edits that are hardly controversial.[13]

Novasource (talk) 18:13, 9 June 2008 (UTC)

You may have gotten me here. I may have accidentally reverted some minor cleanup someone else did between my good edit and your bad one. My mistake. Don't worry though, on this revert I won't make that mistake. Only your changes will be reverted. --Replysixty (talk) 04:18, 10 June 2008 (UTC)

Novasource, this discussion area is for talking about the article, not for attacking me. I have every right to be bold in my edits, particularly since you are violating numerous Wikipedia guidelines in your constant edit-warring, which itself constitutes Wikipedia:vandalism. I'm sorry you do not agree with my objections, but you certainly do not have any standing for accusing me of vandalism. That said, my objections to your edits remain and your most recent edits are being reverted. If you continue to persist in placing questionable "warnings" on my talk page or otherwise harass me for participating, I will seek administrative intervention. If you insist on edit-warring, I will seek administrative intervention. Disagreeing with your poor judgment is not vandalism. Especially when you are so very flagrantly wrong on these editorial issues. --Replysixty (talk) 04:18, 10 June 2008 (UTC)

Continued vandalism: wholesale, vindictive reversion of content: [14]. Reverted, user warned. Novasource (talk) 13:27, 10 June 2008 (UTC)

To be clear, reverting the vandal ReplySixty added back these improvements:

• Restored referenced "White Screen of Death" criticism, which ReplySixty has unilaterally decided is not worthy of appearing on Drupal due to his own POV. (See above.)

Again, I reject your characterization. What I have done is removed your persistent use of POV and OR. As evidence I cite the same links. Also, it is not worthy of appearing on Wikipedia. --Replysixty (talk) 16:51, 10 June 2008 (UTC)

• Restored correct use of English. Specifically, "defendant" is about a party in litigation. This article is not about litigation.

A defendant is also one who defends. Please refer to see Webster's Dictionary:

"De*fend"ant\, n. 1. One who defends; a defender."

Enjoy --Replysixty (talk) 16:51, 10 June 2008 (UTC)

• Restored cleaned up links created with web reflinks.

Are you referring to the links that *I* cleaned up in this edit? I fully support cleaning up links. This is not what's at issue. What's at issue is that you don't like my edits to your criticism because you disagree with my rationale, and you are falsely trying to allege vandalism. --Replysixty (talk) 16:51, 10 June 2008 (UTC)

• Restoration of discussion of an official Drupal feature request concerning its core to OOP.[15]

Wikipedia is not the place for feature requests. --Replysixty (talk) 16:51, 10 June 2008 (UTC)

• Removed obfuscation, distractions, and weasely language, such as:
  • Discussing AOP in a criticism specifically about OOP. (AOP is not germane to the specific discussion because does not provide OOP features like encapsulation and namespace separation.)

I am through discussing the merits of this. I will not repeat myself over and over. If a third party moderator wants to take a look, great. --Replysixty (talk) 16:51, 10 June 2008 (UTC)

• • "Like most open-source projects..." Just because it's an open source project doesn't excuse security holes, so is not relevant to the criticism.

That's not even a sentence. I *THINK* you're saying that pointing out it's open-source in itself does not "excuse" what you perceive to be a security hole. However, you are misreading the sentence's function. The opening clause provides context for the rest of the sentence, which would otherwise imply that there is something unusual about Drupal development pertaining to this criticism. The sentence also gives context in that the security problem (as you see it) was developed in an open process, not a traditional closed-source dictatorial environment. In other words, you or anyone else is free to fork Drupal into your own version or correct any perceived errors on your own installation. This is notable, given the nature of the criticism, that there is a (supposed) bug that will not be changed by the developers. --Replysixty (talk) 16:51, 10 June 2008 (UTC)

• • How the Views module "so essential to Drupal that it is tracked to be integrated" and other extraneous language, which was fixed by PRRFan[16] but wiped out via vandalism.

This wasn't even something I wrote. --Replysixty (talk) 16:51, 10 June 2008 (UTC)

• A mention that Drupal's API documentation make an erroneous assertion about OOP inheritance.

Don't know what you're even talking about here, but it doesn't sound especially notable in an article about Drupal. --Replysixty (talk) 16:51, 10 June 2008 (UTC)

• Moved mention of Acquia out of Community section. Acquia is a for-profit firm, not a bona fide part of the Drupal community, and should be in its own section to avoid confusion.

Guess what-- a for-profit firm can be part of the Drupal community. That you consider moving this into the correct section as "vandalism" makes your motivation here pretty obvious. --Replysixty (talk) 16:51, 10 June 2008 (UTC)

Novasource (talk) 13:50, 10 June 2008 (UTC)

As I will formally notify you on your page, your false allegations of vandalism solely to defend your POV and reversion of your own edits are inappropriate and improper. They are not in the spirit of collaboration, they violate Wikipedia rules regarding harassment and vandalism. --Replysixty (talk) 16:51, 10 June 2008 (UTC)

(sigh) Mods: if you see this, read Chewbacca defense first. Novasource (talk) 18:11, 10 June 2008 (UTC)

And be sure to check out Wikipedia's policy on vandalism, civility, and harassment. Repeated instances of incivility constitute harassment. Novasource's repeated posting on my talk page does as well. Most important in resolving this dispute, please review Novasources' edits to the Drupal article, responses to criticism in this talk page, and attacks on me, both here and on my user talk page. They speak for themselves. --Replysixty (talk) 02:28, 11 June 2008 (UTC)

More of Replysixty's vandalism

Vandal Replysixty's unconstructive edits (vindictive vandalism) have again been reverted, and another warning has been placed on his talk page. Novasource (talk) 03:32, 11 June 2008 (UTC)

In the process of vandalizing, Replysixty made a couple of constructive edits, and I have added them back. Novasource (talk) 03:36, 11 June 2008 (UTC)

Novasource, are you "vandalizing" the article?

I have added back my changes, which are not in fact vandalism or anything close. Your reversion also removed references and other things that are not even at issue. By your own standards, you are "vandalizing" the page. Let me ask you--are we going to do this forever? Also, I am politely asking you a third time to cool it with my talk page. I have thusfar done my best to avoid confrontation while simultaneously maintaining the integrity of the article, but for a third time, I will point out that unfounded "warnings" on my talk page do constitute harassment. --Replysixty (talk) 03:45, 11 June 2008 (UTC)

I'm taking a break from edits. I've reported you to admins, and I'll let them sort this out. Novasource (talk) 03:47, 11 June 2008 (UTC)

Great. I look forward to their evaluation. --Replysixty (talk) 04:02, 11 June 2008 (UTC)

This article is now protected

It is clear from reviewing the history of this article that there is an ongoing edit war amongst several editors. There is some discussion on this page, but this discussion does not appear to be resolving the dispute. I recommend that editors use the dispute resolution system, which can include mediation or a request for comment from previously uninvolved editors.

The article is protected for five days. If there is consensus to make any edits in the interim, use the {{editprotected}} template to request administrator assistance. I will continue to monitor this article after the protection expires; further edit warring between the parties may lead to blocks of all editors involved in the dispute. Risker (talk) 04:59, 11 June 2008 (UTC)

WSD Crititicism

I have read through all the edits and this page as well. I also believe that Replysixty has a good logical approach to notable content.

In the following example from Replysixty it is easy to see logic that is defensible: Second, this isn't even a Drupal behavior, it's a PHP behavior. I don't see how this qualifies as a criticism of Drupal. How are they supposed to "fix" this problem? In any event, I've run Drupal for years and never experienced Drupal suddenly white-screening.

If this is truly a Drupal error, please explain what it has to do with Drupal in particular, as opposed to the thousands of other PHP programs out there. And also if this is a fair criticism, is it an inherent flaw or can it be corrected? If the former, the article should say so. If the latter, the article might say this as well. --[index.php?title=User:Replysixty&action=edit&redlink=1 Replysixty] (talk) 19:54, 7 June 2008 (UTC)

The emotional experience of Novasource does not qualify as Notable. Stompersly (talk) 23:01, 13 June 2008 (UTC)

CERTIFACTION

bert boerland (board member drupal association) deleted the "drupal certifcation" link in the "see also" section. since 1) there was no wiki page 2) there is no such thing as "drupal certication" —Preceding unsigned comment added by 213.84.158.14 (talk) 09:26, 17 June 2008 (UTC)