Homepage Handy-freundlich gestalter (@media screen..) + Fragen

[Madman1209]

Hi,

will gar nicht mehr länger zwischenfunken, wollte mich nur noch kurz bedanken für die Tipps und Erklärungen. Jetzt bleibe ich wieder stiller Leser und drücke dem TE die Daumen

VG,
Mad

 

[rest0ck]

Okay das hat mir schon gut weitergeholfen, vielen Dank
Hab nur meinen Laptop dabei und mit dem habe ich kein Internet (So als Provider, .. schon .. nicht schlecht), .. was eigentlich ja nichts zur Sache tut aber ich nutze das Teil so selten und dann hat es auch noch eine andere Belegung (MacBook), .. es verwirrt mich und macht mir irgendwie wenig Spaß an dem Teil :<
Ich werde es vermutlich trotzdem gleich mal bisschen testen..

Achja ehm, meine Freundin hätte gerne einen Blog auf dem sie hauptsächlich Rezepte postet. Wisst ihr womit es möglich ist, aus den Blogeinträgen dann ein "Rezepteindex" zuerstellen mit "Hauptspeisen" "Nachspeisen" etc. - also ne große Auflistung?

Grüße

 

[Speedy.]

Für einen Blog ist WordPress durchaus eine Empfehlung. Du kannst WordPress entweder selbst hosten und hast damit die Administration vor dir (Updates, E-Mail-Einstellungen, Datenbank usw.), oder nimmst das kostenlose Angebot von http://wordpress.com an. Dort kann sich deine Freundin auf das reine Bloggen konzentrieren, den Rest macht der Anbieter. Einziger Nachteil ist, dass du zunächst keine eigene Top-Level-Domain hast, sondern nur eine Subdomain (sprich deineadresse.wordpress.com statt deineadresse.com).

In WordPress kannst du für jeden Beitrag beliebig viele Kategorien selbst erstellen und zuordnen. Wenn das Frontendtheme es zulässt, kann der Besucher der Webseite dann nach diesen Kategorien filtern (Vorspeise, Nachspeise, etc.). Jedes bessere WordPress-Theme hat solch eine Funktionialität.

 

[Daaron]

Ein Wort der Warnung zum Thema Kochbuch... Lasst euch bloß nicht einfallen, Bilder (z.B. schöne reife Tomaten) aus dem Internet zu verwenden. Ein recht ruchloses Kochbuch hier in Deutschland hat alle Hebel in Bewegung gesetzt, um bei der Bildersuche oben zu sein und mahnt danach alles und jeden ab, der die Bilder arglos verwendet.

 

[rest0ck]

Hey, dank für die Tipps und die Warnung

Sie wird das alles natürlich selbst machen. Aber bis dahin dauert es erst mal etwas.
Die Seite ist jetzt übrigens auf http://jaklef.de/ zu erreichen (das bin ich nicht ich, nebenbei bemerkt), hab das ganze aber NICHT geändert, lediglich die Schriften und Abstände. Um es auf dem Handy richtig darzustellen hab ich einfach getrickst: Der Body wird auf Breite von 498px gelegt und zentriert. Hab es auf 3 versch. Handys getestet (versch. Größen und Auflösungen) und es funktioniert

Das Videoplugin habe ich jetzt auch umgeschrieben, so das ich kein !important mehr nutzen muss. Facebook wird jetzt in Mobil Größe auch nicht mehr Scrollbar und die Buttons unten werden Finger-gerechter (größer).

Hab zwar immer recht hohe Ansprüche an mich selbst, aber dafür das ich das noch nie wirklich gemacht habe, bin ich zufrieden. Ist ja auch kostenlos für nen Freund, der darf nicht meckern ;P

Was aber stört: Wenn man mit dem Handy (am pc nicht) das Menü aufklappt, dann sieht man wie die Schrift der Items plötzlich größer wird, .. wie kann das sein und wie ändere ich das? Auch mit fester px größe passiert es. Kann es mir nicht so recht erklären.

Grüße

 

[max_1234]

Meine persönliche Umsetzung bisher:

|-> Systemauflösung checken (PC/Tablet)
|---> Auflösung zuordnen (Diff: PC/Tablet)
|------> User Agent zusätzlich checken, Ausgabe finalisieren

Primär Auflösung, sekundär User-Agent.
Auch wenn jemand den Firefox mit IPad User-Agent fährt, bekommt er die Seite richtig dargestellt (von mir gewollt).
Mobile Devices werden dann auch nur über den User-Agent gefischt (von mir gewollt).

Und natürlich bekommen die Mobiles ne eigene Seite ....

mfg,
Max

 

[Daaron]

Für Mobile Devices eine eigene Seite auszuliefern ist doch Grütze. Was machst du, wenn deine User Agents mal wegfallen? Was machst du, wenn der User seine Device einfach DREHT und plötzlich FullHD hat? Was machst du, wenn er zwar ne leichtgewichtige kleine Device hat, aber durch irgend welche Linking-Funktionen die Darstellung auf nem Monitor/Fernseher erfolgt?

Mobile First über Media Queries ist der beste Weg:
- selber Content für alle (SEO-technisch besser) und deutlich leichter zu verwalten
- keine obskuren "Magic Numbers" in irgend welchen Was-Wäre-Wenn - Tabellen
- zukunftssicher. Wenn Monitore größer werden, fügt man im Zweifel noch einen Break Point hinzu, das wars.

 

[rest0ck]

Okay okay, hab verstanden ;P
Jetzt gibt es zwar nur Desktop oder Mobil, aber das reicht mir fürs erste. Hab grad mit der Arbeit bisschen zu tun und mache ne kurze Homepage-Pause. Zumal der Jaklef grad eh kein Zugang zum Internet hat und die Seite im Grunde zwar jetzt online ist, aber kaum besucht wird :/

Hab das Problem mit dem Menü übrigens lösen können.

Blöd nur, dass wenn man Jaklef googelt, die Homepage auf circa Seite 5 landet. Hab noch nicht so recht rausgefunden, wie sich das verbessern lässt. Abwarten?

 

[Daaron]

Was ist Desktop, was ist mobile? Ist ein Netbook nun Mobile oder Desktop? Denk bei der Antwort daran, dass ein Tablet wie das aktuelle Nexus ne höhere Auflösung als ein Netbook erreicht...

Und Suchmaschinen-Ranking erlangt man
a) durch Zeit
b) durch anständige SEO-Maßnahmen. Das ist ein Kapitel für sich, damit kann man Bücher füllen.

 

[Speedy.]

Suchmaschinenoptimierung (SEO) ist so ein Fall für sich. Man kann ewig viel Zeit reinhängen, ohne das etwas bei rumkommt. Letztlich hängt (zum Glück) viel vom Content ab, darauf sollte man sich fokussieren. Ansonsten, wenn du der englischen Sprache mächtig bist und diesen Kurs durch hast (und auch auf der Webseite anwendest), dann dürfte es ganz gut aussehen:

http://webdesign.tutsplus.com/series/seo-fundamentals-for-web-designers--webdesign-9715

 

[rest0ck]

Die Seite braucht keine 3 Layouts - alles über Handy kann das normal Layout nutzen, außer im Hochformat vielleicht.

Ich denke das passt schon so.

Wegen dem SEO lese ich mir das mal durch, danke schon mal .)

Gute Nacht.

Ergänzung (4. März 2014)

Bezüglich SEO habe ich eine Frage wegen mod_rewrite.

Auf die normalen Seiten wie index.php, kontakt.php etc kann ich es normal anwenden mit z.B.

RewriteRule ^kontakt/$ /kontakt.php [NC,L]

Bei galerie.php funktioniert das allerdings gar nicht.
Das selbe wie oben mit galerie statt kontakt = Seite nicht gefunden.

Wollte es dann noch für galerie.php?album=X versuchen

RewriteRule ^galerie/album/*/$ /galerie.php?album=$1 [NC,L]

Keine Ahnung, ob das so richtig ist, hab auch schon anderes versucht, funktioniert aber auch nicht.

Kann mir jemand auf die Sprünge helfen :/?

/e Hm ich glaub das ist etwas komplizierter, oder? So kann doch gar nicht mehr GET aufgerufen werden?

Ergänzung (5. März 2014)

Ziel soll übrigens sein:

Jaklef.de/galerie/
Jaklef.de/galerie/album1/ oder /album/1 .. mir relativ

 

[Daaron]

Ne, das sollte schon grundsätzlich funktionieren. Evtl. hast du da einfach einen kleinen Schreibfehler, bei RewriteRules häng ich immer etwas im Trial&Error...

Aber für die Zukunft kannst du dir abgewöhnen, für jeden Furz ne eigene .php zu schreiben. Man schreibt ne zentrale index.php und hat dann (vor dem rewrite) URLs wie index.php?page=contact oder index.php?page=galerie&album=3&pagination=2 (die 2. Pagination-Unterseite des 3. Albums). Das sorgt für ne deutlich bessere Erweiterbarkeit, Übersicht und Fehlertoleranz.

Und was du ebenfalls bedenken solltest:
NOCH ist Apache die Platzhirsch, NOCH hast du mod_rewrite. Mittel- oder langfristig wird der Apache in die ewigen Jagdgründe eingehen, es drängen schließliche in paar wirklich mächtige Konkurrenten auf den Markt, allen voran natürlich nginx. Aber auch Cherokee hat richtig geile Ansätze.
Was all diese Konkurrenten gemeinsam haben: Sie haben keine .htaccess, denn .htaccess ist hochgradig ineffizient. Für die verschiedenen hta-Regeln muss der ganze Verzeichnisbaum rekursiv gelesen werden, um ja keine Regel zu übersehen. Nix gut.

Deutlich angenehmer als mod_rewrite ist Code-basieres Routing. Gibt einige freie und recht schlanke PHP Router Klassen, die das für dich übernehmen. Alle modernen, großen CMS verwenden Router. Die .htaccess wird zwar mit eingesetzt, aber nur für elementare Umleitung: Alles, was nicht auf die index.php geht und nicht als Datei existiert, wird auf die index.php geleitet (und die zündet den Router)

 

[rest0ck]

Oh, hm das ist mir alles sehr neu. Muss ich mich erst mal einlesen.

Wie genau funktioniert das denn, wenn ich nur noch eine .php habe?
Ist die dann ewig lang und beinhaltet Inhalt ALLER Dateien?
So quasi

if (isset($getage=kontakt)) {
kontaktkram }
else if (...) {
}

etc?

Das kommt mir sehr umständlich vor, sicherlich soll man das so nicht machen, oder?

Und wegen dem htaccess: Hab alles mögliche versucht und es auch einfach 1:1 kopiert und den Namen geändert (kopiert) -> hat nicht funktioniert?

 

[Daaron]

Nein, die index.php ist ziemlich klein. Die von Contao (immerhin ein ziemlich mächtiges CMS) ist gerade mal 414 Zeilen/11.5kByte lang, inklusive Kommentaren und Lizenz. Die von Magento (so ziemlich eines der mächtigsten Shopsysteme) ist auch nicht länger, ich glaub sogar noch kleiner.

Die Zauberworte heißen:
- Modularisierung
- Datenbank
- Objektorientierung

 

[rest0ck]

Achso, gut, man kann natürlich auch .. eh..den Kram quasi rein laden? Bzw die Inhalte werden trotzdem in Daten ausgelagert, oder?
Wozu genau soll die Datenbank verwendet werden?

Ich schreibe die ganze Seite jetzt aber erst mal nicht um, will es nur für nächste Projekte wissen.

 

[Speedy.]

Stimmt so ungefähr. Das Stichwort heißt MVC (Model, View, Controller). MVC ist eine empfohlene Herangehensweise bei der Softwareprogammierung, wo die Logik, die Templates und das Datenmodell voneinander getrennt sind. Das ist ein ziemlicher Happen und für Anfänger nicht leicht, bei großen Projekten aber ziemlich wichtig, da es sonst schnell in einer Codesuppe ausartet.

Nimm als Beispiel die index.php: Sie ist der Startpunkt deiner Webseite und steuert, was als nächstes geladen werden soll. Das entscheidet sich daran, was der User eingegeben hat oder du vordefinierst hast. Wenn der User also auf die Unterseite /kontakt/ gelangen möchte, wird über die URL ein entsprechender Parameter übergeben. Wenn eine Datenbank mit den Kontaktinformationen im Hintergrund arbeitet, dann wird der Controller (die index.php) das Model ansprechen, welches die Daten aus der Datenbank liest (oder schreibt, updated, wie auch immer...) und an die View (eine Templateseite etwa) weitergibt. So hast du die Applikationslogik von dem Datenmodell und den Ansichtsseiten getrennt und du hast wartbaren und sauber strukturierten Code.

Aber solch ein MVC schreibst du mal nicht so eben. Die meisten großen CMS oder Frameworks setzen darauf, sodass ess sich im Zweifel anbietet, eine solche Lösung zu nutzen und nicht von Null zu beginnen.

 

[Madman1209]

Hi,

mal ganz anders gefragt: was du da gerade selber zusammenbaust klingt mir nach genau dem, was Daaron anspricht, nämlich einem CMS. Warum verwendest du nicht einfach ein fertiges, ohne das Rad neu zu erfinden? Wäre das keine Option?

VG,
Mad

 

[Daaron]

Das is die andere Seite der Medaille: Do not repeat yourself!
Wenn es bereits mordsgeile freie CMS gibt, warum nicht einfach dei verwenden? Wenn eine Funktion fehlt, kann man immer ncoh genau die Funktion nachentwickeln.

Eine Vereinfachte Form von "Was macht die Index.php? Woher kennt sie, was sie den Kontakt laden soll?" wäre auch:
- Datenbank mit ner Zuordnung von Page-ID, evtl. nem menschenlesbaren Page-Alias, Page-Titel (<title>), Metadaten, das der Seite zugeordnete Gesamt-Layout,.... und im leichtesten Fall ein Verweis auf eine PHP-Datei, die die eigentlichen Inhalte enthält
- die Index lädt anhand der URL-Parameter aus der DB, welche PHP-File fällig ist (und evtl., ob der User berechtigt ist, sie zu sehen)
- der Rest ist include($hierStehtDerPfadZurPhpDateiAusDerDatenbank) an einer angenehmen Stelle, z.B. in einem <div> zwischen <header> und <footer>.

So ein Ansatz ist viel flexibler als dein aktueller, aber weit weniger mächtig als ein vollwertiges CMS mit separaten Content Elementen, die du wild Seiten zuweisen kannst.

 

[Speedy.]

- die Index lädt anhand der URL-Parameter aus der DB, welche PHP-File fällig ist (und evtl., ob der User berechtigt ist, sie zu sehen)

Wird das heute wirklich praktisch angewendet, dass PHP Dateien als BLOB in einer Datenbank liegen? Ich habe bisher immer nur Content in der Datenbank gelagert und diesen auf Template-Files angewendet.

 

[Daaron]

Ich sagte nix von BLOB. Du legst einfach in einen Unterordner deine einzelnen PHP-Files für die verschiedenen Unterseiten und in der DB liegt nur er Pfad zur Datei.
Und nein, das ist natürlich kein Vergleich zu komplexen Ansätzen, wo jeglicher Content in der DB liegt und nur auf ein Template gestülpt wird. Aber: Anders als eine komplette Lösung mit Content Elementen, Layout-Zuordnungen,... (also einem komplexen CMS) ist meine Variante sehr leicht umsetzbar. Außerdem lassen sich Unterseiten hier einfach per Editor + FTP-Verbindung ändern. Für ein "hey, ich will was lernen" - Projekt durchaus sinnvoll.