My page was deleted

Go to admin/content/node

It may provide some help

moving

After allot of digging I found your answer...
Sorry, but this page was on Drupall.org not Drupal.org
The page was not on this site or deleted by us!

Woops Fixed

Google shows http://drupal.org/node/39822 in search results when searched with http://drupal.org/node/39822

Incidentally I tried http://www.drupall.org/ but this is not existing, only cgi-bin.

I'm sorry, but you wont get an answer you dont already have. I marked this as "Fixed" because I wanted to give others the last chance to review it. However I have looked into the issue and have found nothing. The original post you referenced was a site on drupall.org, and was archived there. I have now spent 2 hours searching for your page.

I have searched the Internet Archive and found nothing
I have looked almost everywhere for your document.

It seems that your document was about finding and fixing WSOD? I would assume that it wasnt delete, but that it was included into the WSOD main document. Sometimes when documents are rolled into each other the original gets deleted. In may make for a valid arguement that this process be changed to an edit of the original document and a reference to the changed document. We never really delete anything, though we will combine documents or archive them. Your document was not archived. I would assume your Ideas were evaluated and added to the WSOD main document.

The only thing I do know that is deleted regular is SPAM. I dont think your document was Spam, I assume it was deleted.

Now I would love to help you on THIS issue, but I have exhausted all options. In fact the only document I have found that really references your document is

http://code.google.com/p/drupal-dtools/wiki/MostCommonWSODs

I know your frustration, and I would hate to see you leave.. but someone messed up and your document got deleted. I would take your time and read related material. I would assume you will find your contribution put to good use in another document. In may have even been re-written.

I will contact a Document admin about the status of this ticket. If we leave it active it will fall down to the bottom of the queue and years later after about 100+ people have read it, some poor person will mark it as fixed or wont fix.

There are thousands if not tens of thousands of people working on the site and on various documents in one state or another. I wish I could point you in a better direction but the simple answer to your problem is that I don't know. I once thought someone deleted my revision and I was pissed! So I can understand your feelings. I must mark your ticket as fixed, which will give the community 2 weeks to see the problem, and maybe find out what happened to it. After 2 weeks with no response, it will be marked as fixed.

Now for a better solution to the issue... I will open up a ticket to change the document procedure. I will also ask you to please look at the http://drupal.org/node/158043 and see if it has the ideas that you addressed.

Then look around at other handbook pages, and see if you can find the topics you addressed in them.

Then I will go the extra length and present you with a very good opportunity. If you want, we can work on your ideas jump onto IRC #drupal-docs channel. I am on there most days and am willing to help! We will quickly get a team together and I will attempt to work with you on a mini-docsprint.

Mike

P.S. I followed up with a monster admin about this issue and unfortunately the node simply does not exist. He (chx) checked everywhere!

Marked Fixed :( *cry*

No I am not an admin, though I am talking to many admins. We are taking this very serous. The status "won't fix" will not show up in the issue queue. In fact its more, cant fix.

Can you provide me with the page in your track log that has the link to the article?

I am currently attempting to get the log checked for you... I am going to move this over to the webmasters queue since I think we over at the Docteam have basically exhausted all avenues. The problem is that even if we find out who is responsible for deleting it that there is no current information on what your post contained. I do not know the procedure for deleting nodes. I would assume nodes would be marked as Unpublished and not deleted.

I would assume your content was valid since it is referenced here http://code.google.com/p/drupal-dtools/wiki/MostCommonWSODs but we do not even know who published that code.

Lets see if the webmasters can come up with any last conclusions! I will continue to track this issue.

I had Killes check the logs, but reasonably, the logs do not go back that far (they go back 2 days). Trust me I know first hand how frustrating documentation is. Unfortunately you have fallen in the cracks.

But in defense of the people who do work on the doc team, we have to face ridiculous people and conditions. I am so frustrated by it that I am going to take a break from it.

I am happy I could close this ticket. I am sorry that I could not provide you with any other information. I would file a ticket with the docteam that requests no document be deleted, but instead all documents be marked as not-published.

kenorb, please contribute to Drupal documentation. I have never ever seen a webmaster deleting anything for the reasons you listed. As we do not know what was there I can't say what happened. Writing doucmentation on another site is practically lost. But, sure.

kenorb
I cant agree more with chx. I will work hard to get more people to contribute. I have spent over 4 hours research this issue and talking to a number of people (including chx) to try and get the answer. We take this seriously. I don't know what suitable outcome will be for this, but I am thinking of how the process failed and how we can make it work.

A good possibility is that your document was cut and pasted into another document. This left your document without any meet. Instead of simply moving it to archive (preserving the revisions) someone MAY have deleted it. This would be a reasonable situation in which someone could easily overlook the repercussions. If this situation happens to me, I will know to reference the child documents/document that the parent document spawned before moving it to archive.

I can assure you, that my Docteam mentor Add1sun refuses to delete ANYTHING! When I first started to do Documenting I wanted allot of things deleted, but she stuck her ground and eventually I saw why. I am rather frustrated myself with the process. Sometimes it wears on us, and we got to walk away, put our heads back on, and then come back. Being in the Docteam is a thankless job. At the same time, we need it so much. No one wants to write, including me, and so things and features go unused, unnoticed, and eventually forgotten.

Lastly I will work to come up with a set of procedures for Admin activities in Drupal's Docteam. I think deleting documents and references after changing pages are good ideas. However in the end most people have access to most documents. They can edit them without reading any guidelines. I would rather have this open system fail, then have a closed system that doesn't work.

I don't know what was on the page, but it seems to me that most of what you wrote is covered in http://drupal.org/node/158043 and http://drupal.org/node/201875. Is that right?

I deleted this page on purpose a while back (at least 2-3 months, we can probably find that in the log if we want to). This page was about the exact same subject already extensively treated by http://drupal.org/node/158043, and was linking offsite to the google code page of your module (http://code.google.com/p/drupal-dtools). If I remember correctly the content was nothing more then what's today on http://code.google.com/p/drupal-dtools/wiki/MostCommonWSODs

I considered that spam at this time, and would probably also do today, if faced with similar content. I understand that you were not happy at this time because your CVS application had been refused (see history on http://drupal.org/node/375629), but this page was nothing more then self promotion.

Oh wow, I have used dtools... I didnt know Kenobi wrote it. Its a GNU project located on this site http://drupal.org/project/dtools. I would find it hard to self promote a module that is licensed under the GNU, that is on this site, and that has actually saved my butt.

I use that tool for the times things go bad. Documentation on modules is allowed in the handbook under contributed modules. I find it a bit ironic that documentation dealing with a module would be deleted and not moved to this section. If there was an issue of self promotion I would of helped fix the document. I would also make a argument that his module should be mentioned in the WSOD as a possible tool to help solve these problems.

This all makes me want to stop contributing.

@MGParisi: I don't see any reason not to mention dtools on http://drupal.org/node/158043. At the time we are talking about this module was not hosted on d.o and his author added the page mentioned in this post for the sole purpose to make a link to his website.

Kenorb wrote D-Tools, a fact I just came aware of. Damien, from what it sounds like, all you had to do was talk to kenorb about hosting his module on D.O. and he would of. Im sorry, but I have spent over 5 hours on this issue, researching every link that I have found. I did not even notice that he wrote D-Tools, and how effective it has been for me in some cases. Add that with the fact that the the document had to deal with WSOD, and how difficult it is to get information on what is causing the WSOD, and you have a situation where we should be begging for more tools to help solve the problem.

If I enter incorrect code in a block, or enable a block with a wrong setting. I get a WSOD. Currently, I have a dev site that I had to abandon, and recreate on another instillation, because for some reason, the same block setup on user does not work on user/login...

There is no tools out there to help manage the block database scheme if something goes wrong. I think we need people like Kenorb to work on these tools, and definately not delete there documents without giving them a notification to change its content.

@kenorb: fell free to improve http://drupal.org/node/158043 if you feel that it is needed. You have the right to do so, as does every other user on drupal.org.

first, relax.
All those existing troubleshooting symptoms are listed there because they were a problem for someone at one point or another. I'm sure there are plenty of threads where one or more of the listed problems was solved by reading that checklist! Calling everyones advice there "useless" is just rude and wrong. If you know the problem in hindsight, maybe it was easy. If you don't know the cause, at least that list is a place to start looking.

Your list, while not wrong, is a bunch of much rarer possible cases, and not 'simpler' at all, but actually more complicated, and arising from cases where you have done something in the code that is damaging to the site. Perhaps it could be added as an extra page - "Did these common troubleshooting steps not help? Try some of these advanced debugging issues!"

The list you provided seems to be one that will only occur for developers writing code, checking out unstables or moving internals about, not users just trying to run Drupal on stable releases.
It looks like it could be summarized as :

Possible reasons for a WSOD:
- You wrote some bad code
- You wrote some bad code
- You wrote some bad code
- You put a backup in the wrong place
- You wrote some bad code
- You messed up a site transfer
- You messed up a site transfer

Now... I think we could invent a few hundred more examples of "bad code" that would cause a WSOD if you tried. My favorite one is naming a theme the same as a module!
If you want to document your own mistakes for others to learn from, that's a really good thing. Providing hints on how to debug would be a useful document, but the truth is that the most common causes of WSOD are those listed in the main page you call "useless" and that page provides accurate information for many many users.
You don't need to so bitterly criticize it just to make your own contribution look not-so-bad.

The developers who are writing code are probably already aware that they put an exit() into their code for debugging. Writing advice that "if you put die() or exit() in your code and the site stops working, then take it out" is what I would call close to useless.

About deleting pages:

Part of editing a useful knowledge base is being able to remove redundant information, not just piling more on. It is inevitable that occasionally some pages can and should be deleted. It doesn't have to be personal, it's about making the docs better. Learn how ego-less programming and editing can work.
Sometimes less documentation is better. That may mean deleting other content. You already claim that one page is better than ten. In this case maybe one page (node) is better than two.

The Drupal docs have, and should continue to have the freedom to delete appropriate pages as required. The docs are a wiki, and it is counter-productive to believe that pages should never be deleted.

.dan.

You linked to an active issue in an unstable dev version. Code problems, debug stuff and unsupported dependencies do sometimes exist in unstable dev versions.
If a developer gets a WSOD by checking out HEAD ... then the steps they need to go through are a bit different from the steps that everyone using recommended releases gets.
Step #1 would be look at the thing they just installed or modified - not 200 others that were working fine before. But you'd know that, right?

Good start on the page anyway. You do want to start that page by explaining these debugging steps are for active coders only, because diving straight into SQL in the first paragraph is a bit scary for most readers of the handbook.

Suggestion 2b is helpful.

I actually would like to see an easier, WSOD "cookbook", though I would never use it. Ultimately WSOD can always be contributed to bad code, everything can be. We do need more tools for dummies. For example the current WSOD tells the user to uninstall modules. For me, I go into phpmyadmin and see tid and know thats a term id, the normal user does not. Also disabling blocks is another area.