Beiträge von codestyling

Mal ein Zitat zum gleichen Problem aus dem Joomla Forum:

Zitat

Danke für die schnelle Antwort - anbei die Antwort zusammengefasst vom supportteam bei hosteurope.
...
Problem 1 besteht.
Wenn Verzeichnisse oder Dateien über ein Script angelegt werden, erhalten diese immer den User "nobody" und man kann die Rechte über den FTP Client nicht mehr ändern. Hier ist es erforderlich, dass Sie die Rechte der betreffenden Dateien und Verzeichnisse mit einem PHP-Script ändern.
Problem 2 gelöst.
Wenn es Ihnen jedoch aktuell nur um die Löschung bestimmter Verzeichnisse und der darin befindlichen Dateien geht, können Sie diese auch im KIS löschen.

Alles anzeigen

Da stimmt die Sprachumsetzung in deiner comments.php nicht. Ist ja alles englisch, deswegen sicher auch das Datums/Zeitformat.
Doch diese müsste man erstmal sehen, um zu verstehen, warum das so aussieht.

Zitat von Gersprenz

Dies ist eine typische Einstellung vieler Webhoster, glaube ich.

Das glaub ich weniger. Mein Provider macht da keinen Senf drum, ich hab alle Berechtigungen die ich brauche und kann die auch setzen. Es wäre ja mal ein Ansatz, zu schreiben, welchen Provider du hast, damit man qualifiziert nachkommen und Support leisten kann.

Wenn du nicht moderierts, dann schon. Aber das kannst du nicht verhindern, wenn man sich bei dir nicht einloggen muß zum Kommentieren.
Nur durch Moderation oder Kommentieren durch Anmeldung kannst du das begrenzen, sonst leider nicht (oder nur täglich lesen und korrigieren :))

Der Autor wird so getestet:

<?php
if($comment->comment_author_email == get_the_author_email()) {
   //hier ist Author
}
else{
   //das sind alle anderen
}
?>

Wie wärs mal mit eine wenig english und dem Forum des Autors: Graph Paper Press Forum - Images a no show on home page
Dort steht, des es für WP 2.6 ein Update braucht.
Ausserdem ist dafür ja das Forum des Autors zuständig.

Da ich nicht weiss, ob du ein IntelliTXT Plugin benutzt oder den Code selbst einbaust, würde ich vorschlagen, dieses erstmal zu deaktivieren. Wenn es dann wieder sauber dargestellt wird, müsstest du im Falle eines Plugins den Autor um Fehlerkorrektur bitten.

Wenn es an der Sprachdatei scheitert aber ohne funktioniert, würde ich wetten, dass es diese Ursache hat: Code Styling Project » WordPress Fehler durch Sprachdateien - die Ursache
Eventuell hilf dieser Patch. Ein neuer Patch, nachdem ich die Ursache gefunden hab, ist in Arbeit, denn dieser hier Code Styling Project » WordPress Sprachdateien erzeugen Fehler in gettext.php hilft nicht auf allen Systemen.

Die Funktion comments_number ist so definiert:

/**
 * comments_number() - Display the language string for the number of comments the current post has
 *
 * @since 0.71
 * @uses $id
 * @uses apply_filters() Calls the 'comments_number' hook on the output and number of comments respectively.
 *
 * @param string $zero Text for no comments
 * @param string $one Text for one comment
 * @param string $more Text for more than one comment
 * @param string $deprecated Not used.
 */
function comments_number( $zero = false, $one = false, $more = false, $deprecated = '' ) {
    global $id;
    $number = get_comments_number($id);


    if ( $number > 1 )
        $output = str_replace('%', $number, ( false === $more ) ? __('% Comments') : $more);
    elseif ( $number == 0 )
        $output = ( false === $zero ) ? __('No Comments') : $zero;
    else // must be one
        $output = ( false === $one ) ? __('1 Comment') : $one;


    echo apply_filters('comments_number', $output, $number);
}

Wie es bei jeglichen Übersetzungsmodulen, die auf gettext beruhen üblich ist, gibt es nur eine Unterscheidung für 0 | Einzahl | Mehrzahl. Deshalb müsstest du für den 2. und 3 Paramter das Ergebnis einer von dir geschriebenen Funktion reingeben, der du den aktuellen Kommentarzähler übergibst und den richtigen Text zurückgeben lässt. Bloß dann kannst du auch gleich das als Code hinschreiben und brauchts die comments_number nicht.

Deine IntelliTXT baut Tables, die ineinander geschachtelt sind, aber die äussere ist nicht beendet worden!

<table border="0" cellspacing="0" cellpadding="0">
<tbody>
<tr>
<td width="300" valign="top"></td>
<td align="right" valign="top"></td>
</tr>
<tr>
<td colspan="2">
<div id="intelliTXT">
<table class="ImgFormat" style="float: right ! important;" border="0" cellspacing="0" cellpadding="0" width="135" align="right">
<tbody>
<tr>
<td width="5"><img style="border: 0px none;" src="http://gamepro.de/img/0.gif" alt="" width="5" height="1" /></td>
<td><a href="javascript:MM_ImgDetail(1214040,1307071,'EL_12163929798284923584664');"><img src="http://gamepro.de/imgserver/bdb/1214000/1214040/135x.jpg" border="0" alt="" /></a></td>
</tr>
</tbody>
</table>

Was soll das bringen ? Was machst du beim 13. Kommentar ? Ein wenig Hintergrundinformation ist schon nötig, denn dass, was du schreibst, ist unlogisch.

Das solltest du in PHP so lösen können:

<?php if (!is_admin()) { ?>
.... hier deine Script ausgeben ....
<?php } ?>

dann werden die nur ausgegeben, wenn du nicht im Admin Bereich bist.

Da deine Seite(n) offensichtlich bei 1und1 gehostet sind und du noch PHP/4.4.8 im Einsatz hast, aber einige Plugins dazu übergegangen sind nur mit PHP 5 sauber zu arbeiten, solltest du umstellen auf PHP 5 zum Test.

Das geht bei 1und1, indem man an den Anfang der .htaccess Datei folgendes einfügt:

AddType x-mapp-php5 .php
AddHandler x-mapp-php5 .php

Viele Plugins laufen dann erst rund, wenn sie durch PHP 5 ausgeführt werden. Sobald du die .htaccess so geändert hochgeladen hast, wird alles mit PHP 5 bei dir ausgeführt. Dann solltest du nochmals testen.

Sollte eigentlich komplett aus sein durch

define('WP_POST_REVISIONS', false);

wenn man das in die wp-config.php einfügt.
Falls Artikel bereits eine Revision haben, dann kann es sein, dass diese noch weitergeht, aber neue Artikel/Seiten sollten dann keine mehr haben.

Wenn dein Hoster Pear text/diff bereitstellt, kann es zu Konflikten kommen, denn WP bringt sicherheitshalber seine eigenen Files mit und verzichtet auf Pear. Deshalb kann auch dein Wiki funktionieren aber WP nicht. Der Patch könnte helfen, denn wenn es dort endet und du alle Fehlermeldungen unterdrückst (oder dein Provider) dann kann das ggf. so aussehen.

Wenn das tatsächlich zweifelsfrei nur von diesem Plugin angelegt und benutzt wurde, dann kannst du die Tabelle löschen. Da du das Plugin ja schon gelöscht hast (und so mit nicht mehr einsetzen willst), wäre das dann ok.
Und WP selbst legt so eine Tabelle nicht an oder benutzt sie.

Das könnte dir weiterhelfen, weil deine Fehlerbeschreibung recht dünn ist, vermute ich dieses Problem: http://forum.wordpress-deutschland.org/installation/3…html#post179032

Einfach die Übergeordnete Kategorie neu anlegen.
Dann alle bestehenden Kategorien der Reihe nach aufrufen (bearbeiten im Admin Bereich) und im Feld Oberkategorie die neue Kategorie auswählen.

Nicht alle Plugins sind zu neueren Versionen von WP automatisch kompatibel. Falls es Probleme mit Plugins gibt, ist die 1. Anlaufstellen immer dessen Autor, den man nach Kompatibilität mit WP 2.6 befragt oder dort ggf. schon eine angepasste Version findet.

Für alle, die solche unschönen Fehlermeldungen bekommen, wenn sie Artikel oder Seiten bearbeiten wollen:

Warning: ini_set() has been disabled for security reasons in /srv/www/httpd/phost/l/de/pytalhost/laz/web/wordpress/wp-includes/pluggable.php on line 1517
Warning: require_once(Text/Diff/Renderer.php) [function.require-once]: failed to open stream: No such file or directory in /srv/www/httpd/phost/l/de/pytalhost/laz/web/wordpress/wp-includes/Text/Diff/Renderer/inline.php on line 17
Fatal error: require_once() [function.require]: Failed opening required ‘Text/Diff/Renderer.php’ (include_path=’.:/srv/www/httpd/phost/l/de/pytalhost/laz/web’) in /srv/www/httpd/phost/l/de/pytalhost/laz/web/wordpress/wp-includes/Text/Diff/Renderer/inline.php on line 17

und der Editor dann nicht mehr funktioniert, hab ich einen Patch programmiert.

Ursache des Fehler (siehe 1. Warnung): in_set() wurde von Provider gesperrt.
Die neue Versionsverwaltung versucht temporär, den include_path für die nötigen Dateien zu setzen und dann wieder herzustellen, was in beiden Fällen nicht geht. Daraufhin kann keine der nötigen Dateien geladen werden, was zu fatalen Abbruch des PHP Scriptes führt. Und nichts geht mehr.

Ich hab das so geändert, dass es ohne ini_set() auskommt und sauber funktioniert. Das Patch-Set gibt es hier: Code Styling Project » WordPress 2.6 und die Text/Diff Fehler im Editor
Ich werde das ggf. WP Bug Trac melden, wenn es nicht schon gemeldet ist.