ready for 3.4? about myphotoshare HOT 20 OPEN

Todo list

• Update documentation, particularly the screen captures gallery, as this version has a new look.
• More extensive test. I have to index many more pictures in my gallery (i.e. create album.ini files).
• Bug when scanner updates existing cache and content has changed. Seems to be old indexes in the cache and new pictures. Or problem with browser cache?
• When a search has no results, it displays "No results". When the user click to come back to the root album, the error message is not cleared from screen.
• One cannot browse the search results. As soon a picture is selected in a search result and displayed, moving to another picture is done in the album and not in the search results. Is it the intent behaviour?
• Adapt Debian/Ubuntu package generation for version 3.4.
  • Check no more file moves.
  • Test it on Debian server.
  • Create GitHub project...

3.4 will be a great version! Nice job with the search feature

from myphotoshare.

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

from myphotoshare.

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:

1. Do a search on a word with results. Result thumbnails are displayed.
2. Search now on an nonexistent word, like a stopword or "ufophejk". No Results is diplayed.
3. Click on the root album name link, on top left. Root albums are displayed. But in my case, as I have only 1 root album and no thumbnails, I still see the No Result from previous search...
   

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.

1. Delete all cache files to start clean.
2. Drop one album and run scanner. The browser displays the album. All is good...
3. Add another album and run scanner. Do a refresh of the browser page ([F5]) and only the previous album is shown.
4. Open browser developer tools ([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...

from myphotoshare.

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

from myphotoshare.

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.

from myphotoshare.

search isn't working thoroughly yet

from myphotoshare.

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.

from myphotoshare.

now should be ok

from myphotoshare.

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

from myphotoshare.

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.

from myphotoshare.

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.

from myphotoshare.

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.

from myphotoshare.

The second time I run the scanner, I did not have the bug

The json_version variable in options.py works this way:

• the scanner embeds it in all json files
• if the embedded 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...

from myphotoshare.

Perhaps we should limit to lowercase values understood by JavaScript, Python and PHP

ok!

from myphotoshare.

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?

from myphotoshare.

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...

from myphotoshare.

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.

from myphotoshare.

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

from myphotoshare.

I've found the reasons:

1. A bad (default) Apache configuration on my PC. It was using 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.
2. Because of the 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.

from myphotoshare.

:-)

from myphotoshare.