[wp-hackers] Caching as part of the core

[Almog Baku]

Sorry, I've just not understand you..
There is minification at 3.4.1? If there is.. where?..

And about the caching interface in the current basic/common hooks.. what?

On Tue, Jul 24, 2012 at 6:19 PM, Otto <otto at ottodestruct.com> wrote:
> Minification and combination of JS/CSS files is already in there for
> the admin, and also not part of "caching" in any real way.
>
> -Otto
>
>
> On Tue, Jul 24, 2012 at 9:58 AM, Almog Baku <almog.baku at gmail.com> wrote:
>> As I type before- I would like to see references for the cache at the basic
>> use of the api. so the system will calculate the caching automatically(with
>> sidebars, files, widgets, etc) excepts for other registrations..
>>
>> Quote:
>>
>>
>> On Sat, Jul 21, 2012 at 2:17 PM, Almog Baku <almog.baku at gmail.com> wrote:
>>>
>>> I think that if we will insert basic caching into the api it would fore
>>> the plugins-developers to deal with caching.
>>> Actually, it pretty simple- and the user will able to disabling this
>>> featue.
>>>
>>> The base caching/optimization will include:
>>>
>>> minification: html, js, css:
>>>
>>> interface:
>>> wp_enqueue_script( $handle, $src = false, $deps = array(), $ver = false,
>>> $in_footer = false, $minify=AUTO_MINIFY )
>>> wp_register_style( $handle, $src, $deps = array(), $ver = false, $media =
>>> 'all', $minify=AUTO_MINIFY )
>>>
>>> combination: combine js, css files:
>>>
>>> interface:
>>> wp_enqueue_script( $handle, $src = false, $deps = array(), $ver = false,
>>> $in_footer = false, $minify=AUTO_MINIFY, $combine=AUTO_COMBINE )
>>> wp_register_style( $handle, $src, $deps = array(), $ver = false, $media =
>>> 'all', $minify=MINIFY_DISABLED, $combine=AUTO_COMBINE )
>>>
>>> basic object caching- at least as api interface without implemention!:
>>> extending the object caching api: adding option to control the object
>>> caching within the development- like widgets, pages, etc
>>>
>>> interface:
>>> register_sidebar(array(
>>>     'name'     => __( 'Post Sidebar'),
>>>     'id'     => 'post-sidebar',
>>>     ...
>>>     'cache'    => AUTO_CACHE,
>>> ));
>>> register_nav_menus(array(
>>>     'top_nav' => __( 'Top Navigation'),
>>>     ...
>>>     'cache'    => AUTO_CACHE,
>>> ));
>>> register_post_type('slider', array(
>>>     'label' => __('Slider'),
>>>     ...
>>>     'cache'=> AUTO_CACHE,
>>> ));
>>>
>>>
>>> Insert this minor changes into the api will able the caching plugins or
>>> future core-caching-system to handle with caching!
>>
>>
>> On Tue, Jul 24, 2012 at 3:38 PM, Ryan Hellyer <ryan at pixopoint.com> wrote:
>>
>>> +1
>>>
>>> Lots of waffle, but no explanation of what should actually be
>>> improved. We have object caching. We have persistent caching that
>>> defaults to object caching when available (ie: the transients API).
>>>
>>> Is it possible that what you guys are actually wanting is a persistent
>>> disk caching caching API? If so, then I guess that could be added via
>>> the transients API, maybe as an extra argument. The disk caching API
>>> could perhaps default to object caching when available, just as the
>>> regular transients do.
>>>
>>> On Tue, Jul 24, 2012 at 1:32 PM, Otto <otto at ottodestruct.com> wrote:
>>> > What more is needed? You speak about adding a caching API of some
>>> > sort, but you completely fail to address what actually is in this
>>> > magical API that would be useful or even valuable.
>>> >
>>> > -Otto
>>> _______________________________________________
>>> wp-hackers mailing list
>>> wp-hackers at lists.automattic.com
>>> http://lists.automattic.com/mailman/listinfo/wp-hackers
>>>
>> _______________________________________________
>> wp-hackers mailing list
>> wp-hackers at lists.automattic.com
>> http://lists.automattic.com/mailman/listinfo/wp-hackers
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers