New Client: Gallery 3 Publish Service for Lightroom 3
|
3.14159
Joined: 2010-03-25
Posts: 64 |
Posted: Sun, 2010-09-05 03:33
|
|
Hi! I've written a Lightroom 3.0+ plugin for Gallery 3 integration both via publish service and export. Most of the functionality is there and it works for me, use it at your own risk. If you do find any bugs or quirks, please tell me so I can try and fix them. [img]http://misc.nesciens.net/files/screenshot1.png[/img] For further information and a download link, please look here. You can either use the comment form there or this forum thread for feedback. So long |
|
Posts: 7994
Outstanding.. great work!
---
Problems? Check gallery3/var/logs
bugs/feature req's | upgrade to the latest code | use git
Posts: 64
...
Posts: 28
Hey Pi,
Really nice of you to put this together. Looking forward to giving it a whirl.
When I load the plugin, I get the following error:
Plug-in error log for plug-in at: /Volumes/data/d2/software/mac/plugins/lightroom3/G3_publish_service_20100905/G3PublishService.lrplugin
**** Error 1
An error occurred while attempting to load this plug-in.
The plug-in description script (Info.lua) is missing.
The status in Plug-in Manager is listed as 'Installed but not working'.
Any thoughts?
OS: MacOS 10.6.4
LR: 3.2
-Avery
Posts: 64
Ok, just tried on a Mac, i can reproduce that. i'll look into it, thanks for the info!
Pi
Update: It should work now; I can't check against LR 3.2, but it does work for LR 3.0 on Leopard now. I've updated the file attachment in the initial posting.
Posts: 28
Well, after I uploaded the new plugin (removed prior version and rebooted LR first), I received the status "Installed but not working". I rebooted LR, and the plugin was then listed as disabled. After enabling, it works.
Anyhow, I was able to upload to my dev site, just fine (only basic testing thus far). That's just awesome. Great work, and thanks! I'd buy you a beer if you were local. Now, I just need a G3-WordPress3 SSO solution that works!
One question about auth (since I really don't know how G3 3rd party auth works)... if you indicate an httpS url (I don't have SSL configured on my dev env yet), does it pass the credentials over SSL? Also, with the auth key, does it pass the credentials again, or does it exclusively rely on a paired key to authenticate my workstation for future requests (and only pass the password when retrieving the initial key)?
Thanks!
Avery
Posts: 64
Haha, thanks anyway. Good to hear it works for you now. As to the authentication, as far as i know https encrypts all data that is sent over the line, though I don't know whether LR's networking supports https at all. But if it does I should think that all http traffic is encrypted. It would be quite bad if it wasnt, because every http request sent to the gallery contains the auth key, and if an attacker came to know it, he/she could cause quite a lot of harm. The login credentials you enter into the login dialog are used just once to fetch the key, the password isn't even saved at all by the plugin. Come to think of it, the key really shouldn't be as prominently displayed as it currently is. I'll change that.
Update: Key is more private now.
Posts: 28
Cool on the update.
I initially asked the question, because I was lazy and didn't want to order a cert, setup ssl to test and do a packet capture to test, if someone already knew this answer. Well, here are the results of the test:
- LR 3.2 *does* support http traffic over SSL (https)
- Without SSL, the auth key and initial passing of the password is easily seen with a sniffer (as expected)
I think it probably makes sense to highlight somewhere in the documentation that there is a vulnerability if you are not using https (Gallery should point this out to folks, as well). Then again, sites like facebook do insecure submits all day long... that's just poor.
################################
Clicking 'Request Key' > 'OK'
(insecure http url)
X-Gallery-Request-Method: post
Content-Type: application/x-www-form-urlencoded
Content-Length: 28
Accept: */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: keep-alive
user=<MY USER NAME CLEAR-TEXT>&password=<MY PASSWORD CLEAR-TEXT>
22
"<NEW KEY CLEAR-TEXT>"
0
################################
Clicking Publish
(insecure http URL)
X-Gallery-Request-Method: post
X-Gallery-Request-Key: <MY KEY CLEAR-TEXT HERE>
Content-Type: multipart/form-data; boundary=_846843213219879654635132_
Accept: */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Content-Length: 687970
Connection: keep-alive
################################
Clicking 'Request Key' > 'OK'
(secure httpS url)
+.KGSa.......gp.Y........}.|-.y....~.U.t....O..-...hEm.....Xw"Kg...R@....?..toa.1!....@.]L..S6..E... ?,..K....hh..a>.H#.N..G.5e..... N`x..)...4f.%..Y/.
Wl.......V>......
\.....g....g9!.G..s...%..I*........*...q.....{|..5P./.........i.1./...:..H...Z.....
u..!m.A.|.(.`..s
.O..3ux..y..i.D.)].j.s....+..~.\.G......
...R....`.. m..f.a..k......m.PT..O.._.R....%.._...*. 6..0..P.f.].E.....G...-;..(...]...s..[..a..:lM....'.....
@...K.(..)../I...t.*..@.!i....r...O$4p.<..._.Y......
################################
Clicking Publish
(secure httpS URL)
..*.H..
..........K..L%.......K...#B.U,.....!T!._.Od7..!.2...SJ%.-..l..?.E+.....}.\8..W.G.....$.....8F.m..p|.#D.u.~.*k..^..U.e41)........
P..'.7n7Q.V'... \Mh..K...M........G.M..qk.......D.....N..C...M.C....3....E.......q<B&....5Su....<.T...."D....F.H9*..
j.. ??Z...#z.....;x.&D........d...............4..)\.......H#]..~...u....3."H...C......n.u.......y{.Sk..2.'.!...5.B.Y.D.....S
%.*qf..3.|.....K..jf`..T.%S.]..."..<T...&R..F8..V.......d....0...."..do.qV.W.C..M.m!.....fgy...i."...L..T..y..y..........0
.ApA..j.U.4........9....v.?t....L..O...."....dY`......._ -<........ot...G..........?}..0r....d..2.-.'.u...s4....T... 8^Y.....4b..bv
################################
Posts: 64
Good to know https works. However, I don't think this is really such a big risk for most people. Sure, if an attacker can sniff the traffic, then you're in trouble, but for the overwhelming majority of people and network setups this is extremely difficult. I'm behind a router which regularly pulls security updates from my ISP and doesn't expose my machine's traffic to other network participants; over here in Germany, this is what most people have nowadays. Even on public wifi hotspots you usually can't sniff other people's traffic. That doesn't make it impossible to exploit that vulnerability, but you'd need to take control of the router or some part of the ISP's infrastructure, and an attacker capable of that would probably not be stopped by https encryption, at least if the client runs windows ;) So, while I do agree that this is a vulnerability and that there are setups where this would be dangerous, I'd rather not highlight it too much, since people who don't fully understand the matter might be frightened away to flickr (who don't even support https at all afaik), even though they'd in practice be perfectly safe. Facebook, on the other hand, that's really poor, they ought to at least offer https (which to my knowledge they don't) since that traffic just offers so much possibilities for ISPs to profile their customers .. but then, it's not as if they cared about their users' privacy, so they're probably just being consequent.
Apart from that, if you find any other security issues, let me know, I'll be glad to try and patch them if I can.
So long
Three
Posts: 64
Fairly big update (0.3):
* Merged with Gloopers Lightroom 3 Export code. This can now do both publish service-ing and exporting.
* Lots of bugs fixed
* Lots of new bugs introduced, since I've restructured and rewritten a lot of the code - I ran my testing regimen and couldn't find any, but there must be lots of them in there. When you put your ear really close to the CPU, you can actually hear them crawl around (AMD only)
* New (hopefully better) GUIs
* Collection names are now being validated
* A few error messages make more sense now (or appear at all)
* Export should be preset-friendly (seems to work for me, at least)
* More than one publish service to different gallery installations and using different user accounts are (should be) now supported too
* "Go to published photo" etc. won't work with RC2, only with recent code. This is a known issue.
* Lots of other stuff that I can't remember right now.
Besides, if anyone in the know is reading this, are there any official repositories or web sites or any kind of central registry for Gallery 3 clients? I don't think too many people will find this forum thread, so once this is stable enough for everyday use something more exposed would be good.
Posts: 28
Security... perhaps it's out of habit of working on systems with sensitive data, but I just don't login with an admin ID to any system without secure auth. Hackers tend to be particularly crafty, regardless of physical access. You are right, more users might be 'scared' away by the truth!
Re: best location to post. There is the git contrib area, but since this is a lightroom plugin (versus a gallery module)... maybe consider the Adobe Lightroom Exchange. Similar export/publish plugins have been posted there in the past.
http://www.adobe.com/cfusion/exchange/index.cfm?event=productHome&exc=25
Posts: 225
Just tried the integrated export functionality. Works well. I like the interface, it's a bit more streamline than the original. Not so keen on the pop-up message boxes that appear after things happen, but once logged in you don't see them again anyway so I'm fine with it. Excellent stuff.
.
The only bug I've noticed is that it doesn't remember the last album you've chosen in the drop down list, which it did before, was useful when you keep uploading to the same album.
Cheers
Ben
Benjamin Albert Smith - Photography
Pikitia - New Zealand Photography
Posts: 64
Avery: If you're going to use Gallery3 for sensitive or just valuable images, by all means encrypt your traffic and make sure all modules you use are secure. I fully agree, if that's what you're storing in there, then you had better have good security, and if possible it'd be best not to expose it at all to the www. If, on the other hand, all you upload is photos of your ugly aunt marge's brutally boring birthday party, then I'd say the risk of being compromised by some crafty hacker sniffing your traffic is minuscule, it's not exactly trivial to do that after all.
Lightroom Exchange.. makes sense. I'll take a look.
Glooper: Bug fixed, album name is now being remembered. I've updated the initial posting's file attachment.
Posts: 22
This is awesome!
But, I get an error when publishing pictures. It reads:
[Window Title]
Warning
[Main Instruction]
Can’t update this collection.
[Content]
An internal error has occurred: [string "G3PublishServiceProvider.lua"]:207: attempt to index global 'collectionInfo' (a nil value)
Keep up the good work!
Åsmund
Posts: 64
aalang: Thanks! I've found the error, it should work now, please download the latest version (file attachment in the initial posting) and try again.
Posts: 6
I ran into the attempt to index global 'collectionInfo' problem as well (Lightroom 3.2, OS X 10.6.4, Gallery git pull 3936183446375e039cc3).
It turnes out that
local collectionInfo = exportContext.publishedCollectionInfo
needed to be pulled out above the
if exportSettings.LR_isExportForPublish then
line.
Once I did that it seams to be working well.
Thanks very much for publishing this. I have been looking for a good way to manage my high res images locally and lower res ones on gallery.
chris.
Posts: 64
pyjamasam: Yep, I was looking for something to do that, too. It's really quite unnerving that there is no good solution for that, at least for people who would like to have proper sorting, which rules out flickr. I hope this will turn out to be useful for other people too, but for me it definitely is, I've been looking for a solution like this for ages.
And yes, you're right, that was the issue, thanks for helping! Quite embarassing to miss such a blunder in testing .. and it seems the defunct version was online until a few minutes ago, though I definitely did upload the fix almost 24 hours ago.. that's really odd. I might have forgotten to hit this "Attach" button or so. But anyway, I double-checked and it really is the corrected version now.
Also, I've nearly completed comment integration. There's still a problem on the API side (pulling user information via REST, can't seem to find a way to do this) but apart from that it's all implemented and working for me. And I did declare and use all variables in the right order.
Posts: 88
Hi,
I always get "result is nil" and "failed to retrieve auth key" when I want to add an account.
What can be wrong?
[IMG]http://cindyenguy.be/ico_www.gif[/img] My Blog [IMG]http://cindyenguy.be/ico_www.gif[/img] My Gallery
Posts: 64
That's interesting. This means the request is sent to the Gallery and that there is neither success nor a 404 or 403 response. What Lightroom version are you on? What's your gallery version? Is there any number (http status code) after the "failed to retrieve auth key"? You might also want to make sure the REST module is activated in your gallery and check your URL again (it should look like http://example.com/gallery3/ with no index.php or /rest/ or the like.)
So long
Three
Posts: 22
3.14159: It's getting there
I now get another error
[Window Title]
Warning
[Main Instruction]
Can’t update this collection.
[Content]
Error uploading image. (Code: 400)
with the previous error it did upload the picture, now it does not.
Posts: 88
If I use http://galerie.cindyenguy.be as URL I get "wrong username/password"
If I use galerie.cindyenguy.be as URL I get the "Result is nil" and "failed to retrieve auth key"
I am using Lightroom 3.2 64bit op Windows 7 64bit
Gallery version is normally the latest, as for now: gallery3-3.0-rc-2-298-g3936183
[IMG]http://cindyenguy.be/ico_www.gif[/img] My Blog [IMG]http://cindyenguy.be/ico_www.gif[/img] My Gallery
Posts: 64
GuyVerschuere: The http:// is necessary, you can't omit that. So .. are you really sure your credentials are valid? i've checked in the code, the only way this error message can possibly show up is when gallery returns a "403 Forbidden" header to your authentication request. That's also the only way I can reproduce this. So either something is seriously broken or it's just that .. before i start digging deeper into the code please check again if your user name and passwort really are correct.
aalang: Code 400, that's odd. What gallery version are you on, and what exactly were you trying to do? I'll send you a private message with another thing you could try.
Posts: 88
I'm still getting the wrong username/password error.
Even changed my password to be sure the & symbol doesn't make a problem. Now, even with a new plain text password I get the error.
I asume the plugin relayes on the REST plugin? How can I check that one is fine?
I'll send you temporary password thru PM.
[IMG]http://cindyenguy.be/ico_www.gif[/img] My Blog [IMG]http://cindyenguy.be/ico_www.gif[/img] My Gallery
Posts: 64
Guy: Thanks! I'm taking a look right now, I can reproduce the issue.
OK, it seems your url rewriting is to blame; I'm currently guessing the rest base url, and i'm using gallery_url/index.php/rest/. For you, it's just /rest/ (which returns a 404 file not found on other gallery installations). When I use just the / When I open the URL in a browser I'm being redirected just fine, but that doesn't seem to work for POST requests. You could try using the default .htaccess file, if that solves your problem we know for sure. If the .htaccess is the culprit, then I guess you could fix that if you excluded all /index.php/rest/... urls from being rewritten. These aren't supposed to be opened in a browser anyway, so your users wouldnt notice that. I'll see that I include an option to specify the relative REST path in the next version, but that will take some time. For now that htaccess tweak should be your best bet, more so since other clients will probably have problems with that, too.
So long
Three
Posts: 88
That's the problem! Thans for finding it.
Now I just need to find how to disable it just for the rest plugin....
[IMG]http://cindyenguy.be/ico_www.gif[/img] My Blog [IMG]http://cindyenguy.be/ico_www.gif[/img] My Gallery
Posts: 88
It isn't easy
this doesn't work:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^rest/(.*)$ rest/$1 [L]
RewriteRule ^(.*)$ index.php?kohana_uri=$1 [QSA,PT,L]
RewriteRule ^$ index.php?kohana_uri=$1 [QSA,PT,L]
RewriteRule ^index.php/(.*) $1 [QSA,R,L]
</IfModule>
and this also doesn't work:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_URI} ^/rest/.*$
RewriteRule ^.*$ - [L]
RewriteCond %{REQUEST_URI} ^/REST/.*$
RewriteRule ^.*$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php?kohana_uri=$1 [QSA,PT,L]
RewriteRule ^$ index.php?kohana_uri=$1 [QSA,PT,L]
RewriteRule ^index.php/(.*) $1 [QSA,R,L]
</IfModule>
Anyone who knows how to set.htaccess to exclude the rest module?
[IMG]http://cindyenguy.be/ico_www.gif[/img] My Blog [IMG]http://cindyenguy.be/ico_www.gif[/img] My Gallery
Posts: 64
Yeah, this rewrite stuff is tricky. I've written a quick fix, though. The login form now includes a "Path to REST base" field, for you that should be "/rest/". Since theres an unfinished comment integration in there (that I hope I commented out completely) I'll wait till I have that feature finished until i release this, but it should work for you in the meantime.
Posts: 88
THANK YOU!
it works!
[IMG]http://cindyenguy.be/ico_www.gif[/img] My Blog [IMG]http://cindyenguy.be/ico_www.gif[/img] My Gallery
Posts: 64
Guy: Good to hear!
aalang: thanks for the log file. this is really puzzling, there seems to be nothing wrong with the request that is sent, everything looks good. It also can't be missing rights for your gallery user, since that would return 500 Internal Server Error and it can't be a missing album either since that's a 404 (I tried both). It's gotta be something with the data sent, but as far as I can see everything's alright there (and I just don't believe that LR would produce invalid jpeg files.) Any way I could get access to your gallery to try myself? A temporary account with a temporary album would do fine, lock it down as much as you want, I just need a place I can upload an image to. I could then take a closer look at the HTTP traffic going over the wire, and maybe find something there.
Posts: 22
3.14159: Thanks! I'll set up an account for you. Sending you an email with the details.
Posts: 6
So some things I have discovered while working through my close to 30k of images.
- I managed to "break" things by deleting an album from Gallery through he web interface and then trying to "re-publish" it from Lightroom (I did this a few times while tuning the settings between the 2 apps.
- That being said I have modified the code so that it now detects a missing album and creates a replacement. It might not be the proper solution, but it seams to work for the use case I ran into specifically. I would gladly share that if your interested.
- Having lightroom upload a 640x? sharpened image is great, except Gallery still does all its image processing on it.
)
- Since I have gallery set to display 640x? images, and lightroom is uploading them that sized it seams overkill.
- Again, code to solve that. I added a new "noop" graphics method to Gallery, and configured my "resize" graphics rule in the DB to use this new noop method (it just copies the source to the destination so the files are where gallery expects them). This greatly sped up uploads and now I think I am hitting my upstream bandwidth limit instead of waiting on the server to process the images (I live in a rural area so my DSL line is slow
- Along the same lines, I commented out sharpening in the gallery resize method. I don't really care if the thumbnails are resized and it again saves cpu cycles when uploading lots of images.
- I also added a "sort by file name" option to Gallery (I setup album names based on year and then month and then a descriptive name) so that I could sort things "chronologically" based on when an even occurred. (even if the images are from different dates).
Overall I am REALLY happy with this plugin. You have done a great job with it. I think the only things on my wish list are video support (which might be possible as a module/addon with somthing like FFMPEG transcoding to h.264 on the server side after upload or what not.) and nested collections so I don't end up with names like 2008/05AACRegionals or even worse 2008/11EuropeVacation/London
Great stuff, I really appreciate you releasing this plugin. Its enabled me to move away from iMatch and a custom export/html builder script to something slightly more modern
chris.
Posts: 64
aalang was able to solve the mystery; if anyone else experiences code 400 errors, deleting and republishing the responsible images should help.
pyjamasam: thanks for the praise! glad to hear this works for you, and for your pretty specialized requirements, too. i agree the behaviour on missing albums (and when updating missing images, too!) can't stay that way. I have an idea how to fix that, but please share what you have, yours might be better.
as to the rest of your modifications, they concern the gallery software, don't they? in that case you could package them into modules if you havent already done so, especially the "sort by filename" might be useful to a lot of people.
concerning your wish list, i'd like to have nested collections, too, but lightroom simply doesn't support that. you can nest collection sets, but these can't hold any photos; you could have a "Photos in this album" collection inside each collection set, but some users would inevitably delete them and there's currently no way to prevent that, as far as I know. Also, it would probably be a lot more visual clutter than the current solution, crude as it may be. I do hope Adobe includes nested collections in a future release, but for now I think the way I'm doing it is the best of the available options. I'm always open to suggestions, though.
As to uploading video, I'm currently not supporting this because I have absolutely no idea how this video stuff works, both in gallery and LR. I believe enabling it in LR isn't hard, one line of config and another two or so lines to make sure there's "type:video" instead of "type:photo" in the upload requests. However, if I understand correctly, then somewhere somehow there must be a transcoding step to get something that flash-based video players or browsers can play. Where does that happen? It had better not be on gallery's end, since that would surely not fit into any sensible php execution time limit, and would probably not be tolerated by many shared hosters either, since that kind of thing eats up loads of resources. If it has to be done on LR's end, though, and if it isn't already being done by LR (which I doubt), then I'd have to hand it off to an external application to do this and cope with a whole host of ways for things to go awry, on two different platforms (win+mac) no less. What is more, since I don't even have any videos in my LR catalogue (and my SLR doesn't do video) I could hardly help anyone for whom it doesn't work. And from a user experience perspective, if I were to do the transcoding on the client side, having to wait half an hour per file with 100% system load might not appeal to people used to fast connections and the youtube/flickr experience. I'd like to include that functionality, but for now I suppose all I could do would be to simply push the unprocessed video file over the wire. I think i'll stick to both lr's and gallery's core competence for now, photos.
so long
three
Posts: 6
Sure. When I get home tonight I'll grab the code and do a diff from the latest version you posted and post it up here for you.
I am not totally sure that they could be included as a module. They are modifications to some basic parts of Gallery. Its somthing I could add as a ticket and submit a patch for, but either way, its not major changes in the end.
One thing that I did think of this morning is that I actually have double copies of images floating around on my server now. A "normal" size version, and a "resized" version (which are exactly the same). I need to do some digging and clean that up, but its not a huge deal as they are small images, but its something I'd like to solve.
Hehe. Ya that's why its my wish list. Its stuff that's not quite feasible, or even if it is feasible it would take far to much effort to deal with. I have so few videos that it really doesn't matter, and as for the nested collections, your method of putting the / in the name works great. So all in all I am a happy camper.
chris.
Posts: 3
Hello (just registered to post this comment to improve an already fantastic plugin!
)
I seem to be experiencing Code 400 errors as well. What I found out from looking around a bit is as follows:
I'm using the modified plugin with the "Path to REST base" option field. Works basically OK (i.e. Export to Gallery3 is perfect), but... When trying to create an album as a target for Publishing, the following happens.
1) The Create album asks for the album name and accepts whatever the user gives OK.
2) The album accepts pictures for import
3) When clicking Publish, the plugin notices that the desired album is not (yet) present in Gallery3 and asks for a title.
4) The update then fails with a 400 error.
After looking at the error log in Gallery, the following clue is given:
2010-09-13 09:28:21 -07:00 --- error: Rest_Exception [ 400 ]: Bad Request /var/www/gallery/modules/gallery/helpers/item_rest.php [ 184 ]
#0 [internal function]: item_rest_Core::post(Object(stdClass))
Looking at item_rest.php, line 184, indicates that a Rest_Exception is thrown whenever the $entity->type is not any of album, photo or movie. What gives? It should be creating an album, shouldn't it?
Now here is where I think the "REST Base URL" option comes into play and isn't properly handled. I ran a Wireshark trace on the Publish communication, and the HTTP POST request is "POST /index.php/rest/item/1". This isn't really a problem from Gallery's (or Apache's, actually) point of view, and it gives a 302 Found redirect to the proper path (/rest/item/1). However, for some reason unknown to me, the LR Gallery plugin then tries a HTTP GET request on the redirect URL. This, of course, strips the POST contents from the request, leading to the exception being thrown by item_rest.php.
Could somebody please fix this? I'm a bit afraid to touch the plugin myself..
Best regards,
Sam
Posts: 3
Replying to myself here
Further debugging indicates that the property table used on Publishing is not the same as is used on Export.. Removing index.php from the default value of path_to_rest in G3Api.url apparently fixed the issue and that should only be used if path_to_rest is not set in the properties..
/Sam
Posts: 64
sounds good.
as to the wish list, these things happen to be quite high on mine, too, especially the nested collections issue. but there's nothing that can be done about that, sadly.
samwise_s: thanks for helping! these 400s are quite annoying, even more so since I fail to reproduce them. What is the exact error message you're getting?
Also, there's another source of information you could use; I'm using LR's LrLogger facility to debug these early builds; you should have a file called g3.log in your My Documents (win) or ~/Documents (mac) folder. I'm keeping a more detailed log of the steps the plugin takes there, nothing sensitive (no credentials or the like). Please repeat what you did to get the error and send me the last couple of lines of this debug file; maybe that information helps. The get request in your wireshark trace could be alright; i'm sending one immediately after posting the new album to fetch that album's id (the post request returns only a rest url.) This does not strip anything off the post request, since the requests are processed sequentially on the server; once the reply to the post request is out the next one (the get) can be processed. To me this indicates that creating the album probably works as intended; the 400 error might occur someplace inside the image upload part. I suspect that something breaks on updating from earlier builds to more current ones, I just don't have any idea what that might be. Any chance I could get my hands on an actual wireshark iptrace file?
As to the propertyTables, each publish service and each export has its own independent propertyTable; I'm saving the PATH_TO_REST in the global plugin preferences, though, and the property tables only store which of the accounts the current task uses. And in any way, unless you change the PATH_TO_REST setting, everything works just the way it did before (at least it should.)
I'll keep your hypothesis in mind at any rate, I'd be glad if you were right since then I had a starting point for a fix at last.
so long
Three
Posts: 3
I'm still not entirely convinced
The communication sequence is: "req: POST /index.php/rest/item/1" -> "resp: 302 FOUND, target /rest/item/1" -> "req: GET /rest/item/1" -> "resp: 400". This looks to me that the 302 isn't handled properly (Gallery3 probably doesn't even see the request as the 302 comes from mod_rewrite), but the 302 wouldn't even occur if the original POST path was correct (i.e. without the index.php). The album doesn't get created, and when trying to create an album structure, the title dialog is only displayed for the rootmost album, with the 400 failure after that. Removing index.php from the default rest path (in G3Api.url) works around the issue, but of course it's not a real fix.
I'll get you the debug info and Wireshark trace as you requested, that's not a problem at all
Might take a couple of days, I'm a bit busy for the next 72 hours or so.
BR,
Samwise
Posts: 64
Wait, did you change the rewrite settings in the .htaccess? I can't reproduce any 302 responses on none of my test setups (gallery3 latest code running on apache on win7 and apache on debian linux) and /rest/ without index.php doesn't even work in the browser either (404 from the web server, with /index.php/ it works.) if that's the case, then you'd enter /rest/ or /my_new_rest_path/ in the "path to REST base" field in the add account dialog, and then the plugin wouldn't send anything to /index.php/rest/ at all, since that would be expected to cause errors. If you didn't see that text field when you added your account, maybe you created it with a previous version of the plugin that didn't have this option yet. Just add the account again (the old one will be replaced) and enter /rest/ in the "path to rest" field; that should do the same as your workaround. if you did/do enter "/rest/" instead of the default "/index.php/rest/" and the default value shows up in any urls, that would be a good starting point for a fix.
Thanks!
so long
Three
Posts: 6
This is great! Thanks for doing it.
I have two (I think) simple suggestions:
1. In the 'Image Sizing' box of Publishing Manager, can you add a box to change the resolution of uploaded pictures.
2. Other authors have put an automatic update notification system in the Plug-In Manager so when there is a new version available it lets the user know.
Just my 2-cents.
Thanks again for doing this!
Rob
Posts: 64
You're welcome!
Change the resolution? You're talking about the dpi, aren't you? It's trivial to add indeed, but I disabled that on purpose; is there any sense in having that kind of setting when you export to a web gallery? I can't quite think of a use case for that, what's yours?
Interesting suggestion; I'll put that onto my todo list. I'll have to do all of this organizating stuff sometime soon anyway, for the moment I try to spend as much of the time I can devote to this project progamming and testing, that's why it's all a bit chaotic.
Posts: 5
Thanks so much for getting this plugin so far - it works great! I'm in the process of transitioning from Gallery2 to 3 and am really looking forward to using this in the future to export from lightroom - way nicer than manually uploading and importing as I had to do with 2! I had no problems with initially adding my photos to gallery, but I ran into the 400 error mentioned above when I added photos to existing albums or edited photos in a way that necessitated re-uploading... I saw that the current solution is to delete the offending photos and try again, but how does one figure out which photo is offending? I looked in gallery's var/log/<date> file and saw the entries relating to the failed attempt, but no reference to the photo:
2010-09-17 20:26:19 -06:00 --- error: Rest_Exception [ 400 ]: Bad Request
/home7/ellipsi3/ellipsisphotography/gallery3/modules/rest/controllers/rest.php [ 110 ]
#0 [internal function]: Rest_Controller->__call('item', Array)
#1 /home7/ellipsi3/ellipsisphotography/gallery3/system/core/Kohana.php(331): ReflectionMethod->invokeArgs(Object(Rest_Controller), Array)
#2 /home7/ellipsi3/ellipsisphotography/gallery3/system/core/Event.php(208): Kohana_Core::instance(NULL)
#3 /home7/ellipsi3/ellipsisphotography/gallery3/application/Bootstrap.php(67): Event_Core::run(Array, Array)
#4 /home7/ellipsi3/ellipsisphotography/gallery3/index.php(97): require('/home7/ellipsi3...')
#5 {main}
2010-09-17 20:26:19 -06:00 --- error: Missing messages entry kohana/core.errors.400 for message kohana/core
2010-09-17 20:26:19 -06:00 --- error: Rest error details: Array
(
[name] => conflict
)
Am I to delete the entire collection and recreate it, or is there an easier way?
Thanks!
Eric
Posts: 64
To everybody: If you find that deleting collections doesn't work, it's totally broken. I've fixed it and it'll work again in the next version, but for now it's a know issue.
Glad to hear you find it useful!
No, in your case that's definitely not a solution. I thought this was happening only when you had photos from a really early version of this plugin and updated to the latest one. But in your case that won't do, what's needed is a proper fix. You'll have to help me somewhat, since I couldn't yet reproduce this issue, though.
First, can you pinpoint anything you did that could have made the photos behave like that? did you update the plugin, perhaps? did you cancel any uploads? did you make any changes in the gallery?
Second, there's a log file in your My Documents (win) or ~/Documents (mac) folder called g3.log. I'd like to take a look at it, if possible. I'll send you my email address via PM.
Third, any chances you could make a wireshark trace of an upload that throws an error and send me the wireshark iptrace file? If you happen to be familiar with wireshark, that is. I'll be glad to help if there are any questions.
I do hope we'll find one!
So long,
Felix
Posts: 5
I did just install everything in this past week (Thursday, Sept 16), so I wasn't using anything super out-dated, but I did update from G3 rc 2 to the latest developer version 326-g4b8d6be. I'm running version 0.3.1 of the publish service, which I think is the most recent? I got your address and will send the requested log files via email, thanks for helping!
Posts: 64
September 16, that's as up-to-date as can be. I assume you did run the update script after upgrading your Gallery installation (/index.php/upgrader), so you should be up-to-date there, too. That's good because it rules out a lot of possible causes for this error, should make locating the issue easier. Thanks for helping! i'll wait for your email.
so long
Three
Posts: 64
New version: 0.3.3
# 0.3.3: Repaired deleting albums. This should work now. Deleting existing collections can't be done because the plugin failed to remember whether they were created by itself or not. Deleting collections created with version 0.3.3 onward should work fine.
# 0.3.3: Updating photos that aren't in the Gallery is handled more gracefully now (user is being prompted whether to delete locally or upload as new)
Get it here.
Posts: 64
Hmm. I've experimented a bit and I have a working prototype for a possible new feature. The functionality would be this: On adding a remote album to the publish service, it downloads all existing images and adds them to the catalogue; they're then being treated like any other photo you add to the published collection, you can edit them, republish them, use the comment integration (that will be in the next version), anything. I also have the parts to make a working synchronization, that is, on publishing the plugin could update the local copies of those downloaded if their counterparts in the gallery get updated; I didn't actually write this yet, but im 99% convinced it's can be done. Just loads of work to get all the critical details right.
I'm not sure if it makes sense to pursue this further, or if this is the kind of pointless feature that no one really needs anyway. Opinions?
Posts: 88
It can be useful to download the existing pictures, on the other hand, wouldn't that create double pictures in the catalogue?
[IMG]http://cindyenguy.be/ico_www.gif[/img] My Blog [IMG]http://cindyenguy.be/ico_www.gif[/img] My Gallery
Posts: 22
Great work!
I'm an old G2 user and having upgraded to the G3 most of my pictures sits both in G3 and in Lightroom. I like the idea of the new feature but i would like it to first attempt to locate the image in the Lightroom catalog. If found, then don't download. Just add to the collection. Else download.
The sync function sounds great. G3 could be used as an online backup.
Keep up the good work!
Posts: 64
Thanks for your feedback! I agree that duplicate pictures arent good. I could do what aalang suggests, it's definitely possible. But I think, in the end this really is the "concept car" kind of feature, impressive stuff but ultimately not very practical. Using Gallery as a backup might be possible, but I don't know of any way to export the LR editing info, so you'd always end up with one flat jpeg file only. That definitely wouldn't do for me. So I'm not going to integrate this, unless someone comes up with a really compelling use case. It'd be quite time-intensive, too, and I think that time is better spent doing useful stuff like localization. Maybe synchronizing metadata too (reflecting changes made to title or description via the web interface in the LR catalog), I could imagine that some people might find this useful (I probably would), but that's low priority. I think for now I'm going to push out a new version with comment support soon and then see that I find and fix as many bugs and quirks as i can and get localization done before I add anything this big (or if I do, then only as an optional experimental feature that people can wreck their catalogs with.)
so long
Three
Posts: 28
Pi -- Just wanted to voice that I REALLY like the sounds of that... especially since I'm planning on using GPS tagging and extensive meta tagging. And, yeah -- it would be really cool to maintain the updated title/description with a bidirectional sync!!!
Anyhow, thanks for all your work.
Posts: 64
Avery: What's meta tagging? As far as geotagging is concerned, changes to image metadata already trigger republishing, so one way sync should be already there. The other direction would be far more tricky; I can only bi-directionally synchronize what I can access via REST, like title and description (which don't require any additional modules, which is good). Is there any geotagging support in Gallery 3 and Lightroom? I had a quick look around and couldn't find any, but I may have missed something.
Finally, would being able to edit the geotagging info via the web interface and having that change reflected in the LR catalog really be that useful? Being able to correct a typo in the description without having to fire up LR is something that I've wanted to do numerous times, but wouldn't the gps position be inserted into the images in-camera or using data from a gps logger? In that case, I'd expect having to edit the gps position to be a very rare use case.
So long
Three