Speeddial nachbauen, Datenbankfelder und Tabreihenfolge

[Malcolm Beck´s]

مرحبا

ich nutze schon seit ewigkeiten Tools wie Speed Dial, oder Foxtab. Allerdings  sind nach fast jedem Grossen Update beide Tools eine weile unbrauchbar, warum auch immer. Die gesetzten Tabs exportieren ist die reinste zumutung (von Foxtab zu Speed Dial z. B.). Aus diesem Grunde möchte ich mir ein kleines Online-Speeddial nachbauen.

Jetzt habe ich Schwierigkeiten mit der Reihenfolge der einzelnen Tabs (Links) einer Gruppe. Ursprünglich wollte ich die Tabreihenfolge direkt im Feld für die Links speichern. Allerdings soll die Reihenfolge der Tabs per Drag and Drop änderbar werden. Dann müsste ich aber die Nummerierung jeder Gruppe komplett ändern, wenn ich einen Tab per Drag and Drop verschiebe. Wie könnte ich die Reihenfolge der Tabs  speichern? Javascript ist vorausgesetzt, ohne braucht es nicht funktionieren.

Mein Aktuelles Modell:

CREATE TABLE IF NOT EXISTS `tabs` (  
  `id` int(3) unsigned NOT NULL AUTO_INCREMENT,  
  `link` varchar(250) NOT NULL,  
  `title` varchar(150) NOT NULL,  
  `description` longtext NOT NULL,  
  `grouid` int(5) NOT NULL,  
  `tabposition` int(3) NOT NULL,  
  PRIMARY KEY (`id`)  
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;  
  
CREATE TABLE IF NOT EXISTS `groups` (  
  `id` int(3) unsigned NOT NULL AUTO_INCREMENT,  
  `groupid` int(5) NOT NULL,  
  `groupname` varchar(80) NOT NULL,  
  PRIMARY KEY (`id`)  
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

Nur tabposition gefällt mir nicht wirklich. Wie würdet Ihr das angehen?

mfg

[dedlfix]

Tach!

Jetzt habe ich Schwierigkeiten mit der Reihenfolge der einzelnen Tabs (Links) einer Gruppe. Ursprünglich wollte ich die Tabreihenfolge direkt im Feld für die Links speichern. Allerdings soll die Reihenfolge der Tabs per Drag and Drop änderbar werden. Dann müsste ich aber die Nummerierung jeder Gruppe komplett ändern, wenn ich einen Tab per Drag and Drop verschiebe.

Ja, zumindest wenn du bei Integer bleibst. Bei Fließkommazahlen kannst du ausreichend viele Werte zwischenschieben.

id int(3) unsigned NOT NULL AUTO_INCREMENT,
  grouid int(5) NOT NULL,
  tabposition int(3) NOT NULL,

Eine Längenangabe bei Integer ist ohne Nutzwert. Zahlenwerte (außer Decimal/Numeric) belegen immer dieselbe Anzahl an Bytes. Die Längenangabe hat nur einen Einfluss auf die Anzeigebreite auf der Kommandozeile - und die wirst du nicht nutzen.

dedlfix.

[Malcolm Beck´s]

مرحبا

Ja, zumindest wenn du bei Integer bleibst. Bei Fließkommazahlen kannst du ausreichend viele Werte zwischenschieben.

Stimmt, so könnte ich es auch angehen. Wobei ich mittlerweile mit dem Gedanken spiele, doch alle Einträge auf einen Rutsch zu aktualisieren. Wäre ja nicht einmal viel, ich habe in einer Gruppe max. 20-25 Links. Sobald was per drag and drop verschoben wird, lasse ich mir mit Javascript ein Array der Aktuellen Tabs mit entsprechender Reihenfolge zurückgeben, und kann dann dieses Array durch PHP jagen, und so alles nacheinander speichern. Das hin und her verschieben kommt ohnehin sehr Selten vor.

Wobei deine Idee auch gerade fruchtet.

id int(3) unsigned NOT NULL AUTO_INCREMENT,
  grouid int(5) NOT NULL,
  tabposition int(3) NOT NULL,

Eine Längenangabe bei Integer ist ohne Nutzwert.

Ich dachte immer, dass ist zwingend? Ich hab's gerade mal ohne ausprobiert, dass macht „MySQL 5.5.27“ ohne Längenangabe (Export von phpmyadmin):

CREATE TABLE IF NOT EXISTS `groups` (  
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,  
  `groupid` int(11) NOT NULL,  
  `groupname` varchar(80) COLLATE utf8_unicode_ci NOT NULL,  
  PRIMARY KEY (`id`)  
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci AUTO_INCREMENT=1 ;

Mit Varchar macht es soweit ich weiss Sinn, die Zeichen zu begrenzen. Ist das bei int nicht der Fall?

mfg

[dedlfix]

Tach!

Mit Varchar macht es soweit ich weiss Sinn, die Zeichen zu begrenzen. Ist das bei int nicht der Fall?

Bei Varchar geht es auch syntaktisch nicht ohne, denn da legt die Anzahl ebenfalls die maximale Speichergröße fest. Aber Zahlen, wie gesagt, belegen immer denselben Platz, weil sie in dem üblichen Format abgelegt werden. Deshalb haben sie auch so krumme Grenzwerte. Nur Decimal/Numeric richtet sich nach der Anzahl der Ziffern. Bei Int könntest du lediglich auf die kleinen Geschwister SmallInt und TinyInt ausweichen, aber so viel bringt das bei deiner geringen Datenmenge auch nicht, zumal PHP wieder mit vollen 32/64 Bit arbeitet.

dedlfix.

[Malcolm Beck´s]

مرحبا

Aber Zahlen, wie gesagt, belegen immer denselben Platz, weil sie in dem üblichen Format abgelegt werden.

Danke für die Erklärung. Wobei sich mir die Frage stellt, in Zukunft die Längenangabe trotzdem mit anzugeben, da MySQL das ja ohnehin macht? Spätestens wenn ich etwas exportiere, sind sie wieder da.

Eine Folgefrage zu Verzeichnissen und Datenbanken hat sich ergeben.

Wenn in einem Ordner 10.000 Bilder liegen, dauert der Zugriff über die URI eines Bildes länger, weil der Ordner trotz der URI „durchsucht“ werden muss, und sehr viele Dateien drin liegen? Das gleiche frage ich mich gerade für Datenbanken? Nehmen wir an, ich habe ein Feld mit 100.000 Einträgen. Wenn ich jetzt die ID eines Eintrages habe und aufrufe, spielt es da eine Rolle, wie viele Daten in diesem Feld stehen? Wenn ich nach der ID suchen würde, Sicherlich, aber wenn ich die ID bereits habe?

mfg

[Der Martin]

Hallo,

Eine Folgefrage zu Verzeichnissen und Datenbanken hat sich ergeben.

und die finde ich gar nicht uninteressant.

Wenn in einem Ordner 10.000 Bilder liegen, dauert der Zugriff über die URI eines Bildes länger, weil der Ordner trotz der URI „durchsucht“ werden muss, und sehr viele Dateien drin liegen?

Ja. Und wie effizient diese Suche ist, hängt vom Datesystem an sich ab. Nehmen wir FAT als sehr einfaches Beispiel, egal ob in der Geschmacksrichtung FAT12, FAT16 oder FAT32 - sie funktionieren im Grunde alle gleich.
Ein Verzeichnis in FAT (und AFAIK auch in NTFS) ist einfach nur ein lange lineare Liste von Dateinamen und ihren zugehörigen Metainformationen wie Dateigröße, Timestamps und Attribute. Die Einträge sind weder sortiert[1] noch indiziert, das OS hat keine Optimierungsmöglichkeit beim Auffinden eines bestimmten Eintrags. Der Zugriff auf eine bestimmte Datei erfordert daher eine sture lineare Suche und für jeden Eintrag einen Stringvergleich[2]. Je mehr Dateien in einem Verzeichnis liegen, desto länger dauert also schon das Finden der Datei.

Natürlich sind effizientere Organisationen denkbar, und ich meine gelesen zu haben, dass einige Linux-Datesysteme eine Art Baumstruktur verwenden und so die Zahl der Vergleiche auch bei umfangreichen Verzeichnissen sehr gering bleibt.

Das gleiche frage ich mich gerade für Datenbanken? Nehmen wir an, ich habe ein Feld mit 100.000 Einträgen.

Du meinst eine _Tabelle_ mit 1000000 Einträgen (Datensätzen)?

Wenn ich jetzt die ID eines Eintrages habe und aufrufe, spielt es da eine Rolle, wie viele Daten in diesem Feld stehen? Wenn ich nach der ID suchen würde, Sicherlich, aber wenn ich die ID bereits habe?

Auch das kommt wieder auf die Organisation der Tabelle an. Wenn die Spalte mit der ID als sortierrelevanter Schlüssel festgelegt ist, existiert ein Index, mit dessen Hilfe das DBMS den gesuchten Eintrag mit wenigen Zugriffen auffinden kann. Andernfalls wird auch hier eine lineare Suche erforderlich.

Ciao,
 Martin

[1] Alle mir bekannten Dateimanager unter Windows zeigen Verzeichnisinhalte immer nach einem bestimmten Merkmal sortiert an, nicht in der Reihenfolge, wie sie physikalisch vorliegen. Das suggeriert, dass sie sortiert gespeichert sind - ein Trugschluss. Ein "dir" an der Kommandozeile zeigt normalerweise die tatsächliche, unsortierte Reihenfolge.
[2] Genaugenommen zwei Stringvergleiche, weil der Kompatibilität zuliebe meistens noch die gekürzten 8.3-Namen mitgeschleppt werden und eine Datei so unter zwei verschiedenen Namen gefunden werden kann.

[Malcolm Beck´s]

مرحبا

Je mehr Dateien in einem Verzeichnis liegen, desto länger dauert also schon das Finden der Datei.

Ok, dann verteile ich es einfach auf Unterordner. 100 Thumbs pro Ordner sollte doch kein Problem darstellen?

Du meinst eine _Tabelle_ mit 1000000 Einträgen (Datensätzen)?

Ja, ich meine eine Tabelle. Manchmal hakt's mit meinem Fachchinesisch ;)

Auch das kommt wieder auf die Organisation der Tabelle an. Wenn die Spalte mit der ID als sortierrelevanter Schlüssel festgelegt ist, existiert ein Index, mit dessen Hilfe das DBMS den gesuchten Eintrag mit wenigen Zugriffen auffinden kann. Andernfalls wird auch hier eine lineare Suche erforderlich.

Ich werde wohl eine separate Tabelle für jeden User anlegen, wo die Tabs gespeichert sind. Das wäre wohl die einfachste Möglichkeit? Mein derzeitiges Modell sieht so aus:

-- Tabellenstruktur für Tabelle `tablink`  
  
CREATE TABLE `tablink` (  
  `id` int unsigned NOT NULL auto_increment,  
  `userid` int NOT NULL,  
  `groupid` int NOT NULL,  
  `position` int NOT NULL,  
  `link` varchar(250) collate utf8_unicode_ci NOT NULL,  
  `title` varchar(150) collate utf8_unicode_ci NOT NULL,  
  `imgsrc` varchar(250) collate utf8_unicode_ci NOT NULL,  
  PRIMARY KEY  (`id`)  
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci AUTO_INCREMENT=9 ;  
  
-- Daten für Tabelle `tablink`  
  
INSERT INTO `tablink` (`userid`, `groupid`, `position`, `link`, `title`, `imgsrc`) VALUES  
(1, 1, 1, 'http://example.com/?p1&t=article', 'Example', 'qdaspojboujzmchqnepnirvutzhfvwyrdkwglaecgxtxflysibkm.jpg'),  
(1, 1, 2, 'http://google.com/', 'Google', 'gflrvtztdybwafihkxojpoxscmwzebsaicrgvuplqeundhnmqkjy.jpg')  
-- ...  
;

Erster Entwurf

Und dann wollte ich nach „User“, und anschliessend nach Gruppen aussortieren. Das dürfte aber dann wohl problematisch werden, wenn ich Daten von 100.000 Usern in dieser einen Tabelle hätte? Das liest sich schon so.

mfg

[Der Martin]

Hi,

Je mehr Dateien in einem Verzeichnis liegen, desto länger dauert also schon das Finden der Datei.
Ok, dann verteile ich es einfach auf Unterordner. 100 Thumbs pro Ordner sollte doch kein Problem darstellen?

normalerweise nicht. Auch rund 1000 sind erfahrungsgemäß noch okay, aber da würde ich dann irgendwann einbremsen.

Auch das kommt wieder auf die Organisation der Tabelle an. Wenn die Spalte mit der ID als sortierrelevanter Schlüssel festgelegt ist, existiert ein Index, mit dessen Hilfe das DBMS den gesuchten Eintrag mit wenigen Zugriffen auffinden kann. Andernfalls wird auch hier eine lineare Suche erforderlich.
Ich werde wohl eine separate Tabelle für jeden User anlegen, wo die Tabs gespeichert sind. Das wäre wohl die einfachste Möglichkeit?

Das würde dann auf mehrere Tabellen mit derselben Struktur hinauslaufen. Schlechtes Datenmodell. Gleichartige Daten gehören normalerweise in *einer* Tabelle gespeichert.

-- Tabellenstruktur für Tabelle tablink

CREATE TABLE tablink (
  id int unsigned NOT NULL auto_increment,
  userid int NOT NULL,
  groupid int NOT NULL,
  position int NOT NULL,
  link varchar(250) collate utf8_unicode_ci NOT NULL,
  title varchar(150) collate utf8_unicode_ci NOT NULL,
  imgsrc varchar(250) collate utf8_unicode_ci NOT NULL,
  PRIMARY KEY  (id)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci AUTO_INCREMENT=9 ;

  
Welche Daten sind im Normalfall suchrelevant, nach welchen wird  üblicherweise abgefragt? \*Das\* solltest du dir überlegen und dann darauf den Index (Primary Key) legen, gern auch auf eine Kombination zweier Spalten. Ich könnte mir da userid+groupid vorstellen. Damit bekommst du zwar keine Eindeutigkeit, aber brauchst du die?  
Ist die "künstlich" produzierte id-Spalte für irgendwas relevant? Dient sie zum Referenzieren des Datensatzes in Kombination mit einer weiteren Tabelle? Wenn sie keinen konkreten Zweck hat, würde ich sie weglassen und userid+groupid zum Finden verwenden.  
  

> Und dann wollte ich nach „User“, und anschliessend nach Gruppen aussortieren.  
  
Sag ich's nicht ... ;-)  
  

> Das dürfte aber dann wohl problematisch werden, wenn ich Daten von 100.000 Usern in dieser einen Tabelle hätte? Das liest sich schon so.  
  
Nein. Klar, bei einer Datenhaltung in Textdateien oder CSV hätte ich da auch schon langsam Bauchweh. Aber unterschätze nicht die Leistungsfähigkeit von modernen Datenbanksystemen.  
  
So long,  
 Martin  

-- 
[Gott hilft niemandem](http://forum.de.selfhtml.org/?t=134084&m=869527), er erfreut sich nur an unseren Leiden.  
  (Ashura)  
Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(

[Malcolm Beck´s]

مرحبا

Das würde dann auf mehrere Tabellen mit derselben Struktur hinauslaufen. Schlechtes Datenmodell. Gleichartige Daten gehören normalerweise in *einer* Tabelle gespeichert.

Das habe ich bei Piwik gesehen. Piwik legt für jeden Monat im Jahr eine Tabelle an:
https://docs.google.com/file/d/0B36OJ6IwIXLvQ1VjWlFQcW12MGs/edit

Welche Daten sind im Normalfall suchrelevant, nach welchen wird  üblicherweise abgefragt? *Das* solltest du dir überlegen und dann darauf den Index (Primary Key) legen, gern auch auf eine Kombination zweier Spalten. Ich könnte mir da userid+groupid vorstellen.

Genau so  soll es sein. Nach einem Login werden alle Tabs des Users geladen, und je nach Gruppe angezeigt. Wobei ich noch nicht weiss, ob ich die Gruppen komplett mit Javascript anzeigen soll, ohne neuen Request (?group=1). Ich denke ja.

Ist die "künstlich" produzierte id-Spalte für irgendwas relevant?

Noch nicht. Ich weiss aber auch noch gar nicht so genau, welche Spalten ich brauche werde. Ich Modelliere erst seit Gestern.

Nein. Klar, bei einer Datenhaltung in Textdateien oder CSV hätte ich da auch schon langsam Bauchweh. Aber unterschätze nicht die Leistungsfähigkeit von modernen Datenbanksystemen.

Stimmt, ist auch einfacher für mich zu programmieren. Wenn's viele User werden, kaufe ich mir einfach ein Team Webworker :)

mfg

[Der Martin]

Hallo,

eine Sache beschäftigt mich schon eine Weile:

مرحبا

Könntest du das mal in lateinische Schrift transkribieren und übersetzen?
Ich kann diese Haken, Würmer und Ösen zwar als arabische Schrift erkennen, das war's dann aber auch schon.

Ciao,
 Martin

[dedlfix]

Tach!

eine Sache beschäftigt mich schon eine Weile:

مرحبا
Könntest du das mal in lateinische Schrift transkribieren und übersetzen?

Google Translate kann das problemlos. Transkribieren zar nicht, aber auch vorlesen.

dedlfix.

[Malcolm Beck´s]

مرحبا

eine Sache beschäftigt mich schon eine Weile:

مرحبا
Könntest du das mal in lateinische Schrift transkribieren und übersetzen?

Google Translate kann das problemlos. Transkribieren zar nicht, aber auch vorlesen.

Min. Transkription: „Merhaba“. Genauer kann ich es nicht transkribieren.

mfg

[Malcolm Beck´s]

مرحبا

مرحبا
Könntest du das mal in lateinische Schrift transkribieren und übersetzen?

http://en.wiktionary.org/wiki/merhaba. Sogar mit einem Hörbeispiel.

mfg

[Der Martin]

Hallo,

مرحبا
Könntest du das mal in lateinische Schrift transkribieren und übersetzen?
Min. Transkription: „Merhaba“. Genauer kann ich es nicht transkribieren.

das reicht mir aber schon, "merhaba" ist mir geläufig.

http://en.wiktionary.org/wiki/merhaba. Sogar mit einem Hörbeispiel.

Hörbeispiel? Kann ich auf die Schnelle nicht entdecken. Dafür aber die IPA-Lautschrift. Das ist mindestens genausogut.

Danke und tschüss,
 Martin

[Malcolm Beck´s]

مرحبا

http://en.wiktionary.org/wiki/merhaba. Sogar mit einem Hörbeispiel.

Hörbeispiel? Kann ich auf die Schnelle nicht entdecken.

http://en.wiktionary.org/wiki/merhaba#Turkish, unter „Pronunciation“. Vielleicht fehlt dir ein Plugin?

mfg

[Der Martin]

Hi,

http://en.wiktionary.org/wiki/merhaba. Sogar mit einem Hörbeispiel.
Hörbeispiel? Kann ich auf die Schnelle nicht entdecken.
http://en.wiktionary.org/wiki/merhaba#Turkish, unter „Pronunciation“. Vielleicht fehlt dir ein Plugin?

aah, jetzt seh ich's. Na, ist auch gut versteckt:

merhaba (file)

Die unauffällige Verlinkung des Wortes "file" auf eine Audio-Datei kann man schon mal übersehen.

Ciao,
 Martin

[Malcolm Beck´s]

مرحبا

merhaba (file)

Die unauffällige Verlinkung des Wortes "file" auf eine Audio-Datei kann man schon mal übersehen.

Mit dem richtigen Plugin wird dieser Link durch einen Player ersetzt. Ich surfe nur noch mit Chrome, der hat quasi alles OnBoard. Und den Screenshot habe ich innerhalb von Sekunden geschossen und verlinkt, Chrome sei es gedankt :)

mfg

[Der Martin]

Hallo,

merhaba (file)
Die unauffällige Verlinkung des Wortes "file" auf eine Audio-Datei kann man schon mal übersehen.
Mit dem richtigen Plugin wird dieser Link durch einen Player ersetzt.

ja, und jemand anders, der keinen Google-Account hat, wird über diesen Link einfach nur zu einer Login-Seite geschickt.

Ich surfe nur noch mit Chrome, der hat quasi alles OnBoard.

Das sei dir gegönnt; ich möchte genau das *nicht*. Ich möchte das Web so nüchtern wie nur möglich erleben. Textinhalte, Bilder, okay, aber alles weitere (Audio, Video) nur verlinkt, so dass ich es wahlweise entweder runterladen oder direkt online mit meinem bevorzugten Player abspielen kann.

Und den Screenshot habe ich innerhalb von Sekunden geschossen und verlinkt, Chrome sei es gedankt :)

Und für viele ist der Link nutzlos, wenn sie keinen Google-Account haben. :-)

Ciao,
 Martin

[Malcolm Beck´s]

مرحبا

Mit dem richtigen Plugin wird dieser Link durch einen Player ersetzt.

ja, und jemand anders, der keinen Google-Account hat, wird über diesen Link einfach nur zu einer Login-Seite geschickt.

Sorry, ich hatte 2 Screenshots geschossen und das falsche freigegeben, ist korrigiert. Ich muss mir angewöhnen, die Freigaben vorher erst zu checken.

Und für viele ist der Link nutzlos, wenn sie keinen Google-Account haben. :-)

In diesem Fall hätte nicht mal ein Account was genutzt, ich hatte vergessen, die Datei Freizugeben.

mfg

[Der Martin]

n'Abend,

Mit dem richtigen Plugin wird dieser Link durch einen Player ersetzt.
ja, und jemand anders, der keinen Google-Account hat, wird über diesen Link einfach nur zu einer Login-Seite geschickt.
Sorry, ich hatte 2 Screenshots geschossen und das falsche freigegeben, ist korrigiert. Ich muss mir angewöhnen, die Freigaben vorher erst zu checken.

hehehe. :-)
Aber mal ehrlich, wenn das ein Screenshot ist - wie kannst du mit einer so unscharfen Schriftdarstellung leben? Vermutlich irgendeine Art von Kantenglättung. Meine Herrn, meine Augen versuchen krampfhaft, das unscharfe Zeug scharf zu focussieren, natürlich erfolglos. Da würde ich in kürzester Zeit Kopfschmerzen kriegen.

Und für viele ist der Link nutzlos, wenn sie keinen Google-Account haben. :-)
In diesem Fall hätte nicht mal ein Account was genutzt, ich hatte vergessen, die Datei Freizugeben.

Okay. So sieht also der eingebettete Player aus. Hmm. Dann doch lieber ein einfacher Textlink, selbst auf die Gefahr hin, dass man ihn hin und wieder übersieht.

Ciao,
 Martin

[Malcolm Beck´s]

مرحبا

dieser Link durch einen Player ersetzt.
hehehe. :-)
Aber mal ehrlich, wenn das ein Screenshot ist - wie kannst du mit einer so unscharfen Schriftdarstellung leben?

Gar nicht, dass Bild wird von Google runterskaliert. Oben Links (Unter Bearbeiten) steht 100%, wenn du darauf klickst, siehst du die richtige Grösse.

mfg

[dedlfix]

Tach!

Gleichartige Daten gehören normalerweise in *einer* Tabelle gespeichert.
Das habe ich bei Piwik gesehen. Piwik legt für jeden Monat im Jahr eine Tabelle an:

Piwik ist in dem Fall nicht "normalerweise". Im Extremfall sammelt es sehr viele Datensätze und Auswertungen sind oftmals nur über bestimmte Zeiträume nötig. Alle Daten von Anno Filzlatsch mitzuschleppen macht sich irgendwann selbst bei gut gesetzten Indexen bemerkbar. Und dann käme es in Schwierigkeiten, den Ansatz "designed for speed" in der Praxis nachzuweisen.

"Piwik is fast up to at least 300,000 pages per day, and we know of several websites with 10 million pages and more using Piwik with great success."

Das sind schon Dimensionen, die da zusammenkommen können.

Ist die "künstlich" produzierte id-Spalte für irgendwas relevant?
Noch nicht. Ich weiss aber auch noch gar nicht so genau, welche Spalten ich brauche werde.

Als eindeutiger Anfasser ist sie oftmals sehr nützlich, auch wenn man denkt, sie ansonsten nicht zu benötigen. Piwik wird für die Massendaten-Tabellen allerdings darauf verzichten können, weil da eher in (Datums-)Bereichen operiert wird und keine einzelnen Datensätze angefasst werden.

dedlfix.

[Malcolm Beck´s]

مرحبا

Piwik ist in dem Fall nicht "normalerweise".

Das stimmt natürlich. Ich habe mir auch den Inhalt der Spalten angesehen, da leppert sich selbst bei kleinsten Seiten unmengen an Daten.

Als eindeutiger Anfasser ist sie oftmals sehr nützlich, auch wenn man denkt, sie ansonsten nicht zu benötigen. Piwik wird für die Massendaten-Tabellen allerdings darauf verzichten können, weil da eher in (Datums-)Bereichen operiert wird und keine einzelnen Datensätze angefasst werden.

Bei einigen Tabellen verzichte ich auch darauf, aber die besagte Spalte gehört zu den Hauptspalten, da habe ich immer mindestens den einen index gesetzt. User-ID und Group-ID sind oft gleich, daher könnte ich ohne diese ID keinen der Datensätze separat ansprechen. Von Möglichen Updates mal ganz abgesehen.

Danke euch beiden jedenfalls für die Hilfe, jetzt kann ich beruhigt weiter machen. Was aber nicht heisst, dass das Thema damit beendet ist. Neue Ideen sind immer willkommen.

mfg

[dedlfix]

Tach!

Ich werde wohl eine separate Tabelle für jeden User anlegen, wo die Tabs gespeichert sind. Das wäre wohl die einfachste Möglichkeit?
Das würde dann auf mehrere Tabellen mit derselben Struktur hinauslaufen. Schlechtes Datenmodell. Gleichartige Daten gehören normalerweise in *einer* Tabelle gespeichert.

Eben. Mehrere Tabellen zu pflegen ist aufwendiger und bei den drei Datensätzen des Anwendungsfalles spielt Performance so gut wie keine Rolle.

Welche Daten sind im Normalfall suchrelevant, nach welchen wird  üblicherweise abgefragt? *Das* solltest du dir überlegen und dann darauf den Index (Primary Key) legen, gern auch auf eine Kombination zweier Spalten. Ich könnte mir da userid+groupid vorstellen. Damit bekommst du zwar keine Eindeutigkeit, aber brauchst du die?

Ja, der Primärschlüssel muss eindeutig sein. Aber man kann ja beliebig weitere Indexe hinzufügen.

Das dürfte aber dann wohl problematisch werden, wenn ich Daten von 100.000 Usern in dieser einen Tabelle hätte? Das liest sich schon so.

100.000 sind immer noch in der Größenordnung von "die drei Datensätze".

dedlfix.

[Malcolm Beck´s]

مرحبا

Erster Entwurf

Und Thumbnails funktionieren jetzt auch. Oben Links auf „+“ klicken. Jetzt muss ich mir nur noch überlegen, wie ich was in der DB speichere. Die Reihenfolge der Tabs werde ich wohl über eine Seperate Funktion lösen.

mfg

[Malcolm Beck´s]

مرحبا

Aus diesem Grunde möchte ich mir ein kleines Online-Speeddial nachbauen.

Speedtab V 0.7.2343.2 Beta ist quasi Fertig ;)

Jetzt kann ich von vorn anfangen und alles aufräumen. Zumal da noch etliches fehlt, wie Gruppenverwaltung, ausgiebige Fehlermeldungen oder Tabs löschen. Könnt Ihr mal ein bisschen mit dem Login rumspielen, evtl. paar Links anlegen, ob da was unerwartetes passiert? Zum registrieren muss man lediglich irgendwas eingeben, es gibt derzeit keine Prüfungen, keine Emailbestätigung oder ähnliches. Ich nutze das Sessionbasierte Loginsystem, welches ich etwas erweitert habe.

Derzeit funktioniert es auch nur mit Chrome. Der Rest kommt noch.

mfg

[Malcolm Beck´s]

مرحبا

ich habe schon seit Ewigkeiten Probleme mit praktisch allen Domains, auf die ich Zugriff hab. Sämtliche Scripts hingen sich ohne ersichtlichen Grund auf. Das ist ärgerlich, vorallem, wenn man gerade etwas geschrieben hat und es speichern möchte. Ich konnte mir bis gerade eben kein Reim darauf machen. Jetzt gerade bin ich zufällig darüber gestolpert, dass die aufhänger erst eintreten, wenn ich eine eigene php.ini hochlade. Ist das im Prinzip möglich, dass sich Scripte wegen falscher Einstellungen in der php.ini aufhängen?

Grundsätzlich stand in meinen php.ini immer (mit ständigen aussetzern):

allow_url_fopen = ON  
allow_url_include = OFF  
magic_quotes_gpc = OFF  
magic_quotes_runtime = OFF  
register_globals = OFF  
register_long_arrays = OFF  
safe_mode = OFF  
short_open_tag = ON  
asp_tags = OFF  
max_execution_time = 50000  
memory_limit = 40M  
display_errors = ON  
expose_php = OFF  
arg_separator.output = "&"  
arg_separator.input = ";&"  
output_buffering = ON  
zlib.output_compression = ON  
default_charset = "UTF-8"  
upload_max_filesize = 64M  
post_max_size = 64M

Korrigiert, bislang ohne aussetzer

allow_url_fopen = OFF  
allow_url_include = OFF  
magic_quotes_gpc = OFF  
magic_quotes_runtime = OFF  
register_globals = OFF  
register_long_arrays = OFF  
safe_mode = OFF  
short_open_tag = ON  
asp_tags = OFF  
display_errors = ON  
expose_php = OFF  
arg_separator.output = "&"  
arg_separator.input = ";&"  
output_buffering = ON  
zlib.output_compression = ON  
default_charset = "UTF-8"

Ich vermute das Problem bei memory_limit, da man diese bei den Grossen hostern anscheinend nicht ändern darf.

mfg

[dedlfix]

Tach!

Ist das im Prinzip möglich, dass sich Scripte wegen falscher Einstellungen in der php.ini aufhängen?

Ausschließen will ich das nicht, aber ich hab das noch nicht erlebt. Aufhängen heißt aber, dass es unkontrolliert weiterläuft. Sich scheinbar grundlos zu beenden ist nicht aufhängen. Ein solches Beenden kann jedoch sehr wohl durch Konfigurationswerte beeinflusst werden.

Grundsätzlich stand in meinen php.ini immer (mit ständigen aussetzern):
[ code lang=php ]

Das ist kein PHP-Code sondern Ini-Format.

allow_url_fopen = ON
allow_url_fopen = OFF

Das auf off zu setzen, sollte nichts ändern. Alle anderen sind sicher auch nicht die Ursache. Ich würde aber mal das Error-Logging in eine Datei konfigurieren (und auch display_errors im Produktivsystem ausschalten).

[nicht mehr enthalten]
max_execution_time = 50000
memory_limit = 40M
upload_max_filesize = 64M
post_max_size = 64M

Ich vermute das Problem bei memory_limit, da man diese bei den Grossen hostern anscheinend nicht ändern darf.

Ich denke nicht, dass man alle "großen Hoster" über einen Kamm scheren sollte. Und das ist auch für konkrete Probleme mit einem bestimmten wenig hilfreich. Konkret hast du also 1&1, und da kenne ich es beim Webhosting so, dass der PHP-Prozess von außen überwacht und beim Überschreiten der Grenzwerte (Speicher/CPU-Zeit) gekillt wird, woraufhin man nicht mal was innerhalb PHPs merkt, also auch keine (konkreten) Logfile-Einträge.

Die Limits hast du also rausgenommen, so dass jede PHP-Instanz die kompletten zugestandenen Ressourcen nutzen kann - so sie über den Default-Werten liegen. Wenn die Limitierung aufgrund deiner php.ini-Werte die Ursache gewesen sein soll, hättest du Fehlermeldungen in PHPs eigenem Error-Logfile sehen können, wenn du eins angelegt hättest.

dedlfix.

[Malcolm Beck´s]

مرحبا

Ich würde aber mal das Error-Logging in eine Datei konfigurieren

Diese Diskussion hatten wir schon so oft, dank dir ;)

Ich denke nicht, dass man alle "großen Hoster" über einen Kamm scheren sollte.

Ich verwalte 2 Domains bei Strato und einige bei 1und1, und bei beiden kämpfe ich mit diesen Aussetzern. Es passiert ohne erkennbaren Grund, wenn ich z. B. auf einen Link klicke, lädt der Browser Minutenlang, statt die Seite zu öffnen. Jetzt habe ich auf der Testdomain die php.ini komplett rausgenommen, mal sehen, was sich tut. Ich bekomme auch von Zeit zu Zeit DNS-Fehlermeldungen von den Webmastertools, wenn eine Domain nicht erreichbar ist.

Wenn die Limitierung aufgrund deiner php.ini-Werte die Ursache gewesen sein soll, hättest du Fehlermeldungen in PHPs eigenem Error-Logfile sehen können, wenn du eins angelegt hättest.

Ich verstehe es mit dem Error log einfach nicht! Was ist an folgendem Konstrukt falsch?

  define('ErrorLogFile', 'error.log.inc.php');  
  /**  
   * @param $logerror: error_get_last()  
   */  
  function errorLogs ($logerror)  
  {  
    return error_log( date("d M Y H:i:s ") . is_array($logerror) ? sprintf("%s in %s on line %s\n"  
                                                                          , $logerror["message"]  
                                                                          , $logerror["file"]  
                                                                          , $logerror["line"]  
                                                                 : $logerror, 3, ErrorLogFile);  
  }  
  errorLogs (error_get_last());

Wenn ich das in eine meiner Lokalen CMS schreibe, wird zwar ein Fehler gespeichert, also geloggt, aber ohne Inhalt?

error.log.inc.php   (auch in den PHP Error Logs (xampp/php/logs) steht nichts weiter)
 in  on line
 in  on line

Wenn ich eine unbekannte Variable ausgeben will, läuft es richtig:
Undefined variable: abbsnsbd in D:\xampp\anonymous\sauna_as\index.php on line 222 1

Muss ich jetzt das Gesamte CMS umkrempeln, um den fehler zu finden?

mfg

[dedlfix]

Tach!

Ich würde aber mal das Error-Logging in eine Datei konfigurieren
Diese Diskussion hatten wir schon so oft, dank dir ;)

Nicht dass du was verwechselst. Schon oft hatten wir eigentlich nur das error_reporting aufzudrehen.

Wenn die Limitierung aufgrund deiner php.ini-Werte die Ursache gewesen sein soll, hättest du Fehlermeldungen in PHPs eigenem Error-Logfile sehen können, wenn du eins angelegt hättest.
Ich verstehe es mit dem Error log einfach nicht! Was ist an folgendem Konstrukt falsch?

An dem Konstrukt ist falsch, dass es PHP-Code ist. Ein PHP-Script kann aber nicht auch noch eine Fehlerbehandlung machen, wenn in ihm bereits ein nicht "catchable" fataler Fehler auftrat. Deswegen error_log und log_errors setzen - und das muss in die php.ini. Die Datei sollte natürlich außerhalb des DocumentRoots zu liegen kommen, und Schreibrechte darauf braucht PHP auch.

dedlfix.

[Malcolm Beck´s]

હેલો

An dem Konstrukt ist falsch, dass es PHP-Code ist. Ein PHP-Script kann aber nicht auch noch eine Fehlerbehandlung machen, wenn in ihm bereits ein nicht "catchable" fataler Fehler auftrat. Deswegen error_log und log_errors setzen - und das muss in die php.ini.

Ist gerade geschehen. Stimmt natürlich, soweit hatte ich gar nicht gedacht. Ich bin gespannt, was ich morgen alles berichtet bekomme.

Die Datei sollte natürlich außerhalb des DocumentRoots zu liegen kommen, und Schreibrechte darauf braucht PHP auch.

Ich kann's heute nicht mehr testen, aber geht das? Muss die php.ini nicht in jedes Verzeichnis, von wo aus ich die PHP-Scripte aufrufe? Oder stellt error_log eine Ausnahme dar?

બાય

[dedlfix]

Tach!

Die Datei sollte natürlich außerhalb des DocumentRoots zu liegen kommen, und Schreibrechte darauf braucht PHP auch.
Muss die php.ini nicht in jedes Verzeichnis, von wo aus ich die PHP-Scripte aufrufe? Oder stellt error_log eine Ausnahme dar?

Ja und jein. Das was da in error_log angegeben wird, kann überall liegen, solange der PHP-Prozess drauf schreiben kann. Der Ort der php.ini und der von dieser Datei haben keine Abhängigkeiten voneinander.

dedlfix.

[Malcolm Beck´s]

હેલો

Ja und jein. Das was da in error_log angegeben wird, kann überall liegen, solange der PHP-Prozess drauf schreiben kann. Der Ort der php.ini und der von dieser Datei haben keine Abhängigkeiten voneinander.

Also außerhalb der Doc Root funktioniert es bei mir nicht. Fehler werden nicht gespeichert.
Ich habe der php.ini, die außerhalb der Doc liegt folgendes hinzugefügt:

log_errors = On  
error_log = "/homepages/XX/XXXXXXXXXX/htdocs/new_cms/php_error_log.log"  
;error_log = "./homepages/XX/XXXXXXXXXX/htdocs/new_cms/php_error_log.log"

Eine „php_error_log.log“ liegt in beiden Verzeichnissen, ausserhalb der Doc und innerhalb.

Aber selbst wenn das funktioniert, scheinen die Aussetzer nicht durch PHP-Fehler ausgelöst zu werden. Zumindest wurde seit Gestern auf keiner einzigen Domain was geloggt. Als gegentest habe ich gerade eine Seite mit Fatal Error eingebaut und aufgerufen, dass wurde geloggt. Wie kann ich den Aussetzern auf die spur kommen?

બાય

[dedlfix]

Tach!

Also außerhalb der Doc Root funktioniert es bei mir nicht. Fehler werden nicht gespeichert.

PHP muss mindestens in sie schreiben dürfen, mit der Kennung mit der es läuft.

Ich habe der php.ini, die außerhalb der Doc liegt folgendes hinzugefügt:

Ist das dann eine (zumnidest für dich) globale php.ini, wie sie beispielsweise vom FCGI-Wrapper an PHP bekanntgegeben wird? Ansonsten zählt ja nur die php.ini aus dem jeweiligen Script-Startverzeichnis. Alternativ seit 5.3 (und nur mit (F)CGI-Einbindung) gibts da noch die .user.ini, die man im DocumentRoot anlegen kann und dann für alle Script-Starts unterhalb dessen gilt.

;error_log = "./homepages/XX/XXXXXXXXXX/htdocs/new_cms/php_error_log.log"[/code]

Der . am Anfang bewirkt, dass vom aktuellen Verzeichnis ausgegangen wird - welches auch immer das ist.

Aber selbst wenn das funktioniert, scheinen die Aussetzer nicht durch PHP-Fehler ausgelöst zu werden. Zumindest wurde seit Gestern auf keiner einzigen Domain was geloggt. Als gegentest habe ich gerade eine Seite mit Fatal Error eingebaut und aufgerufen, dass wurde geloggt. Wie kann ich den Aussetzern auf die spur kommen?

Wenn PHP nicht zu loggen in der Lage ist, dann kann es die Aussetzer nicht behandeln und vermutlich ist es dann auch nicht ihr Auslöser. Das ist dann höhere Gewalt, die nur dein Systemverwalter aufzuspüren in der Lage ist.

Eine Vermutung ist, wenn du an den Memory-Einstellungen drehst, nimmt sich PHP mehr Speicher von außerhalb zugestanden und wird dann gekillt.

dedlfix.

[Malcolm Beck´s]

હેલો

PHP muss mindestens in sie schreiben dürfen, mit der Kennung mit der es läuft.

0666 habe ich eingestellt. Was bedeutet die „Kennung“, mit der es läuft?

Ist das dann eine (zumnidest für dich) globale php.ini, wie sie beispielsweise vom FCGI-Wrapper an PHP bekanntgegeben wird?

Ich denke nicht. Alle versuche, dass error_reporting von außerhalb der Doc Root zu starten, sind fehlgeschlagen.

Alternativ seit 5.3 (und nur mit (F)CGI-Einbindung) gibts da noch die .user.ini, die man im DocumentRoot anlegen kann und dann für alle Script-Starts unterhalb dessen gilt.

phpinfo() sagt:

PHP Version 5.4.16

Server API:	CGI/FastCGI  
; Habe ich FastCGI?  
  
max_execution_time: 30  
;ich hatte bei mir eingestellt: max_execution_time: 50000

;error_log = "./homepages/XX/XXXXXXXXXX/htdocs/new_cms/php_error_log.log"[/code]

Ich habe jetzt einfach wieder eine php.ini ins Doc Root gelegt und von dort aus das error_log aktiviert.

log_errors = On  
error_log = "php_error_log.log"

Eine Vermutung ist, wenn du an den Memory-Einstellungen drehst, nimmt sich PHP mehr Speicher von außerhalb zugestanden und wird dann gekillt.

memory_limit	128M  
; das ist Default, ich hatte es auf memory_limit = 40M reduziert. Jetzt ist es aus meiner php.ini raus.

બાય

[dedlfix]

Tach!

PHP muss mindestens in sie schreiben dürfen, mit der Kennung mit der es läuft.
0666 habe ich eingestellt. Was bedeutet die „Kennung“, mit der es läuft?

Weltweit ist sicherlich nicht notwendig. "Kennung" ist der Account, den der Webserver nimmt, um deine PHP-Instanzen zu starten. Das ist vermutlich dein Nutzername, den du auch für FTP nimmst.

phpinfo() sagt:
PHP Version 5.4.16
Server API: CGI/FastCGI
Habe ich FastCGI?

Ja. FCGI ist auch die einzig sinnvolle Art, einen Webserver mit Massenhosting zu betreiben. PHP als Apachemodul mag zwar weniger ressourcenverbrauchend klingen, hat aber gravierende Sicherheitsnachteile. Man kann die Anwender/Anwendungen nicht trennen, alles läuft unter demselben Nutzer.

max_execution_time: 30
;ich hatte bei mir eingestellt: max_execution_time: 50000[/code]

;error_log = "./homepages/XX/XXXXXXXXXX/htdocs/new_cms/php_error_log.log"[/code]

Ich habe jetzt einfach wieder eine php.ini ins Doc Root gelegt und von dort aus das error_log aktiviert.

Du hast doch PHP >= 5.3, dann leg doch eine .user.ini ins DocumentRoot und die wird dann immer genommen, egal wo ein Script gestartet wird. Und adressier mal den Pfad der error_log absolut von der Dateisystemwurzel aus: /homepages/...

dedlfix.

[Malcolm Beck´s]

હેલો

Weltweit ist sicherlich nicht notwendig. "Kennung" ist der Account, den der Webserver nimmt, um deine PHP-Instanzen zu starten.

Das ist korrigiert auf 664. Die Kennung sollte doch automatisch erkannt werden?

Du hast doch PHP >= 5.3, dann leg doch eine .user.ini ins DocumentRoot und die wird dann immer genommen, egal wo ein Script gestartet wird. Und adressier mal den Pfad der error_log absolut von der Dateisystemwurzel aus: /homepages/...

Der Server weigert sich, meine .user.ini zu benutzen.

Document Root

Und darin steht (das ist der komplette Inhalt):

allow_url_fopen = ON  
display_errors = ON  
log_errors = On  
error_log = "/kunden/homepages/XX/XXXXXXXXXX/htdocs/new_cms/php_error_log.log"

Egal, ob ich die error_log-Datei ins Document Root lege, oder im Webseitenverzeichnis. Es wird partout nichts darin gelogged.

Den Pfad der errror_log-Datei habe ich mit einer herkömmlichen php.ini gegen getestet, der ist richtig.

બાય

[dedlfix]

Tach!

Weltweit ist sicherlich nicht notwendig. "Kennung" ist der Account, den der Webserver nimmt, um deine PHP-Instanzen zu starten.
Das ist korrigiert auf 664. Die Kennung sollte doch automatisch erkannt werden?

Man muss sie auch nicht weltweit lesen können. "Kennung automatisch erkannt"? Mir scheint du hast da ein Verständnisproblem, wie das so abläuft auf einer Linux-Maschine. Jeder Prozess läuft nicht einfach so, sondern wird im Kontext eines bestimmten Benutzers gestartet. Wenn PHP gestartet wird, wird keine "Kennung erkannt" sondern eine verwendet, mit deren Rechten PHP dann läuft.

allow_url_fopen = ON

display_errors = ON
log_errors = On
error_log = "/kunden/homepages/XX/XXXXXXXXXX/htdocs/new_cms/php_error_log.log"

  
display\_errors ist für das Logging nicht relevant. Das steuert nur, ob die Fehler in Richtung Client ausgegeben werden. error\_reporting muss aber gesetzt werden.  
  

> Egal, ob ich die error\_log-Datei ins Document Root lege, oder im Webseitenverzeichnis. Es wird partout nichts darin gelogged.  
  
Zur Probe sollte ein Fehler in einem PHP-Script provoziert werden. Wenn der einen Eintrag erzeugt, aber die sporadischen Hängern keinen, dann kannst du an der Stelle abbrechen, weil das keine weiteren Erkenntnisse für dieses Fehlerbild bringt. Dann hilft nur noch ein Blick ins Error-Log des Apachen, wenn der Hoster dir ein solches zur Verfügung stellt, weiteres ungezieltes Probieren mit den Einstellungen oder die Hilfe vom Support.  
  
  
dedlfix.

[Malcolm Beck´s]

હેલો

Zur Probe sollte ein Fehler in einem PHP-Script provoziert werden. Wenn der einen Eintrag erzeugt, aber die sporadischen Hängern keinen, dann kannst du an der Stelle abbrechen, weil das keine weiteren Erkenntnisse für dieses Fehlerbild bringt.

Einen Fehler provoziere ich die ganze Zeit schon, während ich teste. Ich habe ein Script angelegt, dass eine nicht vorhandene Funktion aufruft.

Ich bin Gestern beim surfen auch über diese Seite gestolpert. Da wird erklärt, dass man um einzelne php.ini in jedem Verzeichnis nicht rumkommt, oder ich habe es falsch verstanden.

બાય

[dedlfix]

Tach!

Ich bin Gestern beim surfen auch über diese Seite gestolpert. Da wird erklärt, dass man um einzelne php.ini in jedem Verzeichnis nicht rumkommt, oder ich habe es falsch verstanden.

Da kannst du auch die offizielle Dokumentation anschauen: The configuration file. Für dich trifft da nur "Current working directory" (=CWD) und nachfolgende zu. Wobei du die nachfolgenden nicht beeinflussen kannst. Das heißt also, dass du in jedem Verzeichnis mit zu startenden Scripts eine php.ini liegen haben muss (oder eine generelle in die jeweiligen Verzeichnisse versymlinkt). Das kannst du nur mit der .user.ini umgehen, die vom CWD aus hoch bis zum DocumentRoot gesucht wird und demzufolge nur dort abgelegt werden muss. Wenn das aber bei dir nicht funktioniert, dann bleibt nur die Mehrfach-php.ini. (Ich wüsste aber nicht, warum man die .user.ini abschalten wollen würde (falls das geht). Das ergibt keinen Sinn, wenn die php.ini erlaubt ist.)

dedlfix.

[Malcolm Beck´s]

હેલો

Wo ist Document Root?

Ich dachte immer

/DocumentRoot
    /saveincludefiles
    /blog
    /cms
        /css
        /js

oberste ist Document Root. Ist das vllt. Kontextabhängig? Wenn ich bspw. „cms“ als Startverzeichnis für meine Domain angebe, wo ist dann der Document Root?

(Ich wüsste aber nicht, warum man die .user.ini abschalten wollen würde (falls das geht). Das ergibt keinen Sinn, wenn die php.ini erlaubt ist.)

Haben die auch nicht. Ich habe wohl Document Root falsch verstanden. Wenn ich eine „.user.ini“ direkt ins Verzeichnis lege, wo die index.php liegt, funktioniert es.

Es funktioniert dann auch Verzeichnis-Übergreifend. Jetzt werden auch Fehler in Verzeichnissen geloggt, in denen keine php.ini liegt. Zeit zum rumspielen ;) Danke für den Tipp!

બાય

[dedlfix]

Tach!

Wo ist Document Root?

Das Wurzelverzeichnis aller Dokumente unter einer Domain, von HTTP aus gesehen das Verzeichnis / (aber nicht die Dateisystem-Wurzel). Es ist auch in $_SERVER['DOCUMENT_ROOT'] zu finden.

Ich dachte immer

/DocumentRoot
    /saveincludefiles
    /blog
    /cms
        /css
        /js
oberste ist Document Root.

Anhand der Verzeichnisstruktur kann man das nicht erkennen, höchstens raten.

Ist das vllt. Kontextabhängig? Wenn ich bspw. „cms“ als Startverzeichnis für meine Domain angebe, wo ist dann der Document Root?

Es ist konfigurationsabhängig. Wenn du mit http://cms.example.com/ das Index-Dokument des Verzeichnisses cms erreichst, dann ist cms das DocumentRoot.

dedlfix.

[Malcolm Beck´s]

હેલો

/DocumentRoot
    /saveincludefiles
    /blog
    /cms
        /css
        /js
oberste ist Document Root.

Anhand der Verzeichnisstruktur kann man das nicht erkennen, höchstens raten.

„/DocumentRoot“ ist das höchste Verzeichnis, auf das ich zugreifen kann.

Also: „/kunden/homepages/XX/XXXXXXXX/DocumentRoot“

Eigentlich heisst es htdocs, mein Fehler.

Es ist konfigurationsabhängig. Wenn du mit http://cms.example.com/ das Index-Dokument des Verzeichnisses cms erreichst, dann ist cms das DocumentRoot.

Dann hatte ich das ganz klar Missverstanden. Ich dachte, dass „/DocumentRoot“ quasi mein Wurzelverzeichnis ist, auf das ich zugreifen kann.

બાય

[dedlfix]

Tach!

Ich dachte, dass „/DocumentRoot“ quasi mein Wurzelverzeichnis ist, auf das ich zugreifen kann.

Nö, der Begriff DocumentRoot stammt aus der Apache-Konfiguration (zumindest wird er dort verwendet). Das was du meinst, ist dein Kunden-Verzeichnis (oder Home-Verzeichnis). Der Webserver und PHP haben keine Ahnung, wie die Verzeichnisse auf dem Server vergeben worden sind. Die wissen nur das, was sie angeht, und das ist eben das Wurzelverzeichnis (DocumentRoot) der jeweiligen Domains, oder besser (V-)Hosts.

dedlfix.

[Malcolm Beck´s]

હેલો

Nö, der Begriff DocumentRoot stammt aus der Apache-Konfiguration (zumindest wird er dort verwendet). Das was du meinst, ist dein Kunden-Verzeichnis (oder Home-Verzeichnis). Der Webserver und PHP haben keine Ahnung, wie die Verzeichnisse auf dem Server vergeben worden sind. Die wissen nur das, was sie angeht, und das ist eben das Wurzelverzeichnis (DocumentRoot) der jeweiligen Domains, oder besser (V-)Hosts.

Danke für die Hilfe! Wieder einiges dazu gelernt.

બાય

[Malcolm Beck´s]

હેલો

Für das Archiv: „.user.ini“ funktioniert auch bei Strato, zumindest wenn man die PHP-Version auf V 5.3.22 setzt.

Da sehen nur die Pfade etwas anders aus:

log_errors = On  
error_log = "/home/strato/http/power/rid/XX/XX/XXXXXXXX/htdocs/speedtab/php_error.log"  

Die „php_error.log“ braucht man nicht erstellen, die wird beim ersten Fehler automatisch erstellt. Man darf nur nicht vergessen, die „php_error.log“ für den öffentlichen Zugriff zu sperren.

# Document Root htaccess  
<Files ~ ".(ini|log)$">  
  Order allow,deny  
  Deny from all  
</Files>

બાય

[Malcolm Beck´s]

હેલો

hat wer Zeit und Lust mein Speeddial zu testen? Es ist soweit fertig, nur noch ein paar kleine Macken sind vorhanden, die kriege ich aber auch noch weg.

Für die Registrierung habe ich alle Prüfungen deaktiviert. Das heißt, Ihr könnt euch mit einem Buchstaben registrieren und dann direkt einloggen. Mich interessiert vor allem die Benutzerführung (die sollte ja quasi selbstredend sein), wie Intuitiv das ganze wirkt.

Zu den Technischen Details halte ich mich erstmal bedeckt, weil es viel zu viel geworden ist. Wenn Ihr fragen habt, nur zu.

બાય

[Malcolm Beck´s]

હેલો

Speeddial

Funktioniert derzeit übrigens nur in Chrome richtig, Firefox zeigt einiges etwas falsch an. Mit Opera geht es gerade noch so eben.

બાય