SmugMug Foto-Hosting-Integration mit simplem UDT

faglork · 04. Mai 2011 11:55

Moin!

Für alle die SmugMug nicht kennen: Es ist der IMO wohl beste Foto-Hosting Service der Welt. Nicht kostenlos (ab $40/Jahr), aber TOP. Einfach mal die Features durchlesen (schon allein der Drag&Drop Datei Upload spart Zeit ohne Ende):
http://www.smugmug.com/
SmugMug verfügt zudem über ein gut ausgebautes CDN, die Galerien laden also schnell.

Nun gibt es für SmugMug einen PHP-Wrapper: http://phpsmug.com/

damit lässt sich ultraeinfach ein UDT zur Integration von SmugMug-Galerien basteln (ich weiss, der code is nix berühmtes, aber funktioniert prima):

Aufruf:

Hier klicken, um den Code zum Kopieren zu markieren

{smugmug id="yourAlbumID" key="yourAlbumKey"}

Der code für den UDT "smugmug" (Hinweis: man benötigt nen kostenlosen SmugMug API key):

Hier klicken, um den Code zum Kopieren zu markieren

require_once( "/your/server/path/to/phpSmug.php" );
try {
        $f = new phpSmug( "yourAPIKey", "AppName=yourAppName" );     
// Login Anonymously
     $f->login();         
// Get list of public albums
     $albums = $f->albums_get( 'NickName=yourNickName' );         
// Get list of public images and other useful information
     $images = $f->images_get( "AlbumID=$params[id]", "AlbumKey=$params[key]", "Heavy=1" );
     $images = ( $f->APIVer == "1.2.2" ) ? $images['Images'] : $images;     
// Display the thumbnails and link to the large image for each image
     foreach ( $images as $image ) {
         echo '<div class="img"><a href="'.$image['LargeURL'].'" rel="lightbox[gallery]"><img src="'.$image['ThumbURL'].'" title="'.$image['Caption'].'" alt="'.$image['id'].'" /></a></div>';
     } 
} 
catch ( Exception $e ) {
     echo "{$e->getMessage()} (Error Code: {$e->getCode()})";
 }

Ein bisschen Lightbox (o.ä.) dazu und nach belieben stylen.

Live-Beispiel:
http://www.kirschenfest-pretzfeld.de/bilder.html

Für Leute die ein Zentrallager von Fotogalerien benötigen, um diese dann bequem auf mehrere Domains nach Bedarf zu verteilen, eine ideale Lösung (IMO).

Servus,
Alex

Beitrag geändert von faglork (04. Mai 2011 12:00)

Andynium · 05. Mai 2011 12:02

Danke für deinen UDT ... würde mir aus Performance-Gründen trotzdem überlegen, die Bilder auf deinem Server zu cachen.

faglork · 10. Mai 2011 15:01

cyberman schrieb:

Danke für deinen UDT ... würde mir aus Performance-Gründen trotzdem überlegen, die Bilder auf deinem Server zu cachen.

Lohnt sich nicht, IMO:

- die Anbindung der SmugMug-CDN ist superschnell
- eben durch das CDN sind mehr parallele Downloadprozesse möglich als wenn alles von einem Server käme

Probiers aus: ruf mal die oben genannte Seite auf, öffne ein Bild und klick dich mit den "weiter"-Pfeilen durch. Die Bilder werden ja AFAIK nicht vorgeladen. Schneller macht mein Server das auch nicht ...

Servus,
Alex

Beitrag geändert von faglork (10. Mai 2011 15:05)

Andynium · 10. Mai 2011 15:24

War nur so ein Gedanke ... soweit ich sehen konnte, stehen die Server in Kalifornien und die Daten müssen von da erst mal hier her. Wenn da wieder mal eine Ölplattform auf ein Unterseekabel fällt, ist Schluß mit lustig wink .

Außerdem verschenkst du dir damit die Vorteile von datauri's - ich gebs ja zu, bin eher ein Kontrollfanatiker cool .

nockenfell · 10. Mai 2011 15:37

cyberman schrieb:

Außerdem verschenkst du dir damit die Vorteile von datauri's - ich gebs ja zu, bin eher ein Kontrollfanatiker .

Bin im Moment eine Gallery mit datauri's am testen. Im Moment frage ich mich noch, ob sich dies lohnt oder ob dann das Laden zu lange geht. Habe dabei ca 15 Bilder mit der Grösse 485x300px eingebunden.

NaN · 10. Mai 2011 15:54

Mich würde auch mal interessieren, ab welcher Größe bzw. Anzahl data-uri empfehlenswert ist.
Im Stylesheet ist es bestimmt immer recht nützlich, da weniger requests und dennoch im Cache.
Aber im Inhalt? Da fehlen mir noch Erfahrungswerte.

Connie · 10. Mai 2011 16:10

Sagt mir doch bitte was ein CDN ist, wird da wieder eine Sau getrieben und ich kriegs nicht mit?` sad

NaN · 10. Mai 2011 16:30

http://de.wikipedia.org/wiki/Content_Di … on_Network

Connie · 10. Mai 2011 18:32

NaN schrieb:

http://de.wikipedia.org/wiki/Content_Di … on_Network

achso, könnte ja auch Cloud Distribution Network sein, danke!

Andynium · 11. Mai 2011 07:23

nockenfell schrieb:

Habe dabei ca 15 Bilder mit der Grösse 485x300px eingebunden.

Welche Größe haben die?

Der IE8 hat da eine Grenze von 32 kB

https://secure.wikimedia.org/wikipedia/ … URI_scheme

nockenfell · 11. Mai 2011 07:34

cyberman schrieb:

nockenfell schrieb:
Habe dabei ca 15 Bilder mit der Grösse 485x300px eingebunden.
Welche Größe haben die?
Der IE8 hat da eine Grenze von 32 kB
https://secure.wikimedia.org/wikipedia/ … URI_scheme

Das ist abgefangen. Allerdings wird die HTML Seite unkomprimiert damit 832Kb gross. Das ist gerade bei nicht so guten Internetverbindungen, z.B. per UMTS/Edge recht viel.

Andynium · 11. Mai 2011 07:45

nockenfell schrieb:

Allerdings wird die HTML Seite unkomprimiert damit 832Kb gross. Das ist gerade bei nicht so guten Internetverbindungen, z.B. per UMTS/Edge recht viel.

Sollte sich doch aber als Text recht gut komprimieren lassen ...

faglork · 12. Mai 2011 09:56

cyberman schrieb:

Außerdem verschenkst du dir damit die Vorteile von datauri's - ich gebs ja zu, bin eher ein Kontrollfanatiker .

Ähem ... warum? Habe mich mit dem Thema bisher nicht auseinandergesetzt ... aber warum sollte man den obigen UDT nicht erweitern können mit dem Beispielcode aus der Wikipedia:

Hier klicken, um den Code zum Kopieren zu markieren

<?php function data_uri($file, $mime)  {
     $contents = file_get_contents($file);
   $base64   = base64_encode($contents);
    return ('data:' . $mime . ';base64,' . $base64);
 } ?>   

<img src="<?php echo data_uri('elephant.png','image/png'); ?>" alt="An elephant" />

Gestz den Fall es geht, was würde es tatsächlich bringen? Hat da jemand Erfahrung damit?

In dem Wikipedia-Artikel steht zudem, dass die Bilder in diesem Fall nicht gecached werden, und das betrifft doch dann auch alle Proxies, oder?

Wikipedia schrieb:

Data-URLs können nicht separat von den sie enthaltenden Dokumenten (beispielsweise HTML- oder CSS-Dateien) gecacht werden, somit werden die Daten erneut heruntergeladen, wenn das Dokument neu geladen wird.

Aber diese Diskussion geht ein bisschen am Thema vorbei. SmugMug hat halt ganz bestimmte Vorteile, ich kenne da nix Vergleichbares (wenn jemand ne alternative kennt, bitte melden):

Unlimited photo uploads
Max photo file size 24MB
Unlimited traffic

Video:
Quality 1080p
Clip length 10 min
etc. etc.

Ich kann da meine Originalaufnahmen von meiner Nikon hochladen, und kann für jede Gallery angeben in welcher Größe die Bilder angezeigt werden sollen. Probierts mal aus - ladet in irgendeine Gallery von CMSMS 20 Bilder mit je 20Mb und lasst Vorschaubilder generieren ... in 5 Größen ...

Servus,
Alex

Beitrag geändert von faglork (12. Mai 2011 10:20)

faglork · 12. Mai 2011 10:43

Moin!

cyberman schrieb:

War nur so ein Gedanke ... soweit ich sehen konnte, stehen die Server in Kalifornien und die Daten müssen von da erst mal hier her. Wenn da wieder mal eine Ölplattform auf ein Unterseekabel fällt, ist Schluß mit lustig .

Kauf dir mal ne Brille, oder wo hast du da hingesehen? wink

Jedes ordentliche CDN ist weltweit verteilt, sonst nutzt es ja wenig. SmugMug nutzt AKAMAI, und der Server (genauer: die Server) steht natürlich in Deutschland:

Server lokalisieren

Ich schrieb:

ping wiesentbote.smugmug.com
Ping a539.b.akamai.net [195.50.164.202] mit 32 Bytes Daten:
Antwort von 195.50.164.202: Bytes=32 Zeit=19ms TTL=56
Antwort von 195.50.164.202: Bytes=32 Zeit=20ms TTL=56
Antwort von 195.50.164.202: Bytes=32 Zeit=25ms TTL=56
Antwort von 195.50.164.202: Bytes=32 Zeit=19ms TTL=56

Lasst euch das mal auf der Zunge zergehen: Ihr könnt Akamai nutzen, und das quasi für lau!!!
Siehe dazu auch folgenden Artikel

Ich glaube nicht dass irgendeiner hier im Forum nen Hoster mit auch nur annähernd vergleichbaren Daten hat wink

Servus,
Alex

Beitrag geändert von faglork (12. Mai 2011 10:47)

Andynium · 12. Mai 2011 13:15

faglork schrieb:

In dem Wikipedia-Artikel steht zudem, dass die Bilder in diesem Fall nicht gecached werden, und das betrifft doch dann auch alle Proxies, oder?

Nicht im Browser-Cache, aber lokal könntest du die Dateien base64-kodiert schon speichern und bei Bedarf von dort als simple Textdatei bereit stellen und komprimiert ausliefern lassen.

Wie gesagt, war ja nur 'ne Idee ... mit seiner Performance kann jeder anstellen, was er will. Jede externe Verbindung kostet Performance, und die lässt Google bekanntlich in seine Bewertung einfließen.

PS: Für deinen Beispiellink kommt für das favicon.ico und /css/print.css ein 404er Fehler.

faglork · 12. Mai 2011 14:08

cyberman schrieb:

Wie gesagt, war ja nur 'ne Idee ... mit seiner Performance kann jeder anstellen, was er will. Jede externe Verbindung kostet Performance, und die lässt Google bekanntlich in seine Bewertung einfließen.

Au contraire. Das ist grade der Sinn von einem CDN - Performance-Verbesserung. Denn: AFAIK lassen Browser nur eine begrenzte Zahl von gleichzeitigen Verbindungen pro Domain zu. Siehe dazu
http://blogs.msdn.com/b/ie/archive/2005 … 07189.aspx

Microsoft Developer Network schrieb:

Clients that use persistent connections SHOULD limit the number of simultaneous connections that they maintain to a given server. A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy.
Saavy web developers can take this connection limit into account and deliver their data from multiple domains, since the browser will open up to two connections per domain. You can see this trick on pages like Office Online Templates using Microsoft Fiddler or another network monitoring tool. In this case, two domains (office.microsoft.com and i.office.microsoft.com) split the load, permitting up to four simultaneous connections.

Nach RFC 2616 also nur 2 gleichzeitige http requests PRO SERVER.
Bei Einsatz von nur einem (1) CDN hast du schon 4. Das ist eine deutliche Verbesserung ...

In diesem speziellen Fall kommt dazu, dass die Akamai-Server
a) besser angebunden sind als die meisten üblichen Server
b) vergleichsweise gigantische Datenmengen ausliefern können

Servus,
Alex

faglork · 12. Mai 2011 14:22

cyberman schrieb:

PS: Für deinen Beispiellink kommt für das favicon.ico und /css/print.css ein 404er Fehler.

Ahhrrrgh ... danke. Gefixt.

Alex

Andynium · 12. Mai 2011 14:46

faglork schrieb:

Nach RFC 2616 also nur 2 gleichzeitige http requests PRO SERVER.

Eben ... genau das ist der Trick daran - datauri's verursachen KEINEN zusätzlichen Request wink .

Wikipedia schrieb:

Eingebettete Daten benötigen keinen HTTP-Request und sparen Traffic und Bandbreite, wenn der Overhead der Kodierung kleiner ist als der HTTP-Overhead. Beispielsweise ist ein 600 Byte großes Bild Base64-kodiert 800 Bytes groß. Wenn nun der HTTP-Overhead mehr als 200 Bytes beträgt, ist die Data-URL effizienter.

und

Wikipedia schrieb:

Webbrowser sind gewöhnlich so konfiguriert, dass nur eine bestimmte Maximalanzahl an HTTP-Verbindungen zum gleichen Webserver aufgebaut werden,[6] somit sparen eingebettete Daten zu Gunsten anderer Inhalte HTTP-Verbindungen ein.

Andynium · 12. Mai 2011 15:05

Schau mal hier

http://www.webpagetest.org/result/110512_A7_KEA8/

dann weisst du, was ich meine ... ich möchte meinen Kunden nicht erklären müssen, weshalb seine Webseite erst nach 11 Sekunden vollständig geladen ist.

faglork · 27. Juni 2011 10:35

cyberman schrieb:

http://www.webpagetest.org/result/110512_A7_KEA8/

Naja .... ich verlass mich da lieber auf eigene Messungen.

Habe das eben mit geleertem Browser-Cache getestet (Anbindung normale DSL, 5,7Mbit): Es hat nicht mal 4 Sekunden gedauert, bis
http://www.ebermannstadt.biz/de/fotogal … luete.html
geladen war. Selbe Seite mit Smartphone über Edge-Verbindung: knapp 7 Sekunden.

4 Sekunden für ne Galerie? Damit kann ich gut leben.

Vor allem: Den Aufwand, um die paar Sekunden *merklich* zu verbessern, zahlt kein Mensch.

cyberman schrieb:

... ich möchte meinen Kunden nicht erklären müssen, weshalb seine Webseite erst nach 11 Sekunden vollständig geladen ist.

Muss ich auch nicht:

a) es dauert definitv keine 11 Sekunden, ne Standard-DSL-Verbindung vorausgesetzt. Das kann man jetzt diskutieren, aber ich halte eine Fotogalerie in den meisten Fällen für nicht sooo wichtig, dass sie auch über 56k zackig rüberkommen muss ...

b) es ist ne Foto-Galerie - die laden immer etwas langsamer als "normale" Seiten. Wenn der Rest fix ist, akzeptieren die Leute das auch ...

c) bin ich in diesem Fall mein eigener Kunde ;-)

Ich werd trotzdem mal versuchen, datauris zu verwenden (sobald ich Zeit dazu finde).

Wenn sonst jemand ne Idee hat zum Beschleunigen, nur her damit. Wenns zu verbessern geht, bin ich immer dabei.

Servus,
Alex

Forum für CMS/made simple

#1 04. Mai 2011 11:55

SmugMug Foto-Hosting-Integration mit simplem UDT

#2 05. Mai 2011 12:02

Re: SmugMug Foto-Hosting-Integration mit simplem UDT

#3 10. Mai 2011 15:01

Re: SmugMug Foto-Hosting-Integration mit simplem UDT

#4 10. Mai 2011 15:24

Re: SmugMug Foto-Hosting-Integration mit simplem UDT

#5 10. Mai 2011 15:37

Re: SmugMug Foto-Hosting-Integration mit simplem UDT

#6 10. Mai 2011 15:54

Re: SmugMug Foto-Hosting-Integration mit simplem UDT

#7 10. Mai 2011 16:10

Re: SmugMug Foto-Hosting-Integration mit simplem UDT

#8 10. Mai 2011 16:30

Re: SmugMug Foto-Hosting-Integration mit simplem UDT

#9 10. Mai 2011 18:32

Re: SmugMug Foto-Hosting-Integration mit simplem UDT

#10 11. Mai 2011 07:23

Re: SmugMug Foto-Hosting-Integration mit simplem UDT

#11 11. Mai 2011 07:34

Re: SmugMug Foto-Hosting-Integration mit simplem UDT

#12 11. Mai 2011 07:45

Re: SmugMug Foto-Hosting-Integration mit simplem UDT

#13 12. Mai 2011 09:56

Re: SmugMug Foto-Hosting-Integration mit simplem UDT

#14 12. Mai 2011 10:43

Re: SmugMug Foto-Hosting-Integration mit simplem UDT

#15 12. Mai 2011 13:15

Re: SmugMug Foto-Hosting-Integration mit simplem UDT

#16 12. Mai 2011 14:08

Re: SmugMug Foto-Hosting-Integration mit simplem UDT

#17 12. Mai 2011 14:22

Re: SmugMug Foto-Hosting-Integration mit simplem UDT

#18 12. Mai 2011 14:46

Re: SmugMug Foto-Hosting-Integration mit simplem UDT

#19 12. Mai 2011 15:05

Re: SmugMug Foto-Hosting-Integration mit simplem UDT

#20 27. Juni 2011 10:35

Re: SmugMug Foto-Hosting-Integration mit simplem UDT

Fußzeile des Forums