[wp-hackers] Improving Plugin (and Theme) metadata

[Jacob Santos]

I thought about your arguments for a long time and I've come to the 
conclusion that you are missing my point. It might be that I was just 
unclear, so allow me clarify.

I'm talking about an implementation which has been partially tested, 
shown to partially work, and the new patch should fix all of the 
complaints for the last patch. I'm talking about a patch for a version 
which the behavior is not deprecated, which solves a feature request a 
year old. I'm talking about 10-20 lines. I'm talking about something 
that if it was committed now, could be tested within the month before it 
goes live.

You both are talking about an feature, which has no implementation, has 
no release date (can only make one with an implementation) and by 
estimates, the ticket will be almost two years old when one is released. 
You are talking about a lot of code, which would have to be reviewed, 
debated, and then tested when committed.

I'm talking about fixing the issue for those who will be using 2.5 for 
the three to six months until the new feature is released that 
deprecates the old behavior. I'm talking about implementing a feature 
that most people will continue to use up when the new feature is 
released and continue to be able to use it even after the new feature is 
released.

The new feature could make building plugins a lot easier, safer, and 
with a better feature set than can be supported now. The current plugin 
data method works and has been tested and I believe with some partial 
evidence to support my argument that by committing my implementation 
would benefit a whole lot of people for WordPress 2.5 and beyond until 
the Super Awesome New Method is implemented.

I fully support you and anyone that builds this great feature and if no 
one stands up, then when May comes, I'll take up the challenge. If 
someone else does stand up, they have both my support with testing, 
suggestions, and help, and my appreciation because I'll love you forever 
for making my plugin writing awesome! Until then, I believe this is a 
non issue and if you don't know, we've spent more time debating whether 
the implementation should be WordPress 2.5, than it actually spent to 
write the implementation. You are right that whether I implement it or 
not does not matter, I'm just saying that I won't devote any time to 
something, when I have no extra time to give.

You know, I have no power whether or not the current implementation gets 
in for WordPress 2.5. If Peter and everyone else on the commit team 
thinks this new idea is the way to move forward, then great. However, I 
would be more content if it was a sure thing. I just totally hate the 
idea that something so minor has to go through so much debate, it is 
just crazy. So basically, I'm just politely trying to knock of the 
commit teams doors in the hopes that they'll listen to my reasoning and 
just commit the patch and see where it goes.

Basically, another reason I can't agree with you, is that I've been 
wanting to "replace" the implementation of query and rewrite with 
something more easy to define and more inline with Controller 
functionality. Trying to crack open the query is like drilling a hole in 
my head. I would rather like an easy to use function which adds both the 
rewrite path and query and load my script in the process. However, since 
I've stated this intention, should be just block all enhancements to 
query and rewrite until the new implementation is completed?

I think not and I think this debate is the same.

The debate could easily be ended by marking the ticket as "won't fix" 
and I'll supply a new patch which removes the behavior included in #5651 
patch.


Stephen Rider wrote:
>
> On Jan 25, 2008, at 9:46 PM, Jacob Santos wrote:
>
>> I don't think the current way is going to be replaced. It would be 
>> crazy to go from hundreds, if not thousands of plugins to only a 
>> handful, as I've stated before. Therefore, it makes logical sense 
>> that the current method will be supported for the next few versions.
>
> Certainly.  Agreed.
>
>> Given WordPress awesome backwards compatibility record, I don't 
>> believe the current method is going anywhere within the next few 
>> versions. Perhaps you are going to deprecate it, but it seems 
>> illogical and unreasonable to completely remove it.
>
> I think the idea is to leave the current method working, but if 
> somebody wants to make it localizable, they can use the second 
> method.  Kind of the difference between using strings in a plugin or 
> passing all strings through __() -- adding the __() function didn't 
> stop anybody from ignoring it completely and using plain strings.
>
> I don't believe anybody is talking about deprecating or removing the 
> plain jane meta-data-in-a-comment method.  This is an enhancement, not 
> a replacement.
>
>> I don't believe it is going to be removed, but I have no authority on 
>> that matter, you do! However, I'm sure you'll see the reasoning. 
>> Right now there is a chance to fix it for WordPress 2.5, and let me 
>> explain.
>>
>> 1. The patch is simple, should not cause any huge problems, once the 
>> issues are addressed and trust me by this weekend they will be. The 
>> counter to this is that by adding this feature, WordPress will then 
>> have to support it and supply fixes for something that is going to be 
>> eventually deprecated.
>
> _THAT_ is the reason not to do a "quickie" fix that is effectively 
> going to be deprecated before anybody even sees it.  Doing a new 
> method for v 2.5, just to replace it with a _different_ methodology in 
> 2.6 is a bad move, because either the next version of WP will screw up 
> plugins for 2.5, OR we will then have to support two different methods 
> (three!) for the forseeable future.  It's a short term fix that will 
> add unnecessary overhead in the future.
>
> [...]
>> 2. The patch will get plugin developers ready for the eventual 
>> improved solution, which also uses gettext. So you have a fix for 
>> WordPress 2.5 that uses gettext and to the user, it will appear to be 
>> a bump up in an already established feature.
>
> They both use gettext, but that's under the hood code.  You're talking 
> about introducing one method, and then a second that is not compatible 
> with the first.
>
>> 3. We don't have an implementation right now that replaces the 
>> current behavior. My interest is almost diminished to be honest, so 
>> I'm unsure if I will devote time to a project that won't see the 
>> light of day until probably June or July. That is only if it is 
>> completed by April. If an implementation is not completed by April, 
>> then it is unlikely that it will get into 2.6, so it will be skipped 
>> to 2.7. By then interest will be completely diminished and as there 
>> probably won't be a huge interest in this feature, it may completely 
>> die before 2.8 comes out.
>
> I'm sorry if the (probably) one version delay makes you lose interest 
> in WordPress, but respectfully, this community has a responsibility to 
> look after the project, not the interest level of one coder.  No 
> disrespect intended there, but shoring up your interest level is not 
> cause to implement an ill-advised plan.
>
>> 4. The current method isn't going away, so it might as well match 
>> functionality for internationalization for developers as much as 
>> possible.
>
> Not sure what that statement means, actually....
>
>> I'll say, that for myself, I would rather have a fix in 2.5, in the 
>> event that the worst case comes to pass. Not that I don't have faith 
>> in your skill, but that I don't have faith in anything that is so 
>> unsure. Plus, there have been several times that interest on a 
>> project has peaked and then died shortly thereafter with barely a 
>> whimper (of course, I say that after several months of finally doing 
>> something about an issue that has peaked and died many times).
>>
> I suggested a plan that I thought would work well, and it _does_ short 
> of the fact that .pot editors won't harvest the string automatically.  
> Okay, that's a problem, and requires things to be done differently.  
> I'm not going to walk away just because things don't go the way _I_ 
> want them to.
>
>>
>> You know, if you are planning on getting this awesome feature into 
>> 2.6, then I'll totally bow to you and will build an idol in your 
>> image. However, do consider my arguments on why something should be 
>> done in WordPress 2.5.
>>
>> Peter Westwood wrote:
>>> I am not comfortable with introducing one solution for localisation now
>>> when we are already talking about replacing it with something better.
>
> Peter makes me look long winded.  That sentence is my entire argument 
> tied up with a pretty red bow.
>
> Stephen
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers


-- 

Jacob Santos

http://www.santosj.name - blog
http://funcdoc.wordpress.com - WordPress Documentation Blog/Guide Licensed under GPLv2

Also known as darkdragon and santosj on WP trac.