Magento 2 Entwickler auf Meet Magento Opatija – Kroatien.

Wir – Magento 2 Entwickler von andU.de und Magento 2 Entwickler von Webdesign Holder – sitzen im Hotelzimmer- gesponsert von der Magento Agentur Inchoo und der Meet Magento – und lassen die Magento 2 Themen der Vorträge der letzten Tage Revue passieren. Es ist auf viele wichtige Magento 2 Themen eingegangen worden, die ich hier nicht wiedergeben kann – das würde den Rahmen hier sprengen. So viel kann ich jetzt schon schreiben: Es gibt so einige Magento 2 Themen über die es nachzudenken lohnt und auch über die grundsätzliche Frage, ob Magento 2 als ein Nachfolger von Magento betrachtet werden sollte, oder als ein ganz neues, auf Magento 1 aufbauendes Shopsystem, ohne Magento 2 hier bewerten zu wollen oder können.

Unser Fazit ist, dass Magento 1 noch einige Zeit für Shopbetreiber und Magento Entwickler ein Thema sein wird, da ein „Upgrade“ auf Magento 2 nicht ohne unverhältnismäßige Aufwände möglich ist, und auch voraussichtlich nicht sein wird.

Durch Magento 2 hat unsere Beratung der Magento Shop Betreiber eine ganz neue Dimension angenommen.

Da Magento 1 auf PHP Version 5.4 angewiesen ist, und PHP 5.4 nicht mehr viele Jahre lange unterstützt werden wird, wäre eine Idee – um nicht gleich in Unkosten zu stürzen – den Magento 1 Core für PHP 7.0 aufzurüsten, damit bestehende Magento 1 Shops nicht dem Untergang geweiht sind.

Für eine schnelle Webseiten Optimierung für Google sind die Zutaten relativ einfach:

Erste Zutat für eine Webseiten Optimierung für Google ist, dass man eine alte Domain braucht, die mit dem Thema definitiv was gemein hat, umso älter, umso besser. Wenn man einen Relaunch macht, muss dieser vorsichtig von Statten gehen, um nicht als solcher erkannt zu werden, denn sonst landet man schnell in die Sandkiste von Google. Aber auch wenn das passiert und man beim Thema bleibt, rappelt sich die Domain bei Google schnell wieder auf. Also braucht man auch schon ein wenig Glück, sich vor Jahren mal eine zum Thema pssende Domain ausgesucht zu haben, bzw eine solche Domain kaufen zu können.

Zweite Zutat für die Webseiten optimierung für Google ist die Wahl der Keywords, passend zur Absicht. Will man verkaufen, beraten, informieren? Und genau da fängt das Problem der guten Optimierung für Google an. Denn was nützen mir gute Platzierungen, wenn keiner der Suchenden sich für meine Seite interessiert. Also habe ich mit falscher Absicht gelockt und nichts erreicht.

Dritte Zutat für eine Webseitenoptimierung für Google ist das korrekte Einbetten der Keywords, verteilt in der URL, im Title, Description, Überschrift, Ersten Absatz und Fett markerten Wörtern. Und das gepaart mit einem Text der nicht ständig mit der Phrase : „Webseiten Optimierung für Google“ nervt.

Vierte Zutat für eine gute Webseitenoptimierung für Google sind Landing Pages, bzw ein Blog. Aber auch hier wieder vorsicht: Nicht Tipps geben, die sie evtl. verkaufen wollen und den Kunden somit zum Konkurrenten schicken.

Es gibt da noch viele gute Zutaten für eine gute Webseiten Optimierung für Google, doch wenn man ein Gutes Layout hat und wenig bis keine Barrieren auf der Seite ( meine Webseite ist kein Vorbild – weiß Gott nicht),  sollte dieses schon ausreichen, um nach und nach auf die ersten Plätze zu gelangen. Probieren geht auch über Studieren, wie zB A/B Test von Google.

Ich hoffe ein wenig Licht in die Dunkelheit der Webseitenoptimierung für Google gebracht zu haben.

Ich habe da noch eine Schrottige, aber bei google einigermaßen gut gerankte Seite mit Tipps und Referenzen: http://web-seiten-optimierung.de/.

Webentwickler  Raum Hamburg

Sie haben gerade Webentwickler gefunden !!!

Ob PHP, Zend (ZF2), MySQL,  Magento, jQuery,  Vanilla JS Entwicklungen: wir sind die richtigen.

In Zusammenarbeit mit andU.de setzen wir uns für Sie und Ihre Bedürfnisse ein.

Ob es eine gelungene Webseite sein soll – Responsive Design, Progressive Enhancement, oder ein sexy Webshop ( Magento ),
oder eine gelungene Webapplikation ( ZF2, MySQL, jQuery,  Vanilla JS ), oder eine gesunde Mischung aus allem – rufen Sie uns an !

Immer erreichbar unter 0172 422 69 57 – oder im Büro mit unserem Partner andU.de unter der Nummer
☎ 040 430 95 430

Wir sind begeisterte Webentwickler von Webapplikationen. Unsere Programmierleistungen sind Professionell und gut konzipiert.

Die schnelle Nummer – den schnellen Entwickler – finden Sie bei uns leider nicht, dann können Sie sich den Anruf gleich sparen.

Lösung gefunden für das Magic Scroll Modul – Pfeile nur da, wenn nötig

http://www.tomislav.net/magicscroll-magento-pfeile-nur-bei-bedarf.htm

Beim Magento Magic Scroll Modul kann man vieles einstellen. Aber nicht, dass die Pfeile verschwinden, wenn sie nicht benötigt werden. Außerdem wird das Javascript, das man im Falle „zu wenig Bilder“ / Zu wenig Thumbnails nicht mehr braucht für MagicScroll trotzdem geladen.

Hier die Lösung: http://www.tomislav.net/magicscroll-magento-pfeile-nur-bei-bedarf.htm

Beispiel: http://www.tomislav.net/center.html

Manchmal gibt es immer noch den Kunden Wunsch dei Seite absolut zu zentrieren. Es gibt da diese Workarrounds mit dem Absoluten Layer mit left 50% und top 50% und dann jeweils einen negativen Margin von der halben Höhe und halben Breite des Inhalts. Doch Wenn man das Fenster dann kleiner schiebt, dann verschwinden Teile des Contents nach Links ins nirwana und oder gleichfalls nach oben.  Meine Version, leicht abgewandelt, getestet ab IE7 und allen gängigen Browsern erlaubt sogar ein Background Image, dass über den Content hinaus geht.

Angenommen man hat einen Content breite 1000px und höhe 550px. Dafür aber ein Hintergrundbild (hier das bg_center.jpg ) das breiter ist: Hier 1042px x 550px. Dann verpasst man am besten dem body Tag dieses Hintergundbild. Doch passiert dann genau das selbe mit dem Hintergrundbild, wie mit dem Content, wenn man das Fenster kleiner Zieht  es verschwindet jeweils nach oben und / oder nach links..

Darum habe ich mir dafür einen Workarround ausgedacht, das es sogar erlaubt hinter diesem Body BG Bild eine Kachelung einzubauen, die fix ist. Das Kachelbild bekommt dann der HTML Tag.

Hinzu kommt, dass ich den Browser dazu zwinge scrollbalken Platzhalter zu zeigen, egal, ob nun gescrollt werden muss oder nicht.

Das ganze noch auf Basis XHTML 1.0 Transitional und W3C konform und ohne Javascript mit ein wenig CSS auch W3C.

Ich habe nun keine Zeit gehabt das ganez im HTML 5 auszuprobieren, aber ich denke, dass das dort genauso funktioniert.

Hier ein Beispiel:  http://www.tomislav.net/center.html

Den Code bitte der Seite entnehmen.

Wer sich mit (X)HTML und CSS auskennt wird erkennen warum es funktioniert:

Nun stellen Sie sich vor, sie haben weder Windows 7 noch einen Mac, jedoch einen Safari, oder Chrome auf Ihrem Rechner. Sie möchten sich eine Notiz machen. Dann einfach auf die Website  http://webkit.org/demos/sticky-notes/index.html gehen, dort eine Notiz hinterlegen – wobei die Notiz nicht auf deren Server gespeichert wird, sondern auf Ihrem Rechner bei sich zuhause. Jederzeit abrufbar ohne cookies, ohne alles, einfach aus der heimischen Datenbank auslesend.

Verdanken tun Sie das der neuen SQL Engine in der Webkit Browsern. DATENBANKEN im BROWSER !!! Hallelujah… Webserver werden immer mehr enlastet werden, vieles, was zZ noch per Ajax gelöst ist, wird bald eine Mischlösung werden, um die Server zu entlasten… und  auch  – sollte das Internet mal ausfallen, die Daten offline noch greifbar sind. Genauso oder sagen wir mal ähnlich die DOM Storage Engine vom IE… Mal wieder ein anderes Format… aber keine Bange… Mootools hat mal wieder ne Lösung parat: Sie Speichern daten per Mootools, und wenn beides nicht funktioniert, dann speichert Mootools die Daten halt per JS Cookies, wobei das leicht instabil sein dürfte, aber hauptsache funzt 🙂

Normalerweise ist der Focus bzw DOMElement.focus() nur den a-Tags und Input-Tags vorbehalten. Es gibt jedoch einen ganz einfachen „Trick“ (zumindestens für Moderne Browser, bei älteren habe ich es noch nicht ausprobiert) dieses zu fixen. Einfach dem beliebigen Element einen Tabindex verpassen, dann verhält es sich mit dem Focus so, wie bei einem a-Tag. Beispiel:

… Dann einfach per Javascript document.getElementById(‚to_be_focused‘).focus(); aufrufen und schon hat das div Element einen Focus. Leider muss man select() nach wie vor über document.select() und die beiden verschiedenen Arten der Selektion – je nachdem, ob es ein IE ist, oder nicht – nachbauen. Es sei denn, jemand hat einen Tipp für mich… würde mich freuen….

Der IE selbst braucht diesen Workarround nciht, denn im IE lässt sich von Haus aus alles fokusieren

Feedback immer gern gesehn… Euer Tomsilav

Min Height wird im IE6 nicht ausgewertet. Darum gibt es ein paar schlaue Köpfe, die nach Alternativlösungen gesucht hatten und auch eine fanden:

#wrapper {
min-height: 500px;
height: auto !important;
height: 500px;
}

Das funktioniert auch super, solange man tatsächlich auch nur min-height benötigt. Aber was ist wenn man beides braucht? height und min-height?
Angenommen ich habe einen Wrapper, der direkt unterm Body Tag anfängt. und brauche height:100% und min-height:500px; ??

Da kommt nur noch expression als mögliche Alternative.

Wichtig dabei ist es zu wissen, dass wenn man ganz genau vorgehen will, man liber den nächst höheren Tag anspricht und zur Not dafür auch einen anlegt.

Wenn es der Hauptwrapper ist, dann muss man es nicht, denn den Body Tag muss man ja eh anlegen…

Situation: <body><div id=“wrapper“></div></body> wrapper muss 100% hoch sein, aber mindestens 500px;

Das ist bei bestimmten dynamischen footern erforderlich, worauf ich das nächste Mal eingehen werde…

die Lösung in der CSS Datei:

* html #wrapper{
height: expression( document.body.clientHeight <= 500 ? „500px“ : „100%“ );
}

damit hat man beide abgefrühstückt.. es ist mimdestens 500px und 100% hoch.

man könnte auch mit this.clientHeight arbeiten, doch dann nur mit kleiner als, kleiner – gleich funktioniert nicht, denn bei genau 500px bleibt der IE6 schön hängen und stürzt ab.

Sicherlich könnte man herumexperimentieren jedoch, wenn der wrapper 500px in dem Moment hoch ist und man fragt ihn, wenn Du gleich kleiner 500 groß bist dann werde 500px hoch, gibt es eine Schleife und der IE6 stürzt ab.

Ich bleibe dran und versuche eine bessere Solution zu finden, und man muss sich echt keinen Kopf mehr machen, ob nu der IE6 nutzer JS an hat, oder nicht…

denn der IE6 nutzer ist froh, wenn er überhaupt etwas zu sehen bekommt – also wird er JavaScript generell anhaben, oder er hat halt großes Pech. Und man kann ja immer noch da so stylen, dass im Falle des Misserfolgs alle Daten sichtbar sind -also das Wichtigste eigentlich. Und das sollte nun echt kein Problem sein.

Tom