feature(transients): as autoloaded options
Merge request reports
Activity
requested review from @sebastian.pisula
assigned to @dyszczo
- Resolved by Sebastian Pisula
410 } 411 } 412 413 return false; 414 } 415 416 /** 417 * @param array $plugins 418 * @param bool $use_transients 419 * @param int $current_time 420 */ 421 private static function update_plugins_data_in_cache( $plugins, $use_transients, $current_time ) { 422 if ( $use_transients ) { 423 set_transient( self::PLUGIN_INFO_TRANSIENT_NAME, $plugins, self::CACHE_TIME ); 424 } else { 425 update_option( self::PLUGIN_INFO_TRANSIENT_NAME, json_encode( array( Tutaj robią jakieś testy wydajności i rozmiarów danych: https://stackoverflow.com/questions/804045/preferred-method-to-store-php-arrays-json-encode-vs-serialize
Dane w json zawsze są mniejsze, ale json_decode jest wolniejszy od unserialize. Sam nie wiem co lepsze w związku z tym.
@dyszczo jakie masz argumenty za i przeciw?
Myślę, że wszystko jedno. Argumenty za JSON są takie, że ma on jakiś sens w bazie danych: są na przykład natywne funkcje w bazie danych które pozwalają na operowanie tym formatem. Serializacja PHP jest tylko dla PHP, a poza tym jest zapisana w taki sposób, że zmiana kodowania może wywalić całą serializację (zapisywane są długości, a te mogą się zmieniać w zależności od kodowania). Z drugiej strony WP ją wspiera. Normalnie bym mówił, że zdecydowanie json, w wordpressie mówię, że jak sobie marysia życzy
😄 changed this line in version 3 of the diff
generalnie jestem za JSON (np w app shopify custom dane są trzymane jako JSON - https://www.doctrine-project.org/projects/doctrine-orm/en/2.15/cookbook/advanced-field-value-conversion-using-custom-mapping-types.html)
ale przez to, że to WP, które w (add|update)option, (add|update)(post|user|term)_meta itd używa serialize natywnie to moim zdaniem niepotrzebnie dodatkowo to konwertujemy JSON<->ARRAY.
removed review request for @sebastian.pisula
mentioned in commit db0c8887