VoodooPad remains stuck at "Reading the document for the first time, this may take a while" window
Hi
I have recently updated to the new version of VoodooPad, but I encountered the following issues:
When I tried to open the old documents, the window "Reading the document for the first time, this may take a while" and the program remained stuck at it. I went to "Force Quit" Window and checked the program was "not responding", and so I simply forced it to quit. Then, I tried to reopen the document again, and this time it did open inmediately... but I saw that many pages where lacking, the HOME page was the default VoodooPad Welcoming Home Page, and not the Index I had created on that document.
I fear that, because I forced the program to quit, the updating of all pages was not completed, and therefore, only some of them are showing. But on the other hand, it seemed the program was stuck at the "Reading document for the first time" window. I mean, it was maybe one hour or so stuck at it, and on "Force Quit Applications" Window on my Mac it appeared as "not responding" app.
I am not sure if this is the only problem though: I have recently installed the File Stream service from Google, which loads documents from the cloud. I don't know if the document was fully downloaded when I forced it to quit, though I think this was not an issue, as heavier documents take less time to download.
Anyway, I'd like to know if there is a chance to open the document at its full extent, with all the pages. Fortunatelly, I have a recent backup of it, made with the previous version of VoodooPad; but I don't know if it is normal that takes so long to open...
Thank you
Pablo
Keyboard shortcuts
Generic
| ? | Show this help |
|---|---|
| ESC | Blurs the current field |
Comment Form
| r | Focus the comment reply box |
|---|---|
| ^ + ↩ | Submit the comment |
You can use Command ⌘ instead of Control ^ on Mac
1 Posted by Colin on 05 Feb, 2018 05:56 PM
Hi,
Thanks for reaching out to us about this, and I'm sorry for any trouble this may have caused. This is certainly unexpected behaviour, and I'd like to take a closer look at why this may have happened.
Could you let me know what device and version of macOS you're using? In addition, would you be able to attach the document that you were loading when this issue occurred (or any part of the document that also runs into this issue) so that we can narrow down what might have caused this to happen?
Also, to ensure that you can open your document without experiencing this issue again, you can find a copy of VoodooPad 5.1.6 here.
All the best,
Colin
Primate Labs Inc.
2 Posted by Pablo Culebras on 05 Feb, 2018 06:20 PM
Hi Colin
Thanks for your response. I have already solved the problem deleting the
uncompleted file and substitued it from a backup copy. This time I waited
longer, and finally the document did open with no issues. It took quite a
lot though, but I must say it is a quite large file of 227 MB.
I am using MacOS High Sierra 10.12.6
Thanks for your help
Pablo
3 Posted by Colin on 06 Feb, 2018 04:51 PM
Hi,
Thanks for the additional details. I'm glad that you were able to open your document successfully, and I'll see if we can improve the document loading process to avoid this kind of situation following future updates.
All the best,
Colin
Primate Labs Inc.
4 Posted by Pablo Culebras on 13 Feb, 2018 12:59 PM
Hi Colin
I am encountering some issues with VoodooPad when trying to make an HTML
export
When I try to move the folder with the html files inside Google Drive, I
get the following message:
<<You can't copy the item (...) because it's name is too long or includes
characters that are invalid on the destination volume>> (please, check
attached Screenshot_1). I think the same happens when trying to upload it
to a web server.
Now, it is true that I have some pages with very long names: I used the
method of transforming long sentences (some times entire paragraphs of 2 or
three lines) into links, and these paragraphs or sentences included non
English characters (I write on Spanish and Portuguese, with "ñ", " ´ " "^"
and "¡ ¿" signs, besides hyphens, spaces and puntuation marks (; , . ? !).
I though it was not an issue with VoodooPad, since those links work on the
desktop app.
I send you a copy from the VoodooPad console that appeared once I finished
exporting using the WebApp Template.
Besides, I have found some problems when using the WebApp template, since
some links on the pages list seem not to work properly once opened in html.
In other cases they don't work either when clicked from within another html
page (apart from the page list). I found many pages lead to a 404 error
when uploaded to the web.
Finally, the other day I had an issue when trying to export a wiki using
this template. I had a home page called "Index", and when trying to access
it from within the wiki on html, the *Index* links (as I said, I had
renamed the home page that way) and the "Home" button worked. The worse is
that it gave problems from them on on that wiki when I opened its
corresponding vpdoc on the desktop app. When trying to access the *Index *page
(Home page) it appeared a grey screen with a message <<VoodooPad can not
display this item. You may save it to your disk if you like>> (please, see
attached ScreenShot_2), so that I had to substitute that desktop wiki for a
document I had (fortunatelly) saved previously to an external drive.
Please, tell me which would be the best practices to have my wiki online as
ah html file.. should I avoid renaming the Home page? should I avoid using
non English characters on page titles? neither page aliases can have that
kind of characters? or the think to avoid are the punctuation marks? or
simply make them shorter? if the latter is the case, I'd like to know which
is the length limit on page titles.
Thank you,
Pablo
5 Posted by Pablo Culebras on 13 Feb, 2018 01:08 PM
I'd like to add to my previous email, that I have just made another test
uploading my wiki (the one that thas has long title names). I uploaded a
zip file from my cPanel File Manager to my public_html folder. Afterwards I
extracted the files inside that public_html on my server. Then I checked my
wiki online, and found that many pages are giving a 404 error. Those pages
do exist on my local drive html wiki; and they work locally. I send you a
link to this test online so that you can check it yourself:
http://www.paulsnakes.com/dm-wki-prueba-2/
Thanks
Pablo
6 Posted by Colin on 13 Feb, 2018 03:27 PM
Hi,
Thanks for letting us know about this, and I'm sorry to hear that you're running into these issues. I'm not certain how to avoid some of the problems you've encountered based on this information, but I'd like to ask a few questions so that I can investigate further.
For Google Drive, it looks like you might be encountering the maximum file name length for macOS files, which I believe is about 255 characters.
I'd like to take a closer look at the broken links that you're seeing after exporting your document to HTML. Could you let me know what type of page you are using for your website (e.g. are all the pages Rich Text, or are some of the pages with links Markdown) and what type of Web Export format you're using (e.g. RTFD to HTML, Markdown)? To confirm, are these links functional when you just open the HTML files in your browser locally?
For the "VoodooPad cannot display this item", could you let me know where you were opening the document from? For example, was it in a folder on your device that you've opened documents successfully from before, or was it on an external device or shared folder (e.g. a folder synced with Dropbox)? Did you immediately load your backup of the file, or try to save the file with the button provided?
All the best,
Colin
Primate Labs Inc.
7 Posted by Pablo Culebras on 14 Feb, 2018 12:25 PM
Hi Colin
*-For Google Drive, it looks like you might be encountering the maximum
file name length for macOS files, which I believe is about 255 characters.*
As I comment below, I think title length is in fact an issue. It was not
the problem on that link I got the message for (ScreenShot_1.png that I
sent yesterday): that title is 239 characters. Instead, the problem there,
I think, was the use of "" signs. I give more information about that below.
-*I'd like to take a closer look at the broken links that you're seeing
after exporting your document to HTML. Could you let me know what type of
page you are using for your website (e.g. are all the pages Rich Text, or
are some of the pages with links Markdown) and what type of Web Export
format you're using (e.g. RTFD to HTML, Markdown)? To confirm, are these
links functional when you just open the HTML files in your browser locally?*
Sorry, but I don't know exactly what means markdown links... I simply
create the pages from the default editor; with several text formats (18
pts, 12 pts, Bold, changing fonts and text colours). As for links, I have
both internal links to other pages of the wiki and links to external URL's.
Both kind of links where created from the default text editor, using the
shortcut Command-L to transform text into links.
I think I've used RTFD to HTML Web Export option on every wiki (the option
set by default)
*-For the "VoodooPad cannot display this item", could you let me know where
you were opening the document from? For example, was it in a folder on your
device that you've opened documents successfully from before, or was it on
an external device or shared folder (e.g. a folder synced with Dropbox)?
Did you immediately load your backup of the file, or try to save the file
with the button provided?*
This problem happened with another wiki, a different vpdoc to which I refer
on all other parts of this email. This other vpdoc is shorter and it
doesn't have pages with long titles. I opened it from Google Drive. I think
maybe it was a problem caused during the export or related to syncing
issues. I have Google File Stream installed, so anything I put on that
folder goes automatically to the cloud, it is not stored locally. I tried
to reproduce the problem making a new export to a local folder on my Mac
using the WebApp template. This time the VoodooPad app crashed while
exporting. I tried it again and again closed down unexpectedly, but before
appeared a window "VoodooPad console" with a text that I send you attached
to this email. I then tried to make an export without using any template (I
am speaking of RTFD to HTML Web Exports, in every case) and this time the
process succesfully concluded, and the wiki seems to work well as long as I
have checked (as I said, on this wiki there are no pages with titles longer
than 255 characters). I had done the html export to my documents folder;
and afterwards I copied the folder with the html files to a Google Drive
folder. I didn't find any problem in doing so. I then opened the index.html
page of that wiki from within Google Drive on my system and I could
navigate the wiki normally, including pages with "" and non English
characters, which instead give me problems on online wikis, as I comment
below.
*PERFORMANCE TESTS RESULTS COMPARING VERSIONS OF THE SAME HTML WIKI WITH
WEBAPP TEMPLATE vs NO TEMPLATE; LOCAL -vs- ONLINE*
I have made more tests with two versions of the same wiki: one exported
using the WebApp template and the other with no template at all. I found
different performances among them. I found also different performances
between those wikis when stored on my local drive (Documents folder of my
Mac, that is, out of Google Drive folder structure) and when uploaded to my
server (www.paulsnakes.com). Among the latter, I found differences between
the wiki exported using WebApp template (that you can check yourself on
http://www.paulsnakes.com/dm_18_02_10) and the wiki exported without the
use of any template (http://www.paulsnakes.com/dm-wki-prueba-2)
I could isolate some characteristics that seem problematic on any or all of
these versions of the wiki:
*Local wikis:*
Links with “” doesn’t work on WebApp template html wiki, but they do work
on html wiki made with no template
Links longer than 255 doesn’t work either in WebApp template html wiki and
no template html wiki.
*Online wikis:*
Links with any non English character (á, é, í, ó, ú, ñ…) doesn’t work on
any online wiki (give a 404 error page).
Interestingly, links with “” (but with no non-English characters) do work
on server wiki made with no template but the don’t on the online wiki made
with WebApp template (give a 404 error page)
Links with @ work on online wiki made with WebApp template, but links with
# don’t (I didn’t test them on the online wiki made with no template, since
I don’t have the pages list on that and couldn’t find this kind of pages).
They return a 404 error page.
Link 801 - 808: Alfonso II es obligado a retirarse al monasterio de Ablaña,
ante la presión de un grupo nobiliario. Recupera el trono gracias al noble
Teudano, y a partir de entonces empieza una importante reorganización del
reino, vinculándose a la herencia visigoda para reforzar el poder real
gives a 403 error, instead of a 404.
When trying to copy any of the two versions of my wiki to Google Drive
folder structure, I get the error I sent you yesterday on ScreenShot_1.png;
pointing that there is an item with a name that is too long or that
includes characters invalid on the destination volume. The wiki copying
process concludes with only some 300 pages out of +3000 copied.
Those wikis work perfectly on their vpdoc native version.
Thank you,
Pablo
8 Posted by Colin on 14 Feb, 2018 10:53 PM
Hi Pablo,
Thank you so much for the detailed response! I'm taking a look at several of the issues you've noticed now.
There is currently an issue that prevents many non-English characters from being web-exported correctly when RTFD to HTML is specified as the export format, which seems to be affecting some of your links. Depending on the other content on your pages, you may have more success with the Markdown export format for web-exporting your document. We're currently investigating this problem and aim to resolve it in a future VoodooPad update.
It also seems that pages with names longer than 250 characters are not being exported, regardless of the page type or export format specified. We're also investigating this issue to see if we can resolve it soon. In the mean time, I can only recommend that you use page names that are 250 characters or shorter.
Regarding the performance differences, could you provide a bit more detail on the kinds of differences you're seeing between the different versions?
I'm taking a closer look at the issues you've encountered with # and "" characters, and the difficulty you have had with copying your files to Google Drive, and I'll get back to you on these issues as soon as I can. If anything I've noted above doesn't match your experiences, please let me know.
All the best,
Colin
Primate Labs Inc.
9 Posted by Colin on 16 Feb, 2018 10:14 PM
Hi,
Thanks for your patience. It looks like links with # or "" are not converted correctly to the automatically-generated index page when exporting to HTML, whether or not the WebApp template is used. You noted that links with # don't seem to work with the WebApp template -- could you let me know if that is only on the automatically-generated index page (typically called _page_index.html), or in other instances of that link?
All the best,
Colin
Primate Labs Inc.
10 Posted by Pablo Culebras on 14 May, 2018 06:56 AM
Hi Colin
I have been bussy with other tasks these months, and now I am coming back
to look for a setup that will allow me to transform my VoodooPad documents
into a full operating html wiki.
You asked me in your last response
<<You noted that links with # don't seem to work with the WebApp template
-- could you let me know if that is only on the automatically-generated
index page (typically called _page_index.html), or in other instances of
that link?>>
I have checked it and can confirm you that links with # and " " doesn't
work at the automatically-generated index page but they *DO work* from
other html pages out of the automatically-generated index page. Instead,
long titled pages are not exported, and when links to them are clicked from
either automatically-generated index or other pages out of it, I get a
"File not found" message. Links with << >> work normally at the
automatically-generated
index page
I could also check that long titled pages are simply not exported (they get
a message "file not found" both from automatically-generated index and from
other pages), probably due to the macOS limit to 250 characters on file
titles, as you had pointed out.
It seems that pages with non English characters, as ¿ á é í ó ú ñ ... do
work normally, fortunately.
I take the opportunity to point out that would be great if a search box
wiki-wide could be included in the html export templates
regards,
Pablo
11 Posted by Colin on 15 May, 2018 06:13 PM
Hi Pablo,
Thanks for following up with me. I'll pass this information along to my team and see if we can resolve this in a future update. Adding a search field to the WebApp template is a neat idea, and I'll pass this along to my team as well to see if we can implement it.
All the best,
Colin
Primate Labs Inc.
12 Posted by Pablo Culebras on 23 Nov, 2018 10:50 PM
Hi Colin,
I write you again about VoodooPad, which I am using heavily now and I am
happy with.
The point is that I am planning to make a super-wiki with it... you know,
it could have thousands of pages... I have excluded images from the
beginning, but each page can have 2-3 alias in average (it's multilingual)
and so I wonder which is the recommended size limit for a VoodooPad
document... both in terms of total amount of pages, links / alias and total
weight of content... so I wanted to ask you about it.
My intention is to load it to a web host in order to have the content
reachable from anywhere even with a smartphone.
Thank you very much
Pablo
13 Posted by Pablo Culebras on 24 Jun, 2021 10:35 AM
Hi Colin. I have been following Voodoopad forums looking forward for the
release of VP6. Now things seem a bit stuck.. is VP development still going
on? I depend critically on this nice software in my workflow, and would
like to know the software is still alive.
Thank you,
Pablo