Gallery 3.0 RC2 Feedback

Ranger187, new node http://gallery.menalto.com/node/97456

Bharat: http://gallery.menalto.com/node/97219#comment-351109 <---- Is there a way we can put an option where a user can SPECIFY a smtp server? By default G2 won't send email on a windows box unless I specify a server. I know this is a windows issues because even VBulletin needs me to specify a smtp.

So, for \modules\notification\helpers\notification.php or whatever is making the call, can you make an update that would allow us to specify a smtp and also send a test email like we could on G2?

I'm guessing G3 uses function calls for this? I'm not a coder. ;)

UPDATE: http://codex.gallery2.org/Gallery3:Installation_on_Windows_Server_2008_and_IIS7 now has more accurate info. You can install with the current info. After the "Testing PHP" has still to be updated but it will get Windows Server 2008 users up and running.

Not sure if I should still be posting in the RC2 feedback thread or starting a new thread but…

I'm writing clients against the REST API. My question is whether the `start' and `num' parameters are implemented as described in http://codex.gallery2.org/Gallery3:API:REST .

I ask because I seem to always get all the members returned for an album, regardless of what I pass as start and num. Furthermore, looking at modules/gallery/helpers/item_rest.php, I don't see anything passing those parameters into the $orm. But perhaps they are magically pulled from the environment somewhere else.

Here's a short, abridged, and cleaned-up example:

GET http://localhost/gallery3/index.php/rest/item/1?start=700&num=100

HTTP/1.1 200 OK
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Connection: close
Date: Thu, 19 Aug 2010 18:54:03 GMT
Pragma: no-cache
Server: Apache/2.2.14 (Unix) mod_ssl/2.2.14 OpenSSL/0.9.8l DAV/2 PHP/5.3.1
Content-Type: application/json
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Client-Date: Thu, 19 Aug 2010 18:54:03 GMT
Client-Peer: 127.0.0.1:80
Client-Response-Num: 1
Client-Transfer-Encoding: chunked
Set-Cookie: g3sid=a66ff9ca43f25040fbb98396c35ef9a6; expires=Thu, 26-Aug-2010 18:54:03 GMT; path=/; HttpOnly
Set-Cookie: g3sid=2d95506a02235e2249d1308cb5eec3853d18a077%7Ea66ff9ca43f25040fbb98396c35ef9a6; expires=Thu, 26-Aug-2010 18:54:03 GMT; path=/; httponly
X-Gallery-API-Version: 3.0
X-Powered-By: PHP/5.3.1

{

"entity": {
"id":"1", ... },
"members": [
"http://localhost/gallery3/index.php/rest/item/2",
"http://localhost/gallery3/index.php/rest/item/3",
...
"http://localhost/gallery3/index.php/rest/item/134",
"http://localhost/gallery3/index.php/rest/item/135"]
}

Whether or not it's implemented, I don't mind if getting everything is the default. It just wasn't clear to me from the API description whether handling more than 100 members *required* that one process in 100-member chunks (and of course I want to handle large collections properly).

Thanks,
George

So the wiki page Gallery3:About (sorry I can't post links yet) links to a feature list spreadsheet and in that spreadsheet one feature listed is "Amazon S3 support"... so I was wondering, did that get implemented? If so, how would I go about configuring it? If it requires setting up s3fs or something like that I'm able to.

Ⓑ® bromide      

Thanks! I created the ticket.
Ⓑ˳® bromide      
⎵                    

I just wanted to mention that I've installed Gallery3 RC2 and done a little testing and the installation itself appears to have gone perfectly.

One little hiccup I had post-installation was an error that occurred when I changed the encryption seed and the cookie salt. I made sure to log out before I did this but when I first refreshed the page I got a PHP error of some sort. When I navigated to another page everything worked again, though, so no more harm than a moment of confusion.
Ⓑ˳® bromide      
⎵                      

Here's how you can debug it. Create a file in modules/gallery/controllers called "x.php" and put this in it:

class x_Controller extends Controller {
  public function test() {
    print access::htaccess_works() ? "yes" : "no";
  }
}

Then browse to http://your.site/gallery3/index.php/x and you should see "no" appear. This means that it thinks that htaccess doesn't work. Then go and edit modules/gallery/helpers/access.php and look for this code:

   685    /**                                                                                                        
   686     * Verify that our htaccess based permission system actually works.  Create a temporary                    
   687     * directory containing an .htaccess file that uses mod_rewrite to redirect /verify to                     
   688     * /success.  Then request that url.  If we retrieve it successfully, then our redirects are               
   689     * working and our permission system works.                                                                
   690     */                                                                                                        
   691    static function htaccess_works() {                                                                         
   692      $success_url = url::file("var/security_test/success");                                                   
   693                                                                                                               
   694      @mkdir(VARPATH . "security_test");                                                                       
   695      try {                                                                                                    
   696        if ($fp = @fopen(VARPATH . "security_test/.htaccess", "w+")) {                                         
   697          fwrite($fp, "RewriteEngine On\n");                                                                   
   698          fwrite($fp, "RewriteRule verify $success_url [L]\n");                                                
   699          fclose($fp);                                                                                         
   700        }                                                                                                      
   701                                                                                                               
   702        if ($fp = @fopen(VARPATH . "security_test/success", "w+")) {                                           
   703          fwrite($fp, "success");                                                                              
   704          fclose($fp);                                                                                         
   705        }                                                                                                      
   706                                                                                                               
   707        list ($response) = remote::do_request(url::abs_file("var/security_test/verify"));                      
   708        $works = $response == "HTTP/1.1 200 OK";                                                               
   709      } catch (Exception $e) {                                                                                 
   710        @dir::unlink(VARPATH . "security_test");                                                               
   711        throw $e;                                                                                              
   712      }                                                                                                        
   713      @dir::unlink(VARPATH . "security_test");                                                                 
   714                                                                                                               
   715      return $works;                                                                                           
   716    }                                                                                                          

The first thing I'd do is to comment out those "dir::unlink" calls on line 710 and 713. Then when you run the test script, it'll leave around gallery3/var/security_test and we can examine it. Then open http://your.site/gallery3/var/security_test/verify in your browser. What do you get back? If you get the word "success" then the .htaccess system is working and we have a bug of some kind (or your config is too weird for us to handle). Make sure that the var/security_test dir gets created! It should have two files in it, one marked .htaccess with something like this in it:

RewriteEngine On
RewriteRule verify /gallery3/var/security_test/success [L]

And a file called "success" with the word "success" in it.
---
Problems? Check gallery3/var/logs
bugs/feature req's | upgrade to the latest code | use git

PHP 5.2.4 by the way, and Ubuntu 8.04 and MySQL 5.051
Ⓑ˳® bromide      
⎵                      

Hi, and thanks for (another) wonderful product. I'm a long-time user of Gallery 2, and I've just started playing with Gallery 3. I love the design -- very clean -- and I look forward to the final release. A few minor quibbles:

1) Missing (as yet) is the ability for new users to request a login.

2) I tried to install on a system that was missing a few necessary modules. The code that was supposed to explain the problems didn't work. The problem was at line 35 of installer/cli.php:
$errors = installer::check_environment();
if ($errors) {
oops(implode("errors", "\n")); <-- Problem here
}

3) If you click the Login link in the upper-right corner and get the login dialog, the "Forgot Password?" link doesn't work.

None of these are show-stoppers, though I can't use this for my family photo album till family users can get their logins.

Take care, and thanks again.

Hi, after some disappointment with RC1 (I broke it in one day) I decided to give another shot to RC2. It seems to me mores table that RC1 - three days and still working . However I have problem with different thumbnail sizes, specially greater than 200. If I set thumbnail for 230, it creates quite big rectangle around photo with a lot of empty space. With widths less than 200, the rectangle is OK.

My second problem is direct photo upload. I'm often transferring tons of photos between gallery servers. For menalto gallery I need something, like direct photo upload. My idea is to create empty album xxx, put the photos into var/albums/xxx and just press something in the maintenance page (ideally from script) to create resizes and etc. In this case server add function is not the right solution, because of photo copying.

Thanks for answers.

Petr

1) Yes, thanks. I discovered that just after posting, much to my chagrin.

2) It was actually a PHP syntax error:

> PHP Warning: implode(): Invalid arguments passed in /xxxxx/gallery3/installer/cli.php on line 30
> Oops! Something went wrong during the installation:
>

I suspect you intended something like
> oops(implode("\n", $errors));
instead of
> oops(implode("errors", "\n"));
but that's just a guess.

3) It seems to be working now. Perhaps it was only a problem before I had added users and picutres. Or perhaps adding the registration module fixed it....

A side note: the <? shortcut is required by Gallery3, but it is deprecated... From the php.ini files;

; It's been recommended for several years that you not use the short tag "short cut" and
; instead to use the full <?php and ?> tag combination. With the wide spread use
; of XML and use of these tags by other languages, the server can become easily
; confused and end up parsing the wrong code in the wrong context.

Is there a way to allow the creator of an album to edit the album, but nobody else (at least, not without explicit permission)? At the moment, the only way I can think of is to create a group for each relevant user.

Another minor quibble: As I edit the tags in a photo, suggestions appear in a drop-down box. I can type faster than the suggestions come up, so if I enter several tags in a row and hit enter, whatever suggestion is currently displayed replaces the last tag that I typed.

Upon further playing around, I believe that the technique described in my previous message is the only way to produce the problem. I'm guessing that the fact that the problem can resume after I move the cursor out of the picture and then back into it is a consequence of two things:
1) I tend to move the cursor to the middle of the picture, which is right about where the Options menu line ends up, and
2) The JavaScript (Java?) has some memory, so it knows that it still "owes" us a menu-redisplay when we return to the photo. If top of the menu hits the cursor, the loop will simply start over again.

Moving the cursor near the top of the photo will allow the loop to unwind and eventually terminate.

Side note..... Can we make a "Windows" area (forums)so I don't have to sort through threds.....I'm up for whatever but time is limited and I'm not reading 40,000 posts to find it's a windows issue.

Thanks bro.....Appreciate it....

@pbearne: upgrade to the latest experimental code and try the import again. If that fails, please start a new topic and we'll figure it out.
---
Problems? Check gallery3/var/logs
bugs/feature req's | upgrade to the latest code | use git

Hello!

I just installed g3 rc2 on my embedded linux box.
With g2 and g1 I always had 500 errors due to some random php-fcgi bug, but g3 installed straight away!
I did however removed the check on the mysql version since mysql 5 is not cross compilable I'm forced to use mysql 4. To my surprise I didn't run into any problems because of this.

My system:
Operating system: Linux 2.6.22.19
Apache: Unknown (I use lighttpd)
PHP: 5.2.14
MySQL: 4.1.22

I use the php mysqli plugin (if that makes any difference)

Anyway, everything runs fine, it immediately detected imagemagick, just great

melker,
please start a new thread with your issues after getting the latest experimental code. Post you log files as well in the new thread.

Dave
_____________________________________________
Blog & G2 || floridave - Gallery Team

@RAETO: To start, please get the latest experimental version, some or all of these issues may be fixed (see my signature for upgrade info). Also check your gallery3/var/logs for relevant log snippets on errors:

1) The G3 import does not write to the G2 install at all. I don't see how it can cause damage, and I've seen no other reports of damage. Please provide us with more info so that we can track this down.
2) I don't know what you mean by "Rotating does not redirect back to the picture". Rotating how, where?
3) What's in your logs?
4) Not all functionality in G2 is in G3 yet. But there are tons of unofficial modules, and one of them might do what you want. http://codex.gallery2.org/Category:Gallery_3:Modules
5) Don't know why you say that about usability. G3 usability is worlds ahead of G2.
6) See #4
7/8) source control is optimized for developers, not users. why do you care?
9) sorry that you don't like dashboards
10) gallery 2 has several layers of caching to get it to the same performance level that G3 has out of the box. Those caching layers cause instability and varied problems (I bet you that the caching layer is what caused your G2 to go south after you tried the import). If you turn off G2 caching, you'll find G3 to be substantially faster. We may or may not implement caching in G3.

---
Problems? Check gallery3/var/logs
bugs/feature req's | upgrade to the latest code | use git

This bug is fixed in the latest code.
---
Problems? Check gallery3/var/logs
bugs/feature req's | upgrade to the latest code | use git

I'm impressed with Gallery 3!

Yesterday I managed to import near 2000 photos from our Gallery 2 page, it took like 2 hours but everything went good hopefully. I have some suggestions/questions:

1) The "edit permissions" window is too small. I was using Gallery 2 along with SMF and we had many groups of users, so in my case I have to scroll the bottom horizontal bar in the window to see all groups and make changes, etc.

2) In the admin dashboard we can see a Welcome Message. It would be nice if we can set a Welcome messages for our users, too.

3) How can we import several files at the same time?

4) Where can I define what file formats/file sizes our users can upload?

5) Does people get e-mail notifications of new comments in the picture where they commented?

6) It will be possible to modify the menu by default? At the moment there's only a "Tab" button and it would be great to be able to add other tabs from the administration, for example to our forum, to a contact page, to an external link, etc.

7) The main page shows as page <title> "Browse Album :: [the title of my main album]". Why it does not catch the Header Text I defined in the dashboard instead?

Thank you!

Can the module contactowner please incoporate the recaptcha?? Thanks!!!

Otherwise nice job so far - the watermark module works nicer than before - automatic apply - but the settings could be extended to decide on which they are applied ;)

Cool would also be to add personal sidbar boxes and menu entries to link to some static content

Cheers
Raj

i added all the modules from the github - hmm will browse them again - cheers

Is there anything to change the name of the images quicker or even during upload?

Yes it is gone. There was way too much confusion on how it worked. People tried to add tags durring the upload process and after as well.
We might bring back a better UI in the future. Try:
http://codex.gallery2.org/Gallery3:Modules:batchtag

Dave
_____________________________________________
Blog & G2 || floridave - Gallery Team