Viele Styles funktionieren nicht mit Gallery2-Zufallsbild

[hackerart]

Mache ich etwas falsch oder funktionieren die meisten Styles mit einem Zufallsbild aus einer Menalto-Gallery2 in der Seitenliste nicht?

Wer will kann es selber bei http://hackerart.at/ testen, ich habe dafür in der Seitenleiste oben eine Template-Auswahl ermöglicht.

Folgendes dürfte mit "großen Bildern" nach kurzem Test funktionieren, manchmal gibt es Probleme mit dem Blog-Titel

Bazooka
Blue
Blue Haze
Blue Iceberg
Carl BlueS
Serendipity v3.0
Carl Green
codeschmiede
Coffee Bar v1.1
Coffee Cup
Costas Nature Theme v0.5
Serendipity v2.3
RTL-Languages v0.3
Earphone
Elitist Latte
Gila Two
Green Mile 1.1
Joshua
Joshua Nino 1.1
Kamouflage v.1.1
MT-Clean
MT-Georgia Blue
MT-Gettys Burg
MT-Plain Jane
MT-Rusty
MT-Trendy
(bei MT3 passt der Titel nicht, das Bild schon)
Newspaper Blog
Party Brown
Powered
BlueGrey
s9thin
safety yellow
slate grey
Tool Box

[yellowled]

Mache ich etwas falsch oder funktionieren die meisten Styles mit einem Zufallsbild aus einer Menalto-Gallery2 in der Seitenliste nicht?

Soweit ich das so (anhand des Blogs und seines Output-Codes) sehen kann, machst Du nichts falsch. Das »Problem« ist schlicht, dass die wenigsten Templates/Styles das besagte Plugin direkt unterstützen dürften, insofern ist es mehr oder weniger Zufall, dass es bei den erwähnten Styles funktioniert.

Hat z.B. ein Template eine Seitenleiste mit fester Breite, sagen wir mal 200 Pixel, und das betreffende Gallery-Bild ist breiter, sagen wir mal 350 Pixel, dann überlagert das Bild eben ggf. den Inhalt oder bricht nach rechts aus der Seitenleiste aus.

Eine - meiner Meinung nach - »vernünftige« Idee wäre es, das Ganze so einzurichten, dass in der Seitenleiste lediglich Thumbnails angezeigt werden. Da ich aber das besagte Plugin nicht kenne, kann ich nicht viel mehr als das dazu sagen

YL

[hackerart]

Vielen Dank, dann sollte ich das vielleicht mal im englischen Teil posten. Ich würde es auch gut finden, wenn man fremde Bilder aus einer Gallery vorher verkleinern könnte. Für Importe in das Blog gibt es ja die Möglicheit mit convert entsprechende Vorgaben zu machen. Andererseits stelle ich mir das gar nicht so einfach vor. Nehmen wir an eine Gallery hat tausende Bilder, dann macht es vermutlich nicht viel Sinn, alle zufällig angezeigten Bilder zu verkleinern und lokal zu speichern. Vermutlich kommt es aber auch zu einem Performance-Problem, wenn man die Bilder "on-the-fly" verkleinert.

[yellowled]

Entscheidender wäre allerdings meiner Meinung nach, das Plugin ggf. so hinzubiegen, dass die Bilder »vernünftig« eingebunden werden, als einen passenden Style zu suchen (Also ggf. nochmal im Plugins-Forum fragen.)

YL

[hackerart]

Gibt es irgendwo eine Anleitung wie man ein eigenes "Style" baut. Ich finde da noch nicht so recht den Einstieg. Als Basis möchte ich ein vorhandenes Style nehmen und dann alles abändern, das ich anders haben möchte.

Wie wird das dann installiert? Die Rechte werden ja auf nobody geändert.

[yellowled]

Gibt es irgendwo eine Anleitung wie man ein eigenes "Style" baut. Ich finde da noch nicht so recht den Einstieg.

So langsam habe ich den Eindruck, die Dokumentation zu Serendipity ist "verlegt wie bei Suhrkamp - unauffindbar" (W. Neuss) ... die Fragen danach häufen sich irgendwie. Spezielles zu Styles findet sich unter http://www.s9y.org/40.html, speziell http://www.s9y.org/44.html.

Gewisse Grundkenntnisse in HTML und CSS sollte man haben, spezielle Dinge erfordern allerdings auch Smarty.

Als Basis möchte ich ein vorhandenes Style nehmen und dann alles abändern, das ich anders haben möchte.

Das ist generell ein guter Ansatz zum Einstieg.

Wie wird das dann installiert? Die Rechte werden ja auf nobody geändert.

Hö? Man suche sich ein Template als Basis aus, erzeuge im Ordner templates der Serendipity-Installation einen neuen Unterordner, beispielsweise "meintemplate", lade dorthin per ftp oder wie auch immer die Dateien aus dem Template-Verzeichnis des Basis-Styles hoch und bearbeite dann die. Ein Rechtproblem sehe ich da irgendwie nicht, man nehme mir ggf. bitte die Tomaten von den Augen ...

YL

[hackerart]

Ooops, da gibt es ja doch etwas auf Deutsch: http://www.s9y.org/80.html

Ich wollte es einfach mal so wie in Gallery machen, ein Motiv nehmen und abändern und da scheiterte ich dann bei den Rechten, da mein User logischerweise nicht der Gruppe nobody angehört.

zB
carl_green]# ls -l
total 60
-rw-r--r-- 1 nobody nobody 8461 Dec 4 06:47 entries.tpl
drwxr-xr-x 2 nobody nobody 4096 Dec 4 06:47 img/
-rw-r--r-- 1 nobody nobody 2137 Dec 4 06:47 index.tpl
-rw-r--r-- 1 nobody nobody 77 Dec 4 06:47 info.txt
-rw-r--r-- 1 nobody nobody 1792 Dec 4 06:47 plugin_calendar.tpl
-rw-r--r-- 1 nobody nobody 10425 Dec 4 06:47 preview.png
-rw-r--r-- 1 nobody nobody 395 Dec 4 06:47 sidebar.tpl
-rw-r--r-- 1 nobody nobody 7722 Dec 4 06:47 style.css

[garvinhicking]

Hi!

Die permissions von spartacus-dateien kann man im spartacus plugin umändern, so dass neue themes die runtergeladen werden z.B. alle auf 777 stehen.

Für bestehende Dateien guck dir mal das fixperm.php script an was Du in der s9y.org FAQ findest, damit kannst du die Rechte korrigieren.

Grüße,
Garvin

[hackerart]

Macht es Sinn auch den owner zu definieren, wenn die Rechte auf 777 gesetzt sind?

[hackerart]

Die permissions von spartacus-dateien kann man im spartacus plugin umändern, so dass neue themes die runtergeladen werden z.B. alle auf 777 stehen.

Ich hatte carl_green schon in Verwendung und um obiges auszuprobieren habe ich templates/carl_green gelöscht. Bei Spartacus wurden die Rechte geändert. Nach einer Neuinstallation von carl_green sind die Rechte wieder auf nobody. Per ssh und ls sollte es auch kein Cache-Problem sein.

Zum Löschen des Verzeichnisses habe ich cleanup.php von Gallery verwendet, aber das sollte doch ega sein.

Code: Select all

<?php
/*
 * Gallery - a web based photo album viewer and editor
 * Copyright (C) 2000-2006 Bharat Mediratta
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 2 of the License, or (at
 * your option) any later version.
 *
 * This program is distributed in the hope that it will be useful, but
 * WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
 * General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program; if not, write to the Free Software
 * Foundation, Inc., 51 Franklin Street - Fifth Floor, Boston, MA  02110-1301, USA.
 */

/*
 * Last updated 3/24/2006 to fix a bug with the way that we do directory
 * processing that would cause it to miss locks subdirectories.  Restructured
 * the file at that time and made it with with register_globals off and long
 * php tags.
 */
$version = "1.1";

$dir = '';
if (isset($_REQUEST['dir'])) {
    $dir = $_REQUEST['dir'];
}

welcomeMessage($dir);
if (isset($_REQUEST['dir'])) {
    echo "<hr>";
    fix($_REQUEST['dir']);
}

function fix($obj) {
    if (is_dir($obj)) {
	status("Directory", $obj);
	if ($fd = opendir($obj)) {
	    while (($child = readdir($fd)) !== false) {
		if ($child == '.' || $child == '..') {
		    continue;
		}

		$fullpath = "$obj/$child";
		fix($fullpath);
	    }
	    closedir($fd);
	    if (!@chmod($obj, 0777)) {
		error("Can't fix", $obj);
	    }
	} else {
	    error("Error reading dir", $obj);
	}
    } else if (is_file($obj)) {
	print "File: <b>$obj</b><br>";
	chmod($obj, 0666);
    }
}

function status($msg, $obj) {
    print "$msg: <b>$obj</b><br>";
}

function error($msg, $obj) {
    print "<font color=red>$msg: <b>$obj</b></font><br>";
}


function welcomeMessage($dir) {
?>
<font size=+2>
Gallery Cleanup Script
</font>
<p>
Because Gallery runs as part of the webserver, any files it creates
are owned by the webserver process.  If you want to modify those
files yourself, you need to get the webserver to change the permissions
on them so that you have access.  That's what this script is for.
Simply enter the path to your albums directory below and this script
will make every file in that path (that it can access) writable
by everybody.  Then, you can do whatever you want to the files.
</p>

<p>
Path (on your filesystem) to a file or directory to fix?
<br/>
<font size=-1>(examples: /home/~you/public_html/albums, /var/g2data)</font>
<br/>
</p>
<form>
<input name="dir" value="<?php print $dir ?>"/>
<input type=submit value="Go!"/>
</form>
<?php
}
?>

[garvinhicking]

Hi!

Kannst Du das nochmal genau beschrieben? Ich bin jetzt etwas verwirrt und weiß nicht ganz was Du meinst?

Du hast carl_green komplett via FTP gelöscht und dann via spartacus ncohmal runtergeladen, und dann waren die Rechte erst auf 777 aber dann nicht mehr?!

Grüße,
Garvin

[hackerart]

Zuerst habe ich die Rechte mit dem erwähnten Script geändert, d.h. das Script auf den Webspace kopiert und dann die url aufgerufen und den Pfad von carl_green angegeben. Als nächsten Schritt habe ich via Shell-Zugang mit rm carl_green gelöscht. Ich habe auch geprüft, ob carl_green wirklich gelöscht wurde.

Weiters wurden in der s9y-Administration die Rechte bei Spartacaus bei Permissions downloaded files auf 777 und bei Permissions downloaded directories auf 0777 gesetzt.

Nachdem carl_green ja nicht mehr vorhanden war, konnte ich es unter Styles verwalten neu herunterladen. Danach war der Owner wieder auf nobody.

Eben merke ich, dass sich da s9y richtig verhalten hat. Der Owner ist zwar wieder nobody, aber die Rechte sind
rwxrwxrwx nobody nobody

Ich hatte ja auch keinen Owner angegeben. Mit diesen Rechten kann ich die Files ja nun verändern. Macht es Sinn nicht nobody zu verwenden und einen User anzugeben.

[garvinhicking]

Hi!

Wenn die rechte 777 sind, ist ein ownerwechsel eher makulator und überflüssig. Auch klappt er auf vielen webserver nicht, weshalb 777 meist die einfachere wahl ist.

Grüße,
Garvin