[wp-hackers] Minify Scripts and CSS and why it isn't completely
possible
Gaarai
gaarai at gaarai.com
Tue Dec 23 15:17:29 GMT 2008
I never saw anyone claim that you shouldn't use any functions that begin
with wp_, but I have seen on the Automattic site where they say that
coders shouldn't use the widget functions that begin with wp_. I use
them anyways since there isn't any other way to provide full widget info
without them.
As for the original question that you had Jacob, I have to say that
using the API for styles and scripts is not straight-forward at all. At
first, I didn't use them at all since the hooks you should user aren't
well documented which resulted in either calling that function too early
(resulting in errors) or too late (resulting in no css or js inclusions).
After finally figuring out action sequences on my own, I started using
them more, but then I had other problems. I assumed at first that the
call somehow /knew/ when to include or not include my css and js (a
stupid assumption, I know). I would write really nasty code to keep
track of when the inclusions should or should not be made.
It took me much longer to figure out how to store the resulting page
name from latching into the menu system and then using that create
actions for specific page views. Out of everything I've mentioned so
far, this is by far the most poorly documented of the lot.
So, Jacob, I would have to say that the problems are as follows:
1. There is a wealth of information on the Codex, but it has three
fundamental problems:
1. There is so much information in there, that a new plugin
developer will either never read specific areas before
trying to code something or will have forgotten about
something by the time they need it. This results in them
finding something that "just works" which they most likely
will stick with until someone tells them otherwise or they
randomly stumble on the information.
2. Despite the fact that there is so much information, I find
that more often than not, the Codex fails to provide detail
where detail would be extremely helpful. In addition, I
often find the examples to be obscure at best and may show
the specific line of code but none of the surrounding lines
that are actually needed in order for that section of code
to make sense and to actually function appropriately.
3. Most WP developers (myself included), spend very little time
working on the Codex. Personally, I know that I've only
contributed significant changes to the get_posts().
2. Even though WP.org is a community, I find very little community
involvement when it comes to development in Extend. People put
plugins and themes on there, some people use it, some people
don't, and that's the end of it.
3. There is little perceived benefit to coders to meet the (unknown)
expectations of other coders.
So, there are the problems, what are the solutions? That is a very tough
question, but here are some ideas that I have.
* I think most people will agree that getting more people involved
in Codex updating would be a good thing, so I think we need to do
some things to encourage that:
o A particularly complex function should be selected by a very
capable coder that knows the Codex and the community well.
This coder needs to create the ultimate Codex documentation
page for that function. This page can then become the
framework which all other pages can be updated/created to
match. This will provide consistency in information and will
ensure that contributions are easy to do as little thought
will need to be given to presentation of the information as
a guideline is available.
o After creating this ideal framework for pages, a group of
Codex "editors" should go through all the Codex and mark
pages as needing updates in order to match the new
presentation format. This notice of needing updates should
include a link to the page that shows the ideal
presentation. This will help people unfamiliar with this
discussion know what they need to do without looking elsewhere.
o Have monthly Codex days. On these days, an announcement will
come out on this list for coders to "adopt" a Codex page for
the day. Coders will reply with what page they are adopting,
so that way other editors know to leave that page alone as
someone is working on it.
* I talked with you about this way back at WordCamp Dallas, but it
still hasn't happened and still needs to be done. The community
would benefit greatly from a how-to plugin. Basically this plugin
would essentially do nothing, but it would provide developers a
best-practice view of how to do specific things. I've been working
on one on and off for the past few months, but I really need to
get other people involved. This plugin would be added to Extend so
as updates come out, developers can always have easy access to the
latest and greatest examples of how to do specific things (such as
easily add css and js files).
* The forums desperately need to be restructured. I am an avid fan
of forums and over the past few years have spent large quantities
of time in forums of various topics, but I loath going to the
WP.org forums. Honestly, I don't know what it is about the forums
that I dread, but every time I look at them, I feel like I'm
looking at pea soup. There needs to be a better way to structure
things in order to make things easy to find. Also, providing
advanced tool such as showing new topics since last visit, show
only unanswered posts, subscribe to thread (not just an RSS feed),
etc can greatly aid those that want to help out as much as
possible on the forum.
* Get a better search. The entire site needs a search overhaul.
o If I want to find the Codex page for the get_posts function,
I find myself doing the following: searching for get_posts,
changing to only search documentation and searching again,
finding that the page I want isn't even on any of the first
three pages of results, clicking on each of the first
results while searching for a link to the page I want, and
then clicking on the get_posts link inside the fourth search
result. There has to be a better way.
o I don't think I even need to get started on searching in Extend.
* The community needs to get more involved with helping people who
submit content to Extend. In other words, we need to have a sort
of peer review. Technically, there is nothing limiting us from
doing this right now, but from what I can tell, it doesn't happen.
This would go a long way to improving the quality of themes and
plugins available on Extend as well as go a long way to increase
the amount of plugins and themes available as coders/designers
know that there is a helpful community ready to assist them.
* We need to find ways to get more people involved. I think that the
Developer Center for Plugins and the More Info for Themes should
provide people with links to help them get started. In addition,
it should tell people about the existence of this list, point them
to the forum, and give them a quick rundown on the Codex. As it
stands now, it looks like they are on their own, why not
explicitly show them that there is in fact a community behind all
of this?
Sorry for the rambling. It seems like I got off-topic, but in reality,
these issues all trickle down to influence coders' use or disuse of the
script/style API. I hope that this can be helpful.
Chris Jean
http://gaarai.com/
http://wp-roadmap.com/
Jacob Santos wrote:
> It has never been true that you shouldn't use functions that start
> with wp_. Whoever said that to you was either lying or was or still is
> a fool.
>
> You can read about the Scripts and Styles API at these locations:
>
> http://trac.wordpress.org/browser/trunk/wp-includes/class.wp-dependencies.php
>
> http://trac.wordpress.org/browser/trunk/wp-includes/functions.wp-styles.php
>
> http://trac.wordpress.org/browser/trunk/wp-includes/functions.wp-scripts.php
>
>
> Ignore the suggestion to read WP_Scripts::add() and WP_Styles::add().
> That method is actually part of WP_Dependencies. I suppose an article
> on the Codex might also help it seems.
>
> You'll probably want to enqueue scripts and styles, but you can also
> register them.
>
> Jacob Santos
>
> dave jaggy wrote:
>> By the way, what exactly is meant under Scripts and Styles API?
>> wp_enqueue_script and wp_enqueue_style? Is there anything more? How I
>> can
>> read about that, if - yes.
>>
>> And I guess there was somewhere mentioned that one shouldn't use
>> function
>> starting with wp_, is it still true?
>>
>> Dave
>>
>>
>> On Tue, Dec 23, 2008 at 4:08 PM, Viper007Bond
>> <viper at viper007bond.com>wrote:
>>
>>
>>> On Mon, Dec 22, 2008 at 7:27 PM, Jacob Santos <wordpress at santosj.name
>>>
>>>> wrote:
>>>> Why don't more plugin and theme authors use the Scripts and
>>>> Styles API?
>>>>
>>> Because it's relatively new and not all plugin authors are good coders.
>>>
>>> --
>>> Viper007Bond | http://www.viper007bond.com/ | http://www.finalgear.com/
>>> _______________________________________________
>>> 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
>
More information about the wp-hackers
mailing list