Beiträge von mensmaximus
-
-
-
Okay danke.... wobei das mit dem Plugin nichts zu tun haben wird. Weil auch ohne das Plugin gleiche Probleme bestanden.
Ohne Plugins wie Germanized, German Market oder German Shop wird auch keine Mwst angezeigt. Das ist kein Fehler.
-
Germanized Pro
In diesem Fall wendest Du Dich vertrauensvoll an den Hersteller: https://vendidero.de/mein-konto
-
PHP Version :5.2.6-1+lenny13 / 32Bit OSBitte auf PHP 5.6 Updaten und bei Gelegenheit auch auf ein aktuelles Betriebssystem.
-
Dann musst Du klassisch an die Sache rangehen: Alle Plugins bis auf Woocommerce und Germanized deaktivieren und testen. Taucht die Mwst dann auf hast Du einen Pluginkonflikt. Um den zu finden aktivierst Du eines nach dem anderen wieder und prüfst nach jedem Plugin die Ausgabe.
-
Username im Sinne von Loginname oder Displayname?
-
Das kann am Theme liegen. Manche Themes arbeiten mit eigenen Action und Filter Hooks, wodurch Plugins wie German Shop und German Market nicht greifen. Manche dieser Themes, wie z.B. Enfold von Kriesi bieten dafür ein kostenloses Intergrationspaket.
Was passiert wenn Du auf ein Standardtheme (z.B. Twenty Fifteen) umstellst (abgesehen von der wenig hübschen Darstellung)?
-
-
-
Das Problem steht ja quasi auf der Console. Mit 3-4 Stunden Suche und Anpassungen sollte das zu lösen sein. Also ein Sonntag bei Regen

-
Was sich hinter dem PostRank verbirgt oder hinter Tagessätzen, die jemand veranschlagt, kann ich doch nicht wissen. Beklagt euch also nicht bei potentiellen Kunden, sondern ändert etwas an der Außendarstellung und Transparenz eurer Leistungen.
Deswegen nimmt man ja auch nicht den ersten sondern bildet sich eine Meinung durch Nachfragen und Prüfung der Angebote. Und dann stellt man möglicherweise fest, dass der eine oder andere sehr transparent arbeitet und über qualifizierte Referenzen verfügt. Das kostet Zeit und bedeutet Aufwand.
Ich weiß, dass Kunden es nicht immer einfach haben. Die meisten verstecken sich aber genau hinter diesen Aussagen und haben noch nicht einmal versucht der richtigen Fachmann zu finden. Jedes neue Smartphone und jeder neue Fernseher wird besser geprüft und mit anderen Modellen verglichen. Zu viele der Leute die zu mir kommen, weil die Seiten gehackt sind, kommen die ersten 30 Minuten des Gesprächs nicht aus dem "Aber-Sagen" heraus. Schuld sind immer die anderen. Nach einer halben Stunde und einer gewaltigen Kopfwäsche später ist das erledigt und man kann mit der Arbeit beginnen, weil sie dann verstanden haben, dass sie es selbst in der Hand gehabt hätten und das Know-How nicht auf Bäumen wächst, weshalb es auch Geld kostet.
-
Das Problem ist, das hier vier Themen durcheinander gewürfelt werden aber nur eine Frage gestellt wird. Die Dinge hängen zwar zusammen haben aber dennoch nur bedingt etwas miteinander zu tun. Kurz und knapp:
1. Was Du in der Adresszeile des Browsers siehst ist zunächst Deine Anfrage, wie unter 2. beschrieben und später das möglicherweise umgeschriebene Ergebnis, wie unter 3 und 4 beschrieben.
2. Die Anfrage kannst Du selber durch Eingabe oder durch einen Klick auf einen Link in einer Webseite ausgelöst haben. Der Seitenbetreiber gibt den Link im Regelfall so an, wie auch das Ergebnis aussehen soll. Manchmal korrigiert der Webmaster das Ziel durch eine Umleitung, womit wir zu 3 und 4 kommen.
3. Die .htaccess Datei ist ein "Steuerdatei" für den Apache Webserver. Sie enthält Anweisungen, die dem Server mitteilen wie er sich verhalten soll. Dazu gehören unter anderem Rewrite Regeln, die das Apache Modul mod_rewrite steuern. Mit solchen Regeln kann man die Anfrage aus 1 umschreiben, um z.B. Anfragen auf eine nicht mehr existente URL zu einer anderen URL zu lenken. Die Rewrite Regeln greifen auf Webserverebene bevor Scriptsprachen überhaupt aktiv werden bzw. Applikationen wie WordPress zum tragen kommen, womit wir zu Punkt 4 kommen.
4. WordPress besitzt eine Vielzahl von Rewrite Regeln in der Datenbank, die je nach Permalinkstruktur zum tragen kommen. Es handelt sich hierbei um die gleiche Syntax wie in der .htaccess Datei, nur dass diese Regeln erst via PHP verarbeitet werden. WordPress nutzt dabei die .htaccess aus 3 nur um die Anfrage aus 1 so vorzubereiten, dass sie entsprechend der Permalinkeinstellugen verarbeitet werden kann.
Fazit: Dein Archivproblem liegt nicht an 1 und 2 sonder höchstens an 3 und sehr wahrscheinlich an 4. Der Codex zeigt Dir wie der .htaccess Eintrag für WordPress aussehen muss. Liegt es daran nicht, wurde eine Rewriteregel in WordPress verändert. Oft hilft hier einfach das Umstellen der Permalinks auf Standard, das Abspeichern der Einstellung und das Zurückstellen auf "Beitrag" mit erneuter Speicherung.
-
Es wäre toll, wenn mir jemand weiterhelfen könnte. -
Würdet Ihr jetzt noch einen zweiten Experten über die Datenbank schauen lassen? - Die so genannten Experten sind ja gegenseitig immer verschiedener Meinung. Der eine sagt so, der andere so.
Das was Du hier als Antwort des ersten Fachmanns gepostet hast, ist pure Spekulation und voller Konjunktive. Das ist keine vernünftige Analyse. Das liegt entweder daran, dass Du nicht bereit warst Geld in die Hand zu nehmen, der Fachmann als solcher keiner war oder die Möglichkeiten zum Debuggen extrem eingeschränkt waren. Ich tippe auf ersteres, da Du es bei Kontaktaufnahme noch nicht einmal für nötig hältst zu antworten.
Da Du also offensichtlich kein Interesse hast Spezialisten zu beauftragen die tatsächlich etwas von Hacks verstehen, würdest Du wahrscheinlich sowieso nur wieder Spekulationen erhalten. So wie im gesamten Thread.
-
Einmal umgekehrt gefragt: Welchen Sinn hat die Übung? Wenn beim Klick auf einen Menüeintrag der Inhalt von 3 Seiten angezeigt werden soll, dann sollten diese 3 Inhalte in einer Seite untergebracht werden. Statische Seite haben eine einzige Aufgabe und zwar deren Inhalt anzuzeigen und nur deren.
Beiträge und Custom Posttypes haben die Aufgabe Inhalte aufzunehmen und je nach Gusto des Webmasters auszugeben, einzeln oder mehrere nach gewissen Kriterien oder einfach alle.
Ohne Erklärung warum Du das machen willst, was Du eben machen willst, bleibt "3 Seiten untereinander ausgeben" nur ein Rätsel.
-
Du könntest nur ein Backup wieder herstellen. Aber das willst Du nicht, denn 4.2.2 schließt eine Sicherheitslücke. Der richtige Weg ist das Theme upzudaten.
-
30 Plugins sind sicher nicht das gelbe vom Ei, machen aber eine Seite nicht per se langsam. Ich kenne Seiten mit über 70 aktiven Plugins die noch unterhalb 2 Sekunden laden. 20 Sekunden TTFB sprechen eine deutliche Sprache. Da gehört erst einmal ein sauberes Performance Profil erstellt, was bei Hostingaccouts aber schwer wird. Am besten einen V-Server mieten, Seite Clonen und dann Profil erstellen.
-
Da 404er Fehler im Theme Verzeichnis auf der Console erscheinen, könnte es sich um eine Inkompatibilität des Themes handeln.
-
Warum für jeden Hersteller ein CPT erstellt werden soll ist unklar, normalerweise würde man den CPT autos erstellen und die Taxonomien Hersteller mit Sub-Taxonomie Modell.
Wenn nun aber jeder Hersteller ein CPT sein muss, bleibt nur die Festlegung des Slugs als /auto/.