TypeError: Cannot call method 'isDirectory' of null #792
Comments
We need to catch this error somehow. As it seems this error is suppressed due its location, let’s make it way more prevalent so we can get this resolved.
- v6.63.7 February 21, 2014 - Fixed IE9 and below not understanding the charset we send - Thanks to [Eric Vantillard](https://github.com/evantill) for [issue #801](#801) - Better debugging for invalid watch states - For more information see [issue #792](#792) - Fixed DocPad failing to serve files after the initial generation once the docpad configuration file has been modified - Thanks to [Michael Williams](https://github.com/ahdinosaur) for [issue #811](#811) - Updated dependencies
|
I recently received the following error: I'm not certain that this is the same error balupton describes above, but it instructed me to post at issues/792, which is interesting. This was triggered by changing a file in /src/layouts from default.html.teacup to default.html.eco. Stopping and starting docpad rendered the file correctly without error. |
|
It was the same problem on my system (KDE linux). I realized that some editors automatically backup file after edited file is modified, not saved yet, just changed in editor, i.e. Kwrite. That event is saving recent changes to backup file, which event triggers watcher. Seems to be the DocPad does not "understand" what happend, throw out this error, and stops file re/generation in out/ directory. Perhaps backup default behavior of used editor should be reconfigured, or try to use other one. I use vim, and no more such error. |
|
No issues with Brackets, SublimeText 2/3 either. Sometimes auto-refresh gets crazy though. At HackPrinceton we were trying to get a Freebase tutorial running inside DocPad and the auto-refresh kept generating the page in a loop even after if was deleted and removed from dev-dependencies. |
|
Not sure if this is true, but it seems this happens for deletions. It's a watchr issue. We just need someone to look into it. |
|
I ran into this while docpad was running and I tried to change default.html.eco to default.html.md.eco |
|
Hi there, I am getting this when having docpad running and removing a source file of the web site that docpad is watching (in my case through "hg rm ..."). Since I had difficulties with regenerating files on my Mac, I am using "watchOptions: preferredMethods: ['watchFile','watch']" as recommended elsewhere. Cheers, |
|
First time using docpad, but incase it can help. |
|
Thank you @victorhaggqvist. :) /cc @balupton |
|
I got this error when adding roughly 20 files each with their set of images (5-10). The message before the error in question says: It then lists files that failed to render. Eventually it says how many were generated: As you can see, not all files have been generated. I decided to see if I could avoid DocPad errors by deleting some of my content for this section of the site—I needed to do that anyway. I deleted a file and got the error specified and directions to come here. So, I'm guessing the error happened in my case because the file is waiting to be rendered, cannot be rendered, and is then deleted. It seems as though DocPad cannot handle a large amount of files, be it rendering from markdown or copying over from the static directory. I am migrating some content from a PHP-based content management system over to DocPad and I have about 20 child pages each with sets of images. Is this too much for DocPad to handle? Content is being rendered with the markdown plugin, and images are copied into the static directory. Some of the markdown files have HTML in it but from what I understand, markdown can handle that. Also, I do not see any parsing errors like I have before, so I don't think the problem is in the markdown parsing (though I could be mistaken). Another related issue—I also got caught in an infinite loop during the watching of the images directory, i.e. the I'm running DocPad v6.69.1 and my plugins include I'm not sure if this is the best place to specify the infinite loop and lack of being able to generate all files with a large amount of images and a few plugins installed, but it could all be related somehow. |
|
If you have large amount of files use raw plugin and put them in src/raw
|
|
What @dimitarkolev said. :) |
|
Thanks for your quick responses! Using the raw plugin helped with that issue and the rendering is much faster, but it breaks the functionality I had going on with the thumbnails plugin to generate thumbnails. That plugin can no longer find the images, even after specifying the path. Is this an issue with the thumbnails plugin? Is there another way to have it ignore directories in static for the render/indexing passes without having to change the path? Has anyone used the two plugins together? Perhaps it's unrelated to this issue. If so, I would love to carry on the conversation elsewhere. |
|
Unfortunately you are right about the thumbnails plugin. We had to write May be I had to create thumbnails-raw plugin, please advise?
|
|
As a workaround you can add the following to docpad.coffee What it does is that it marks all files in /src/files/hub folder as ignored which will speed up docpad indexing but thumbmails plugin will keep working. As you can see we recreate the directory structure in hub folder in the /out because otherwise thumbnails plugin will fail when generating thumnails. |
|
Do you have an example project with this code, @dimitarkolev? It doesn't appear to work. When running |
|
Did you npm install mkdirp ?
|
|
I did and tried it again and it works. Thanks! |
|
Getting the error below when I delete "about.html.md" in /render my specs: This doesn't actually crash the site - DocPad continues to run w/o any problems, but it still would be great to have a fix for this. |
|
This should be fixed from watchr v2.4.12 December 17, 2014 and above. Closing unless someone reports it again. |
Just checked mixpanel after a few months, and noticed that this error has been getting incurred THOUSANDS of times a day by people... Ever since watchr v2.4.7 December 19, 2013.
Now we could just do a undefined check and skip that section of code, but the problem that particular line:
Should always work, as at least one of those stats should be defined. This need to be looked into.
Want to back this issue? Place a bounty on it! We accept bounties via Bountysource.
The text was updated successfully, but these errors were encountered: