Differences

This shows you the differences between two versions of the page.


versiontwentythreecleanupdone [2007/03/02 13:45] (current) – created - external edit 127.0.0.1
Line 1: Line 1:
 +====== squashed bug cemetery ======
 +
 +  * Something is quite wrong with the history configuration bar. I now noticed the second time that trying to change the skin or the language has no effect. A restart solves this. Don't know how to reproduce/provoke the bug yet.
 +
 +    * From Brian: I had this problem too but it seems to have gone away now. I tried changing the skin using the History page but when the page refreshed it still used the old skin. I tried several times but always got the same result. Without restarting POPFile, I moved to another UI page (Admin, I think), tried to change the skin again and it worked first time. Then I checked the other UI pages and the skin changes all worked first time - including the History page. (I used different skins for these tests, instead of just switching back and forth between two skins). Then I shutdown POPFile, restarted it and tried to use the History page to change the skin... and it worked first time.
 +
 +    * From Brian: I can easily reproduce the problem by using adduser.exe to create a new User Data folder with just the 4 default buckets. Alternatively, just rename or delete popfile.db and let POPFile create an empty database. After doing this, the History page will fail to change the skin. The cure involves using one or more of the other UI pages to change the skin, once that has been done  the History page can be used to change the skin.
 +
 +      * How about this for a theory: Changing skin or language will only work when the history page is not accessed via 127.0.0.1/, but via 127.0.0.1/history. The page name needs to be there so it can work?? -- Manni
 +
 +       * From Brian: I've found the same thing, i.e. "/history" makes a difference
 +
 +  * Another oddity is that the 'Number of messages per page' and 'Number of days of history to keep' input fields come back empty when the language or skin is changed.
 +
 +    * I have seen this too. -- Joseph
 +
 +  * I was trying to change skins repeatedly to reproduce the bug above and then noticed that the 'Add history columns' checkboxes were all gone. The form itself, label, apply button and all were still there. Just the checkboxes with their accompanying labels were awol.
 +
 +    * Is this with all skins after changing repeatedly or just certain skins?  On  OSX the background outside Shell is purposely hidden (I think).  Since these new config options are outside Shell they get hidden.  I don't see this as a skin bug, the Config options should be inside Shell.  There obviously should be a seperator between them and the actual useful page content, but not Shell.  Up till now most all page elements between the header and footer were inside shell. -- Joseph
 +
 +    * No, this is not skin-dependent. Once those checkboxes are gone, I can change skins as much as I like, they remain lost.
 +
 +    * From Brian: To get the boxes back, click the tab for another UI page then click on the History page tab - when I do this the add-a-column boxes re-appear.
 +
 +      * Confirmed. -- Manni
 +
 +
 +
 +  * jac: pix.gif, black.gif, and otto.gif should be moved to skins/default directory.  I think black.gif is no longer needed and can be removed.
 +
 +
 +  * Loader.pm has a small bug. When the "POPFile v0.23.0 running" message was restored, the associated "flush STDOUT;" line was left out. This means the Message Capture utility will not show this message (and the preceding "Level 5 html" one) until POPFile is shut down (or if an error message is output). Inserting "flush STDOUT;" in Loader pm 1.32 after line 689 (print "\n\nPOPFile ", $self->{version_string%%__%%}, " Running\n";) fixes this bug.
 +
 +  * The "Show/Hide Configuration Bar" button resets the history to page 1 of the history when it is used instead of leaving the page number unchanged.
 +    * Is this new from my recent changes or was it doing this when Manni first put it in?
 +      * Sorry - I don't know if this is new
 +
 +  * html.pm uses language strings to format the size column that aren't yet in english.pm. Also: because the changed template now uses the multi-purpose variable History_Cell_Value the   entities break because this variable is (correctly) set to escape all html.
 +
 +    * If the 'Size' column is displayed, no data appears in it and the console shows lots of errors (Use of uninitialized value in sprintf at C:\PROGRA~1\PMUTESTS/UI/HTML.pm line 2504). I looked at the 'history' table and found it contains 'size' data. (I'm using a database from 0.22.2 which current CVS upgraded for me) 
 +
 +      * The size column is blank for me too.  I am using a new DB created by the CVS version a few weeks ago.  -- Joseph
 +
 +  * Upon start up, I get warnings about uninitialized values: 
 +<code>Odd number of elements in hash assignment at d:/compiler/ActivePerl/site/lib/Crypt/Random.pm line 107.
 +Use of uninitialized value in division (/) at d:/compiler/ActivePerl/site/lib/Crypt/Random/Provider/rand.pm line 36.</code>
 +
 +  * While running I get a bunch of errors, these are the unique ones.  Most come from trying to view a bucket's detailed view.  It is empty even though there are words in the bucket:
 +
 +<code>Use of uninitialized value in concatenation (.) or string at c:\pf\run/Classifier/Bayes.pm line 1500. (CVS v1.341)
 +Use of uninitialized value in concatenation (.) or string at c:\pf\run/UI/HTML.pm line 1842. (CVS v1.340)
 +Use of uninitialized value in hash element at c:\pf\run/Classifier/Bayes.pm line 1498. (CVS v1.341)
 +
 +Use of uninitialized value in hash element at c:\pf\run/Classifier/Bayes.pm line 1504. (CVS v1.341)
 +Use of uninitialized value in hash element at c:\pf\run/Classifier/Bayes.pm line 3276. (CVS v1.341)
 +Use of uninitialized value in hash element at c:\pf\run/Classifier/Bayes.pm line 3277. (CVS v1.341)
 +Use of uninitialized value in hash element at c:\pf\run/Classifier/Bayes.pm line 3278. (CVS v1.341)
 +Use of uninitialized value in hash element at c:\pf\run/UI/HTML.pm line 1026. (CVS v1.340)
 +Use of uninitialized value in hash element at c:\pf\run/UI/HTML.pm line 1051. (CVS v1.340)
 +Use of uninitialized value in numeric gt (>) at c:\pf\run/UI/HTML.pm line 1851. (CVS v1.340)
 +Use of uninitialized value in numeric gt (>) at c:\pf\run/UI/HTML.pm line 1856. (CVS v1.340)</code>
 +
 +  * Calls to HTML::load_template%%__%%() now need a $page parameter. This isn't given in many places. 
 +    * I'd fix this if I knew how. Seems the crucial place is url_handler%%__%%(). But I just don't know what logic John had in mind. -- Manni
 +
 +  * "Jump to page x" does not check the supplied page number properly - with 20 msgs per page and 79 msgs in my history, entering "5" displays the last page (page 4) as expected but if I enter a larger number (e.g. 10) it uses "?start_message=180" and thus shows an empty page. Repeatedly clicking the "<Previous" link will eventually display msgs 61-79.
 +
 +  * The Javascript code in password-page.thtml doesn't work in any of my browsers. It is supposed to give focus to the username input field (which is a good thing), but I guess we'd need an onLoad event handler for this to work. We'd have to get our hands on the body element, though, which isn't possible changing only password-page.thtml. Should we change common-middle.thtml and set a default onLoad handler there that the other templates might overwrite at will? Is this even possible?
 +
 +    * For me it is working on Firefox, Opera, and IE.  On FF it works all the time (page load and reload).  On IE and Opera it only works on the inital page load (reload doesn't do it).  On older Mozilla (1.7?) based K-Meleon it doesn't work at all (don't know if that is a Moz or KM problem).  Not being able to access the body element is a problem.  I don't really like the idea of a default onLoad handler, but this isn't the only page that uses JS.  The history page has some too, that for some reason seems to work better.  I have done some work on confirm dialogs for certain buttons, such as Remove All, maybe Remove Page, Reset Stats, Reset Bucket.  So it could be useful.  But how this would be implemented I am not sure.  I guess the body tag would just automatically call the default function which could then include other template files with the JS.  But JS normally is in the head of the HTML.  It seems to work outside, but is it proper?  If it should be in the head we are back to the same problem, though from the amount of code I see outside of head I think its ok.  Using onLoad likely would make the focus work all the time in IE and Opera.
 +
 +      * Any idea why this is working for you and not at all for me? Strange. If was thinking about something like <body onLoad="OnLoadHandler">. The default function named OnLoadHandler would simply do nothing. But later on, you should be able to define a second function Foo and simply say OnLoadHandler = Foo and voila. [[http://popfile.manni-heumann.de/test.html| here]] is an example.
 +
 +       * No idea why it doesn't work for you but does for me.  That doesn't make sense.  I am using XP but have also tested on 2000 I think.  Your example looks great.  I didn't know you could do that.  I will get started on moving to that method.
 +
 +    * **Correction**: The javascript works in most of my browsers except Opera. Opera will play along with the onLoad magic described above, though. Don't know what I did when I last tried this. Sorry.
 +
 +    * I just checked in something based on your suggestion.  Apparently we don't need OnLoadHandler = Foo, just define a function with the original name.  If we have trouble with that I will go back to your way, but this one seems to work everywhere I tested (except the K-Meleon based on Moz 1.7 but the renaming method didn't work on KM either).  This should add tons of flexability.
 +
 +      * Works in all my browsers (Mozilla, Firefox, IE, Opera). I think we can soon remove this 'thread' from this page.
 +
 +After getting everything installed I can still not get PF to run:
 +<code>"makerandom" is not exported by the Crypt::Random module
 +<code>"makerandom_itv" is not exported by the Crypt::Random module
 +"makerandom_octet" is not exported by the Crypt::Random module</code>
 +Can't continue after import errors at j:/Perl/site/lib/Crypt/Random/Generator.pm line 12
 +BEGIN failed--compilation aborted at j:/Perl/site/lib/Crypt/Random/Generator.pm line 12.
 +Compilation failed in require at j:/Perl/site/lib/Crypt/Random.pm line 18.
 +BEGIN failed--compilation aborted at j:/Perl/site/lib/Crypt/Random.pm line 18.
 +Compilation failed in require at J:\popfil~1\run/Classifier/Bayes.pm line 44.
 +BEGIN failed--compilation aborted at J:\popfil~1\run/Classifier/Bayes.pm line 44.
 +Compilation failed in require at J:\popfil~1\run/POPFile/Loader.pm line 456.
 +</code>
 +    * This error is connected with the way in which POPFile uses the packing list (in popfile.pl). A temporary fix is to rename (or delete) the popfile.pck file from the main program folder. The BerkeleyDB check appears to cause this problem.
 +      * I saw the posts about that, didn't realize it caused this kind of error.  Nothing in the error seem to be related to BerkleyDB.  That is really odd.  But would explain why I could get this to work on my other computer, it never had BerkleyDB installed.
 +       * Right. It is really odd and it will work when BerkeleyDB is not installed. 
 +
 +  * When operating in single-user mode the UI pages no longer show the "Shutdown POPFile" link
 +
 +  * Current CVS works with Crypt::CBC v2.12 but does not work with the latest version (2.14). With v2.14 POPFile crashes with the following console error message when you try to access the UI: "Cipher stream did not contain IV or salt, and you did not specify these values in new() at C:\PROGRAM FILES\023-TEST/UI/HTTP.pm line 275"
 +
 +  * jac: On Buckets tab with blue skin, first bucket's buttons are larger.  May be a CSS parsing error, I can't see why its doing it.  I didn't notice it on any other skin.
 +    * jac: was a FF CSS parsing error.  Found a work around.
 +
 +  * jac: There may be something wrong with the layout of the bucket page from a screen reader point of view.  I think screen readers would see things pretty much like Lynx does and it doesn't look good on the buckets page.  See the [[http://www.quarter-horse.com/popfile/lynx_history.gif| history]] page and then see the [[http://www.quarter-horse.com/popfile/lynx_buckets.gif| buckets]] page in these screenshots from Lynx.
 +    * mh: that's bad. Seems like the complete table is falling apart. Maybe because the rows don't fit on one screen row?
 +    * jac: I checked, even a giant window that allows all the headers to show in line doesn't solve it.  I don't see anything wrong with the HTML, the only thing I can think of is buttons have built in line breaks in Lynx.
 +      * jac: Major rework of Buckets page should have solved this.
 +
 +  * jac: The "Changed to %%__%%_" message does not colspan properly when the first message on the page is reclassified, that one gets //colspan=""// [[http://www.quarter-horse.com/popfile/rowerror.jpg| Example]]
 +    * Apparently this does not only occour on the first row?  I was going through my history and got to a page where a message had been reclassified but never displayed due to a search or filter.  That one was also missing its colspan.
 +
 +  * jac: The menu link to the Magnets page always ends with //&amp;start_magnet=0//, it was this way in 0.21 also.  Is there any reason for it?
 +
 +  * jgc: This isn't exactly a new problem, but I only noticed it now: If we send a 404 error, we only send the error code, but not a 404 page. It might be that we don't really need one (if the UI works without errors), but should we have one?
 +
 +  * jgc: POPFile should use 995 as the default POP3 SSL port (instead of using 110). To make a POPFile-enabled account use SSL it should only be necessary to append ':ssl' instead of having to also insert ':995' between the server and userlogin
 +
 +  * jgc: msgdir, piddir and logdir now created at startup
 +
 +  * jgc: When using the history page to change the language, the date format in the footer is not updated when the page is automatically refreshed (but the rest of the page shows the new date format in the 'Arrived' and 'Date' columns and their tooltips). A manual refresh is required to get the footer to use the correct date format (the browser's 'refresh' button or the history page's 'refresh' link or selecting a different UI page)
 +
 +  * jgc: I expected every user would see the special unclassified bucket but non-admin users do not see this special bucket. When I tried to create a bucket called 'unclassified' for a non-admin user POPFile created an ordinary bucket called 'unclassified'.
 +
 +  * jgc: PF dies if you hit Edit user on the blank option.
 +
 +  * Template Strict problems in UI/HTML.pm
 +    * Buckets page (corpus_page) doesn't have an Apply button anymore so need to remove $row_data{Localize_Apply} (line 2318 in v1.359)
 +    * Since Common_Middle_Tab3 is no longer used (Configuration tab) and HTML.pm numbers the pages in a loop (apparently for determining the current tab), PF dies because we don't use tab 3 anymore.  We need to renumber the tabs or change how we deal with them.
 +
 +  * jgc: If you enter a login with incorrect password it goes back to PW entry page.  Then enter the correct password and you end up stuck at a blank page http://localhost:8080/password .  Part of the problem seems to be the password page is just totally blank when logged in, it should redirect to history just in case a user gets there somehow.  In this case the other problem is that the password page directs you to the intended URL when you login, since the incorrect login takes you to /password that is now the destination you go to when finally logged in.
 +
 +  * jgc: POPFile 0.22.2 ships with a minimal Perl based upon ActivePerl 5.8.4 but this is no longer compatible with the optional SSL components in the University of Winnipeg repository (they require a newer version of Perl). ActivePerl 5.8.7 Build 813 was released 7 June 2005.
 +
 +  * jgc: Single user mode (POPFile Classic) toggle should be on Administration page, when not turned on there is no need for the extra Users tab.
 +    * John disagrees, but I think it is a waste to have an almost empty page that is not needed in single user mode.  It also increases the likelyhood that someone will press it just to see what it does.  The amount of tabs the Single user and Admin sees is pretty large, on smaller screens with large fonts the menu tabs can take up the entire width of the screen or more. -- Joe
 +
 +  * When there are no magnets we shouldn't have the Update and Remove buttons on the Magnets config.  In fact, we don't need the section that lists current magents at all if there aren't any, we could just start the page with the Create New Magnet section.  We should also replace the two buttons with our new Apply Changes button to make the interface consistant with Buckets page.
 +    * This should be possible without a single line of Perl. A &lt;TMPL_IF NAME="Magnet_Loop_Magnets"&gt; should do the job.
 +
 +  * Add RTL language variable for template if statement to use additional rtl.css
  
 
Old revisions

Should you find anything in the documentation that is incomplete, unclear, outdated or just plain wrong, please let us know and leave a note in the Documentation Forum.

Recent changes RSS feed Donate Driven by DokuWiki
The content of this wiki is protected by the GNU Fee Documentation License