CodeStyling Localization verursacht leere Seite

"weiße Seite" oben in die Suche eingeben und du weist warum(meist Memory_Limit)

Aber wenn du die Möglichkeit hast lokal das Plugin anzuwenden, warum zusätzlich auch noch auf dem Server?
Du kannst ja alles lokal übersetzen und musst nur die erstellten Dateien hochladen.
Je weniger Plugins auf dem Server sind um so besser :wink:

Zitat von Sunny01

deren Seite her maximalen Wert

stellt sich die Frage was deren maximaler Wert ist und ob der für dieses Plugin ausreichend ist
ist ja auch abhängig davon was alles an Themes, Plugins usw. installiert und durch das Plugin gescannt wird

Zitat von Sunny01

Ich habe auch nicht gerade den Eindruck, dass Wordpress auf das (außerhalb der Blog-Szene) konventionelle Prinzip der lokalen Entwicklung und dann des Uploads auf den life-Server ausgelegt ist. Beispielsweise werden an allen möglichen Ecken und Enden absolute Pfade von Wordpress geschrieben!

In Zukunft will ich den Blog nur mehr online erweitern (sowohl inhaltlich wie auch technisch gesehen), ich sehe ja jetzt, wieviele Probleme bei der Migration von lokal auf online auftreten.

kann ich nicht nachvollziehen, hab meinen Privaten Blog parallel lokal auf dem PC und mache alle Änderungen da
erst wenn lokal alles passt lade ich die Dateien hoch und das ohne Probleme
gleichzeitig spiele ich die jeweils aktuelle online Datenbank auf das lokale System
auf diese Art habe ich auch immer ein aktuelles Backup (Dateien und Datenbank)

Zitat von Sunny01

Und irgendetwas stimmt mit diesem Plugin nicht.
Die Frage ist, was könnte das sein?

Funktioniert bei mir ohne Probleme und bei dir wie du schreibst lokal ja auch, somit ist die online Serverkonfiguration wohl das Problem nicht das Plugin

Zitat von Sunny01

Ja. Wie kann ich feststellen ob er für das Plugin ausreicht?

wie viel hast du denn, bei mir sind es 128M und da hat es funktioniert
wobei ich das Plugin ja nicht mehr online nutze, wird ja eh nur bei Änderungen benötigt und muss so nicht ständig mitlaufen
kannst ja z.B. auch mal nicht verwendete Themes löschen

Zitat von Sunny01

Wie machst Du das? Wie hast Du es hinbekommen, dass die Pfade dann in der Datenbank immer korrekt sind, auch zu Bildern und Bildergalerien usw.?

nun WP / Themes / Plugins / CSS ist ja bis auf die Domain(nur 2 Anpassungen) lokal/online identisch
Artikel erstelle ich nur online, somit habe ich die richtigen Pfade auch in der lokalen Datenbank.
Heißt die Bildpfade(in Artikeln) der lokalen Installation, greifen auf online Bilder zu.
Wenn du natürlich lokal Artikel erstellst, muss du die Pfade anpassen.
Aber auch dafür gibt es ein Plugin, das dies automatisch ändert.

Search and Replace

oder ohne Plugin selbst in der Datenbank ändern

lokale Adresse durch Domain tauschen

UPDATE wp_posts SET post_content = replace(post_content, 'http://localhost/wordpress/', 'http://deinedomain.de/');

Zitat von Sunny01

Hallo!

Meinen Blog habe ich lokal entwickelt und nun auf einen Webserver hochgeladen. Allerdings verursacht das CodeStyling Localization Plugin Probleme: Sobald ich es hochlade und auf aktivieren klicke, wird mir im Adminbereich nur mehr eine leere weiße Seite angezeigt. Ich muss den Ordner per FTP löschen um wieder auf den Adminbereich von Wordpress zugreifen zu können.

Andere Plugins sind derzeit nicht vorhanden. Ich habe versucht statt einem Upload von meinem lokalen Blog das Plugin neu zu installieren, doch es tritt derselbe Effekt auf. Weiters habe ich alle php-Dateien des Plugins mit einem Editor geöffnet, leere Zeilen am Anfang und Ende der Datei entfernt und fehlende php-Schließtags am Seitenende ergänzt. Doch keine Abhilfe, es funktioniert weiterhin nicht.

Lokal lief (und läuft) das Plugin.

Wie kann ich das Problem lösen?

Lg
sunny

Alles anzeigen

Ein Problem dieser Art mit meinem Plugin ist mir noch nie begegnet. Im aktivierten Zustand ohne auf die Pluginseite zu gehen, verbraucht das Plugin minimale Resourcen und Speicher.

Welche Version der Plugins setzt du ein?
Welche PHP Version ist bei dir beim Provider aktiv?
Ist das ein Apache (linux) basierter Server oder Windows IIS basiert?
Hat der Provider dein Möglichkeiten limitiert?

Aktuell ist die Version 1.99.29 mit einer Menge Anpassungen für einige Bugs. Unter anderem was bis 1.99.29 eine .htaccess Datei im Plugin Ordner, welche aber auf manchen Systemen zum Absturz führte bzw. ein Update verhinderte.
Kannst du bitte mal das Plugin auf dem Webspace per FTP (ganzen Ordner) löschen und dann vom Repo die 1.99.29 installieren?

Zitat

Version 1.99.29

• Bugfix: removed .htaccess file inside plugin folder
• Bugfix: improved javascipt exception handling within jQuery initializer chains
• Bugfix: updated re-introduced js libraries

Version 1.99.28

• Bugfix: function missing in very old WordPress versions covered
• Bugfix: Scripting Guard now detects broken ready handler of injected javascripts
• Bugfix: redirection of prototype/scriptaculous done only, if WP version >= 3.5-alpha

Version 1.99.27

• Bugfix: WordPress version 3.5 starts removing prototype.js and scriptaculous but falls back to google CDN include which brokes JSON requests
• Bugfix: CDN verification returned an error object and caused a fatal error if external script can't be verified
• Bugfix: german translation contains untranslated terms
• Bugfix: compatibility improved and checked, still compatible with WordPress >= 2.5

Version 1.99.26

• Bugfix: WordPress version 3.5 starts removing prototype.js and scriptaculous but falls back to google CDN include which brokes JSON requests
• Bugfix: CDN verification returned an error object and caused a fatal error if external script can't be verified
• Bugfix: german translation contains untranslated terms
• Bugfix: compatibility improved and checked, still compatible with WordPress >= 2.5

Version 1.99.25

• Bugfix: trim of string sometimes broken like: 'Result: \'text\''
• Bugfix: 'Domain Path' of plugins will be accepted if set and existing
• Bugfix: uppercase letters used at folders or filenames did break the file handling
• Bugfix: SSL fully supported, all scripts stripped accidentally
• Bugfix: multisite support accidentally sometime broken
• Bugfix: accidentally markup polution
• Bugfix: theme detection for WP >= 3.3 was broken
• Bugfix: statements of memory limits with 0MB indicates mostly misused translation functions at themes/plugins, handled now (e.g. target theme, single.php).
• Bugfix: pofile sometimes created with wrong pluralization
• Bugfix: mofile didn't got the correct pofile header and loads afterwards the wrong pluralization function
• Feature: misused translation functions mapped into artificial textdomain '{bug-detected}' and excluded from mo file generation
• Feature: Scripting Guard supports now 'debug-bar', 'debug-bar-console', 'wp-native-dashboard'
• Feature: Scripting Guard now monitors PHP script errors provoked by other plugins/themes during page generation

Alles anzeigen

Zitat von Sunny01

Ich habe jetzt doch den Speicher nochmal erhöhen können (256 M), und siehe da, das Problem tritt nun wirklich nicht mehr auf.

Mich würde für Testzwecke interessieren, welchen Wert du vorher hattest.

Für ein 64bit System und WP3.5 ist das zu wenig, wenn Plugins laufen.
Folgende Werte sind für WP grobe Minimum Richtwerte, wenn man vernünftig arbeiten will:

OS Platform Plugin Erweiterungen Standard WP 3.5 Multisite WP 3.5
32bit wenig 48M 64M
32bit viel 64M 80M
64bit wenig 70M 128M
64bit viel 128M 128M

Das sind Erfahrungswerte und schwanken stark, je nachdem, wie der Provider die entsprechenden OS konfiguriert hat. Es kann auch mit weniger gehen, aber 40M sind für WP 3.5 teilweise viel zu wenig.