1. die Class .menu bekommt einen z-index von 532, aber .content bekommt 548 und ist somit höher
Seit wann den das? Das kenn ich aber noch ganz anders. Je höher die Zahl um so weiter VORNE vom Betrachter aus das Objekt.
Um schreiben oder kommentieren zu können, benötigen Sie ein Benutzerkonto.
Sie haben schon ein Benutzerkonto? Melden Sie sich hier an.
Jetzt anmeldenHier können Sie ein neues Benutzerkonto erstellen.
Neues Benutzerkonto erstellen1. die Class .menu bekommt einen z-index von 532, aber .content bekommt 548 und ist somit höher
Seit wann den das? Das kenn ich aber noch ganz anders. Je höher die Zahl um so weiter VORNE vom Betrachter aus das Objekt.
Gute Lektüre: http://www.kuketz-blog.de/basisschutz-wo…bsichern-teil1/
Jeder Schutz, hilft aber generell erstmal nicht vor Angriffen. Also wirst Du wohl auch in Zukunft "genervt" werden. Das ist leider so.
Also der Server braucht schonmal ewig bis sich was tut, so wie das aussieht. Dann sind da für meinen Geschmack zuviel verschiedene css und js Dateien. Die kombiniert man, den die blockieren das weitere rendern der Seite.
Nein muss da nicht drin sein. Aber wenn man sich nicht sicher ist, schaut man doch einfach mal nach...
das tut doch weh :confused:
Stimmt, ich sollt das lassen :-)
*Kopf->Tisch* :shock: :)
Eigentlich sollte es bei allen genannten gehen... Hab die selber auch schon durch und nie Probleme gehabt.
Mir ist das ganze zu "unruhig". Es ist irgendwie anstrengend zu lesen. Der Hintergrund sollte wirklich "still" und dezenter sein.
Das Crawlen kann man nur mit dem entsprechenden Eintrag in der robots.txt unterbinden (wie von Gerd-E. geschrieben).
Durch "noindex" im Header wird nur die Aufnahme in den Suchindex verhindert.Gruß
Ingo
Richtig. Allerdings "sieht" Google dann auch nicht den noindex Tag auf der Seite und haut diese evtl. (wenn von irgendwo verlinkt) doch in den Index. Meist dann allerdings ohne Beschreibung und so, was nicht so schön ist. Daher eher Finger weg von der robots.txt und schön mit noindex arbeiten.
Soooooooo groß kann die Seite auch gar nicht sein, das Google damit nicht fertig wird ;-)
Aufrufen lassen sich die schon -> http://siarius.de/?page_id=29
Nur wird da eben immer die page_id=8 noch voran gehängt, was wohl Deine Startseite sein wird. Ergo geh ich mal davon aus du hast das irgendwie als Blogadresse eingetragen. Das muss raus.
Zitat von 'Marcus[IS;579180']aber die Datenschutzerklärung musst du ausgliedern und auf einer Extra Seite ausgeben
Muss nicht... WENN das Impressum von überall mit EINEM Klick erreichbar ist und auf der Seite dann ein sichtbarer Hinweis ist das sich die Datenschutzerklärung auch hier befindet...
Und wer soll damit jetzt was anfangen? Wo steht das? Welches Theme? Link?
...400 MB Webspace. 200 sind für E-Mail 200 für den Webauftritt...
Und dann nicht günstig? Was bitte zahlst Du den dafür?
Wie schon gesagt wurde, wenn Du wirklich alles gelöscht hast und der Provider Dir den Speicherplatz trotzdem nicht mehr freigeben kann, hat ER ein Problem nicht Du. Also Druck machen dort. Aber schau lieber nochmal nach ob Du auch wirklich ALLES gelöscht hast. Logdateien, Fehlerlogs oder anderes Zeug vielleicht noch vorhanden was auch zum Speicherplatz gezählt wird unter umständen... ???
Kenn mich mit Json nicht aus, aber ich les öfters mal was anderes aus, suche mal nach "json auslesen" und wurschtel Dich da dann durch, da findest Du bestimmt was. Dein Ansatz ist schon mal nicht schlecht, musst eben nur wissen wie Du die Json Daten ausliest.
Kannst den ganzen Footer ausblenden. #colophon{display:none}
Wobei ich trotzdem eher zu der Möglichkeit, die footer.php in dein Theme zu kopieren tendieren würde und da dann das Zeug raus zu nehmen. Den warum was rendern lassen wenn man es nicht braucht? Und Google mag versteckte Sachen, vorallem Links auch nicht, und genau das machst Du so aber.
Deine styles sieht falsch aus. Die Kommentare sind nicht richtig, da fehlt
/*
am Anfang. Versuch es mal.
Vielleicht hilft das weiter: http://www.php.net/manual/de/ini.core.php#ini.open-basedir
Ich würd eher sagen das ist ein custom post type.
Der Nachteil an einer lokalen Test-"Kopie" ist, dass dort meist nicht die gleichen Verhältnisse herschen, wie auf dem Live-Server.
Man muss die Testumgebung natürlich genau an die Verhältnisse des Servers anpassen, sonst macht das keinen Sinn.
Ziemlich oft? Ich weiß das es ab und an Probleme gab/gibt, wie aber bei allen Services. Oft liegt es allerdings auch an FB selber. Ich nutze es schon ewig und bleib dabei, den auf Dauer gesehen ist es bisher doch das stabilste und zuverläsigste, insbesondere wenn es um viele Artikel geht die gepostet werden müssen.
Ich lass mir aber immer gern bessere Möglichkeiten zeigen ;-) (Solange es kein Plugin ist das die DB mit 1000ten benutzerdefinierten Feldern zumüllt, was leider die meisten machen...)