Loading...
 
Deutsch

Deutsch


Probleme Bilder auf Wiki-Seiten darzustellen

posts: 11

Hallo Forum, ich habe folgendes Problem:

Bisher ist es mir nicht möglich einfach Bilder auf Wiki-Seiten darzustellen. Wenn man Bilder in ein Dateiarchiv hochlädt, sollte die Tiki-SW eigentlich von selber feststellen, um welchen Dateityp es sich handelt (jpg/gif/png...) und in der "tiki_datenbank" in der Tabelle "tiki_files" als Information in der Spalte "filetype" hinterlegen. Dies funktioniert leider nicht. Es wird bei jeder Datei "application/octet-stream" eingetragen.

Wenn man die Information manuell einträgt (z.B. "image/jpg" für ein JPEG-Bild), dann kann man zumindest auf einer Wiki-Seite dieses Bild via ID verknüpfen.
Das Bild wird dann ohne Probleme angezeigt.

Sobald man aber jetzt Optionen auf das darzustellende Bild benutzen möchte, wie z.B. eine andere Darstellungsauflösung dann "stürzt die Wiki-Seite ab" und zeigt nur noch eine weiße Seite an.

Also 2 Probleme:

1. Die Informationen über den Dateityp werden nicht richtig in die Datenbank eingetragen

2. Wenn man Anzeigeoptionen auf Bilder ausführen möchte stürzt die Wikiseite ab.

Habe auch vor ein paar Monaten HIER schonmal einen ähnlichen Forumbeitrag erstellt, darauf aber leider noch keine Antwort bekommen.

Vielleicht kann mir jetzt jemand bei diesen schwerliegenden Problem helfen, da ein Wiki ohne Bilddarstellungsoption eher Kontraproduktiv ist.

Vielen Dank.

Gruß, coligschlaeger

posts: 1563 Germany

Hi coligschlaeger,

das was Du erzählst klingt sehr seltsam.

Man möchte sich die website direkt mal anschauen, wobei ich die Tage kaum Zeit habe. Wäre es prinzipiell denkbar mal einen Blick darauf zu werfen? Ich meine hinter die Kulissen?

Ansonsten: Welche Tiversion, wie nutzt Du die Site etc. ... gib bitte mal ein paar Hintergrundinfos.

Hab auch den anderen Beitrag gelesen ... seltsam.

hmmm
Mal so gesehn wegen dem Bilderoptionenweisseseiteproblem:

a) welche Version, b) wieviel Memory Limit?

=> Je höher die Tiki Version, desto höher sollte der Memory Limit sein -> bei einem Tiki6 mindestens 64MB und bei einem Tiki9 mindestens 128 MB.

Ist der Memory Limit zu klein, kann es hie und da zu Blank Pages kommen.

Seltsam trotzdem.
Meld Dich
Torsten

posts: 11

Hallo Torsten und alle Mitlesenden.

Schonmal Danke für deine Antwort.

a) welche Version:

Tiki-Version: 8.3 (MyISAM)
PHP-Version: 5.3.10

Als Apache/PHP-SW benutzen wir AMPPS in der Version 1.6.
DatenBank ist MySQL.

b) wieviel Memory Limit

Bei AMPPS gibt es zwei php.ini:

  • C:\Programme\Ampps\apache\php.ini
  • C:\Programme\Ampps\php\php.ini


In beiden Dateien ist "memory_limit = 128M" eingetragen.


Ich würde dir gerne das Problem "Live" zeigen, aber wir benutzen die Tiki-SW als internes Firmen-Wiki. Ein Zugang ist also nicht möglich. Ich hoffe aber das wir das irgendwie auf dem "manuellen" Weg gelöst bekommen.

Noch als Randinfo: Die Blank Pages habe ich auch meißtens bei der Tiki-Suche.

Gruß, coligschlaeger


posts: 11

Hallo Forum, hallo Torsten.
Mittlerweile ist unser Wiki-System von einem Windows-Server auf einen Linux-Server umgezogen.

Ich habe mich nochmal mit einem Admin aus unserer Firma dem Problem gewidmet...

Wenn wir im Dateiarchiv ein Bild hochladen, die Information über das Bild also in der Datenbank in der Tabelle "tiki_files" gespeichert wird, wird der mime-type des Bildes nicht richtig erkannt.
Man kann nun den mime-type manuell eintragen und das Bild so auf einer Wiki-Seite darstellen.

Wenn wir ein Bild als Seitenanhang hochladen, die Infos also in der Datenbank-Tabelle "tiki_wiki_attachments" gespeichert wird, wird der mime-type richtig erkannt.
Das Bild kann nun auf der Wiki-Seite dargestellt und sogar Darstellungsoptionen darauf angewendet werden.

Unser Admin vemutet, dass für die Erkennung der mime-types zwei verschiedene php- oder javaskript-Module zuständig sind und unterschiedlich programmiert wurden. Wir konnten keine php-Datei rausfinden, in der der mime-type erkannt wird.

Hilft das vielleicht weiter?

posts: 1563 Germany

Hi coligschlaeger,

da hört sich wie ein fundierter Hinweis an.
Für mich als Nichtcoder ist es noch etwas wenig für das Gesamtbild, aber ich schon zu verstehen, in welche Richtung Dein Admin denkt.

Mich wundert ein weig, dass dieses Problem anscheinend nicht sehr verbreitet ist Das weist zunächst - unabhängig von der möglichen Doppelcodeproblematik - eher auf eine Servereinstellung hin.
Andererseits besteht das Problem offensichtlich auch beio eienm Umzug auf eine völlig andere Serverarchitektur.

Vielleicht kann man ja eine etwas dezidiertere bulletpointartige Problembeschreibung aus den Posts exzerpieren und das nochmal bei den Codern vorbringen.

Für mich bitte frage Deinen Admin, wo und wie er die Codedopplung lokalisiert hat?



Zum Speicherort: Es ist NICHT zu raten Dateien in der Datenbank zu speichern!
Du solltest auch NICHT die Dateien in einem Verzeichnis im Tikiroot speichern,
sondern ein Verzeichnis mit Unterverzeichnissen ausserhalb (neben) dem Tikiroot (Tiki-Installationsverzeichnis) verwenden.

Beispiel:

mytkisite.com
mytikisite.com/tikiroot
mytikisite.com/files
mytikisite.com/files/archiv
mytikisite.com/files/wiki
mytikisite.com/files/tracker
mytikisite.com/files/forum
mytikisite.com/files/poscasts
mytikisite.com/files/batchupload

Im Tiki Adminbereich (tiki-admin.php?page=fgal etc.) musst Du nun zu den jeweiligen Funktionen den jeweiligen Pfad zu den Verzeichnissen angeben.

Beim Beispiel fgal (filegallery / Dateiarchiv) wäre das hier so einzugeben:

../files/archiv

das batchuploadverzeichnis hat den Pfad:

../files/batchupload

Beachte: bei Linux/Unix heißt "zwei Punkte Slash" eine Verzeichnisebene höher gehen. Von da aus geht der Pfad normal wieder runter.
Es wäre also auch möglich ../../../irgend/ein/anderer/pfad was aber wohl keinen Sinn macht ;-)

Warum das:

Speichern in der Datenbank macht Dir bals Probleme bei Dumps, bei Upgrades, bei vielen und großen Dateien ... das gibt es nur, damit Einsteiger schnell strarten können und weil eine Software das wohl können muss. Mancher braucht es wohl, wenn es sich im Einzelfall nicht vermeiden lässt

Speichern im Tikiroot Verzeichnis ist ein Sicherheitsrisiko, weil Du Deien Dateien per Domain erreichbar machst und es ist ein Risiko Dateien bei Upgrades zu vergessen / zu verlieren, bzw. machtes mehr Arbeit bei Upgrades.

Gruß
Torsten

posts: 1

Hallo,

ich bin der Admin von coligschlaeger.

Ich komme zu dem beschriebenen Schluss, da in der Datenbanktabelle "tiki_files" immer der MIME-Type "application/octet-stream" generiert wird (=> hochgeladen im Dateiarchiv).

Lädt man eine Datei als Anhang einer Wiki-Seite hoch, wird der MIME-Type richtig generiert - in unserem Fall "image/png". Dann funktioniert die Größenänderung. Der Eintrag wird dann auch in der Tabelle "tiki_wiki_attachments" gemacht und nicht in der Tabelle "tiki_files".

Ändert man den MIME-Type in der Tabelle "tiki_files" dann auch zu "image/png" funktioniert die Größenänderung auch dort wunderbar.

Irgendwo müsste ja nach meinem Verständnis der Code für den Datenbankeintrag doppelt liegen, bzw. abgeändert liegen, da in 2 verschiedenen Tabellen gespeichert wird. Das Auslesen des MIME-Typs ist an der Stelle evtl. fehlerhaft, wo der Eintrag in die Tabelle "tiki_files" gemacht wird.

Ich kann natürlich auch nicht ausschließen, dass es etwas mit dem Umzug zu tun hat, aber im Moment hätte ich keine Idee, wo ich dort suchen müsste.

Zum Speicherort: Im Moment liegen die Dateien im ROOT-Verzeichniss des Servers und natürlich nicht in der Datenbank - dort ist nur der Verweis zur Datei hinterlegt. Die Problematik Dateien in einer Datenbank zu speichern sind mir bewusst:

mytikisite.com/tiki-index.php
mytikisite.com/Wikidateien

Ein Sicherheitsrisiko würde es nur darstellen, wenn wir ein Upgrade des Tikis fahren würden, da das Tiki nur intern benutzt wird.

MfG

posts: 1563 Germany

Hi der_admin,

ich denke, das hab ich verstanden ;-)

Ich schau mal, was ich rausfinden kann.