Open paolobenve opened 6 years ago
album.ini
files).3.4 will be a great version! Nice job with the search feature
The no-result bug I think it is ok.
The search results can be browsed.
The version marker in json files (it has been there for various months) should prevent indexes messes. A different json version ensures that the json files are correctly generated. Obviously in this phase of developing/testing many changes occur and we must manually change the json version number every time a change occurr or some bug is corrected, I do so and things work. For the user, we must ensure that after the release no change to the indexes happen, or, if a change happen, a new json version is set.
The web server has cache times, they are in .htaccess files, and they sum up with the browser cache times
I confirm that browsing search results is solved.
That is not the case for the "No Results". Here are the steps I do to reproduce it:
I did a few more tests and I think that the problem with scanner updates lies around browser cache. I can reproduce it at will with the following procedure.
cache
files to start clean.[F5]
) and only the previous album is shown.[F12]
) and under network option, disable cache. Refresh again the page ([F5]
), now both folders are shown.
This behaviour occurs in Chromium and FireFox.I won't be able to work on these bugs these coming days as I won't have access to a computer...
That is not the case for the "No Results". Here are the steps I do to reproduce it:
seems ok now.
I did a few more tests and I think that the problem with scanner updates lies around browser cache. I can reproduce it at will with the following procedure.
I think it's an issue related to web server cache, expiration times are in .htaccess file
Tag 3.4beta2 does not include https://github.com/paolobenve/myphotoshare/blob/master/scanner/Geonames.py#L46 and following 2 files that prevents the scanner from running in the Debian package. These 3 lines of code allows the scanner to load the GeoNames files from the module directory and not the script directory.
search isn't working thoroughly yet
Can you give examples of search failing to work? I haven't conducted extensive tests but the results I get in French are correct with my gallery.
now should be ok
Tag 3.4beta2 does not include https://github.com/paolobenve/myphotoshare/blob/master/scanner/Geonames.py#L46 and following 2 files that prevents the scanner from running in the Debian package. These 3 lines of code allows the scanner to load the GeoNames files from the module directory and not the script directory.
try with beta4
I don't know if there are differences between v3.4beta4 and master, but scanner from master crashes presently in
File "/home/pierre/Development/myphotoshare/scanner/PhotoAlbum.py", line 1769, in default
return obj.to_dict()
File "/home/pierre/Development/myphotoshare/scanner/PhotoAlbum.py", line 1752, in to_dict
media["words"] = self.words
AttributeError: 'Media' object has no attribute 'words'
I don't have the time presently to correct it now.
I think it happens when json_version
is not 0, i.e. when the json files have been generated with the same json_version
but they are different. I've added a control, but I'm quite sure it solves the crash, but the problem is transferred to javascript.
Now the scanner tries to earn machine time, and so json files are re-generated only if strictly needed, but I'm thinking on regenerating them all the times, perhaps the scanner execution time increases when the albums tree has no change, but we are more sure that everything is fine.
The second time I run the scanner, I did not have the bug. But I saw that the scanner deleted obsolete indexes for search terms. That's strange because the content has not changed for quite some time. I'll do more precise test later...
I've seen that you wrote in myphotoshare.conf.default
:
# This file is imported through the ConfigParser standard module
# boolean values:
# 1 = yes = YES = true = True = TRUE;
# 0 = no = NO = false = False = FALSE;
Unfortunately, I remember I had bugs with the PHP JSON parser used in index.php
because it is unable to manage the boolean values when they have uppercase letters. Perhaps we should limit to lowercase values understood by JavaScript, Python and PHP.
I have concerns about the size of the generated .json
files. I get files larger than 100 KB for a two albums test gallery. Perhaps we can optimize them when working on version 3.5.
The second time I run the scanner, I did not have the bug
The json_version
variable in options.py
works this way:
json_version
is different from the options.py
one, json files are treated as invalid, if the value is the same, they are considered valid, unless some other condition makes them such.Perhaps it's better to change it continuously in development phase...
Perhaps we should limit to lowercase values understood by JavaScript, Python and PHP
ok!
That is not the case for the "No Results". Here are the steps I do to reproduce it:
seems ok now.
I don't think it's solved; I still have the problem even when using master branch. I don't understand why it happens. It could be incompatibility between jQuery versions as I'm using the system one on my PC instead of the version provided by MyPhotoShare. Is it possible to force the error messages to hidden when the user makes an action, as a first step?
The no result message is faded out, it cannot persist on screen.
Are you sure you are not using the minimized and perhaps you do not run the minimize script?
Anyway the browser has a cache too...
That's the reason why I say I can't understand how it happens. Because the result is quite visible... I can browse the gallery and do other actions, the message stays over the pictures.
every time the parseHash
function in 010-libphotofloat.js is called, $(".search-failed").hide();
at line 155 is executed, which should hide the no result message.
Please check that execution passes from there putting a breakpoint at that line
I've found the reasons:
index.html
instead of index.php
. I've added markers in the files to differentiate them to help those who'll drop in that bug. Apache was not reading .htaccess
file.index.html
file, it was using the minified JavaScript and CSS and I forgot to regenerate them when I updated them from master
.I've updated the documentation to explain how to configure Apache and use the .htaccess
file.
:-)
Are we ready?