waplet

Izskatās, ka ap 14 tika labots simple bug's un sešos tika salabots palielāks bug's. http://i.imgur.com/HTisMpC.jpg

Kas vainas Wordpressam? Tik pat labi jebkurš CMS ir muļķīgs, jo visos ir bijuši neskaitāmi exploiti.

Noformulē vēlreiz un lēnām. Edit; O, redzi, uzrakstot visu konkrētāk uzreiz ir risinājums.

where vards LIKE '%port%'

WHERE vards = 'port' OR vards = 'airport'

bet varbūt viņam vajag /en/test1?dev=true , lai tomēr aiziet uz /test1.php?dev=true ?

liec kā pirmo rūli. RewriteRule ^(ru|en|lv)/test1(/)? /test1.php [QSA, L] RewriteRule ^(ru|en|lv)$ index.php?lang=$1 [QSA,L] RewriteRule ^(ru|en|lv)/(.*/)?([a-zA-Z0-9_-]+)(/)$ index.php?lang=$1&area=$3 [QSA,L]

++

Parasti Regex ir visa lēnuma avots, skaties vai nevari ieekonomēt uz to?

Paņem kaut kādu konkrētu skaitli, cik ir katrā tabulā. Foreach'o visus ierakstus, kad esošā ierakst kārtas numurs pēc atlikuma no konkrētā skaitļa ir 0, tadā gadījumā ir jātaisa jauna tabula. Vismaz idejiski

Ko nozīmē apmaksāta? 500, 600? Te bez cipara neder.

PHP ir tāds groupBy idejiski?

A pēc kā atlasīt otrajā iterācija?

Izskatās, ka ja "findOne" funkcijai nepadod string'u, tad kā arguments tiek ņemts skaitlis un tiek izpildīts WHERE condition's "WHERE id = $uid". Attiecīgi jāpaskatās dokumentācija kā būtu jābūt, lai "findOne" strādātu pēc tavas "u_id" kolonnas, nevis "id". Iespēhans "->findOne('uid = '. $uid)" vai tml.

DIemžēl kļūdies. Foreach iterē katrai masīva vērtībai cauri un to piesķirts $option mainīgajā.

in case, last == next

Man ir FirstData WooCommerce uzkodēts, ja vajag, par sumām, privāti.

Kāds kļūdas paziņojums? Swedbank'am bija gļuks ar base64 enkodētu parakstu, kad vajadzēja atstarpes ar "+" aizvietot, vai arī otrādāk.

Ja nemaldos, tad XLS mierīgi var eksportēt uz CSV un to jau ar PHP nebūs problēmas nolasīt.

Daudz, kur ir iespējamas SQL injekcijas, netiek sanitaizoti int'i

Ja tu tulkosi tekstu, kas pārsniedz 500 simbolus, droši vien ātr vien sapratīsi, ka tulkojumam nav jēgas

Problem solved, izskatās, ka pie vainas bija mb_strlen, jo nebija norādīts kodējums UTF-8 public static function fs(variable) { return sprintf("%03d%s",mb_strlen(variable,"UTF-8"), variable); }

Tiek rakstīts, kā PHP extension, tāpēc tīrs php netiek izmantots, bet mantojas php funkcijas. valoda ir Zephir

Vai kāds ir tuvakajā laikā saskāries ar banklink datu apstrādi utt? Testēju 0.01 EUR Kā tas nākas, ka veiksmīga maksājuma gadījumā neizpildās paraksta pārbaude , bet neveiksmīga maksājuma gadījumā paraksta pārbaude ir veiksmīga un nav kļūdu. Veiksmīga maksājuma gadījumā datu struktūrā tiek iekļauti: service, version, snd_id, rec_id, stamp, t_no, amount, curr, rec_acc, rec_name, snd_acc,snd_name, ref, msg un t_date,: Taču openssl_verify(uzģenerētā virkne, saņemtais VK_MAC, publiskā atslēga); atgriež negatīvu rezultātu. Bet gadījumā, kad maksājums ir neveiksmīgs jeb VK_SERVICE = 1901 , kur tiek apskatīti tikai : service, version, snd_id, rec_id, stamp, ref, msg , paraksta pārbaude ir veiksmīga. P.s. Pamanīju, ka atstarpes vajag vēl aizvietot ar + simboliem, atgrieztajā MAC'ā , lai pareizi dekodotos Kādi ieteikumi kāpēc tā varētu būt, jo visur izmantoju vienādu konkatenācijas veidu, lai iegūtu MAC'u.. public static function fs(variable) { return sprintf("%03d%s",mb_strlen(variable), variable); } App::fs(method["VK_SERVICE"]) . App::fs(method["VK_VERSION"])...