nietypowy problem, PHP + MySQL Opcje

[qpeace1]

Witam,
mam na tyle nietypowy problem, że nawet nie wiem jak się zapytać o jego rozwiązanie ;-)


otóż mam tabelę `komunikaty` do której dodaję nowe komunikaty na stronę główną, (budowa tabeli jest identyczna z tabelą `wydarzenia`),

zrobiłem też panel administracyjny z systemem logowania, w którym mogę:
-dodać komunikat
-usunąć komunikat
- edytować komunikat
{to samo dotyczy się tabeli wydarzenia}

utworzyłem też system uprawnień do modyfikacji dla określonych grup userów (ja mam pełne)


Opis problemu
-----------------------------------------------
ostatnio jeden z userów dodał komunikat, który chciałem poprawić,
więc zalogowałem się na moje konto do mojego panelu admin., poprawiłem komunikat i nacisnąłem button [Aktualizuj]
ale nic nie zaktualizowało - jakby tabela odrzuciła prośbę o update

Co dziwne, mogę edytować inne komunikaty zamieszczone przez tego usera, ale tego jednego (ostatniego) nie mowę wyedytować

Nie mam zielonego pojęcia gdzie szukać problemu, wiem tylko, że ten user dodaje komunikaty w trybie wyswig, a ja w panelu administracyjnym witryny używam 'tinymce' i 'fckeditor', ale w tej części tylko 'tinymce', ale bardzo mało prawdopodobne, żeby to 'tinymce' było przyczyną problemu.


Może ktoś z Was miał podobny problem i jakoś go rozwiązał?

[blooregard]

W aktualizowanej treści masz jakiś znak, który powoduje, że całe zapytanie UPDATE jest nieprawidłowe i się nie wykonuje.

Zrób sobie echo tego zapytania, a jeśli tam nie zobaczysz błędu, wklej na żywca do phpMyAdmina i wykonaj.

[qpeace1]

W aktualizowanej treści masz jakiś znak, który powoduje, że całe zapytanie UPDATE jest nieprawidłowe i się nie wykonuje, Zrób sobie echo tego zapytania,

.
zrobiłem echo wszystkich zmiennych użytych w update i wyświetlają się ze zmianami (prawidłowo)

a jeśli tam nie zobaczysz błędu, wklej na żywca do phpMyAdmina i wykonaj.

to równie dobrze mógłbym usunąć ten komunikat i dodać nowy ze zmienioną treścią, ale to obejście problemu a mi chodzi o poznanie przyczyny.

Dodam jeszcze, że tamten user wkleił tekst komunikatu z worda 2007 (często tak robi)


Właśnie zauważyłem, że to problem nie ostatniego komunikatu, ale ostatnich 3 komunikatów (nomen omen ten jest 13-sty ;-))
Ale 10 już poprawiam bez problemu


Ten post edytował qpeace1 3.01.2010, 23:12:46

[blooregard]

zrobiłem echo wszystkich zmiennych użytych w update i wyświetlają się ze zmianami (prawidłowo)

Wyświetl całe zapytanie, a nie same zmienne, i wklej do phpMyAdmina.

to równie dobrze mógłbym usunąć ten komunikat i dodać nowy ze zmienioną treścią, ale to obejście problemu a mi chodzi o poznanie przyczyny.

Właśnie to jest sposób na poznanie przyczyny, bo skutkiem jest to, że UPDATE na tych komunikatach się nie wykonuje.

to równie dobrze mógłbym usunąć ten komunikat i dodać nowy ze zmienioną treścią, ale to obejście problemu a mi chodzi o poznanie przyczyny.

Problem - komunikaty się nie aktualizują.
Przyczyna - UPDATE się nie wykonuje, bo w treści zapytania jest błąd.
Rozwiązanie - wykonaj wyśiwetlone zapytanie na żywca w phpMyAdminie.

[thek]

Ja bym zabawił się albo z propozycją poprzednika (na żywca w PhpMyAdmin), albo zrobił zaraz po UPDATE takie jedno małe coś

[PHP] pobierz, plaintext 
echo mysql_error();
[PHP] pobierz, plaintext 

i popatrzył co mi sypnęło Efekt jest ten sam.

[jarexx]

W zapytaniu UPDATE potraktuj zmienna z danymi funkcja addslashes()

[SQL] pobierz, plaintext 
UPDATE TABELA SET NAZWA_POLA='".addslashes($zmienna)."' WHERE ...
[SQL] pobierz, plaintext 

[qpeace1]

Kiszka ;-(

1) dodałem zaraz po update

[PHP] pobierz, plaintext 
echo $zapytanie;
[PHP] pobierz, plaintext 

i wkleiłem 'na chama' w MySQL

efekt:
MySQL dał komunikat: 414 Request-URI Too Large
po czym rozwaliło mi cały komunikat - same 'krzaki'

nic więc, usunąłem cały komunikat i dodałem ponownie treść jako nowy komunikat (całe szczęście że miałem go jeszcze w cache przeglądarki) - już jako 14 komunikat, teraz ten dodany przeze mnie [14] można edytować, [13] został usunięty, ale dalej nie mogę edytować kilku wcześniejszych komunikatów - przed 13-stym,


PS. odnośnie komunikatu błędu, to google mówi, że "Żądany identyfikator URI (zazwyczaj adres URL) jest zbyt długi i serwer nie może go przetworzyć." - ale tam nie ma żadnego adresu url

2) dodałem zamiast powyższego, zaraz po update instrukcję

[PHP] pobierz, plaintext 
echo mysql_error();
[PHP] pobierz, plaintext 

efekt
brak komunikatu błędu,
brak aktualizacji komunikatu [12]
{czyli brak efektu;-(}

W zapytaniu UPDATE potraktuj zmienna z danymi funkcja addslashes()

[SQL] pobierz, plaintext

1.
UPDATE TABELA SET NAZWA_POLA='".addslashes($zmienna)."' WHERE ...

[SQL] pobierz, plaintext

mam coś takiego:

[PHP] pobierz, plaintext 
if(get_magic_quotes_gpc()) {
            $pole_tytul = stripslashes($_POST['pole_tytul']);         
            $pole_tresc  = stripslashes($_POST['pole_tresc']);
            ...
 
        } else {
            $pole_tytul = trim($_POST['pole_tytul']);                            
            $pole_tresc = trim($_POST['pole_tresc']);
            ...
            }
[PHP] pobierz, plaintext 

----------

i wracam do punktu wyjścia: nie mam zielonego pojęcia co jest grane ;-(

co dziwne, w innych komunikatach (tych powiedzmy od nr 1 w górę do chyba 9,czy 10) można zmieniać treść, a więc zapytanie [update] jest poprawne

Ten post edytował qpeace1 5.01.2010, 00:47:50

[Armstrong]

[PHP] pobierz, plaintext 
if(get_magic_quotes_gpc()) {
$pole_tytul = stripslashes($_POST['pole_tytul']);
$pole_tresc = stripslashes($_POST['pole_tresc']);
[PHP] pobierz, plaintext 

Jeżeli dodaje cudzysłowy dla tablic POST GET ... to ty je usuwasz przed dodaniem do bazy?

Ten post edytował Armstrong 6.01.2010, 07:49:51

[thek]

Jedna rzecz... Skoro slashe usuwasz jeśli magic_quotes są włączone (bo to robi ów IF), to chyba zapomniałeś, że wtedy do bazy leci niezabezpieczone zapytanie. Nie lepiej zrobić:
1. Jeśli magic_quotes włączone - olej sprawę (choć i tak ja bym się zastanawiał jak zabezpieczać inaczej)
2. Brak magic_quotes - addslashes lub mysql_real_escape_string to minimum.