[wp-hackers] Minify Scripts and CSS and why it isn't completely possible

[Jacob Santos]

Sorry, I've attempted to write a comprehensive developer manual several 
times, but I've just never had enough motivation. It is really difficult 
to do something like what Automattic is planning with a DocBook type 
User Manual (See Matt Mullenweg interview). I doubt it will include 
developer related topics such as these.

I suppose again the problem when you say that the community should do 
something, is that really they don't have to do anything. That is the 
problem and has always been the problem. Well, inline documentation 
should really be written by the core developers and the ones that submit 
patches. That said, a lot of arguing was made with much ado about 
nothing. Nothing was done for the longest time. Really it took something 
being accomplished first before it really took off.

If you feel strongly about something, I suppose the best advice is to 
bear the cross for as long as possible until someone walks by and gives 
you a hand. Even if the article does exist, there is no telling whether 
anyone will use it. Backwards compatibility is a strong argument, which 
has very weak counters.

Jacob Santos


Gaarai wrote:
> 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/