[wp-hackers] Two new, long-overdue plugins to make your wordpress life a little easier...

[Marcus Pope]

Yes, I will, and I'm sorry for saying every single url, I corrected myself in another reply to say it does not correct content urls.  But grep for http/https and is_ssl to see what I am referring to.  The wordpress core processes those urls to substitute the scheme when served over SSL.  There are four strategies at use: str_replace, preg_replace, parse_url and substr.  

That is post-processing that happens on the wordpress core.  I have recently submitted a patch to abstract the copy-pasted logic into a central function for future refactoring.

http://core.trac.wordpress.org/ticket/19037


-----Original Message-----
From: wp-hackers-bounces at lists.automattic.com [mailto:wp-hackers-bounces at lists.automattic.com] On Behalf Of Mike Little
Sent: Friday, October 28, 2011 5:14 PM
To: wp-hackers at lists.automattic.com
Subject: Re: [wp-hackers] Two new, long-overdue plugins to make your wordpress life a little easier...

On Fri, Oct 28, 2011 at 22:35, Marcus Pope <Marcus.Pope at springbox.com>wrote:

> Mike, I hear you.  There are cases where you can solve this problem.  
> But to say that we don't want to add post processing because of 
> performance reasons means you don't understand how the core operates.  
> It currently post processes every single url in the system, both for 
> content and for system resources in 4 different ways.


Be very careful trying to tell *me* I don't understand how WordPress works.
 Please point me to the code that processes every single url in four different ways for every single request. File name and line numbers, please, trunk or 3.2.1



>  My solution would eliminate all of those post-processing functions 
> except for one in the case of RSS feeds and Emails.  And even then you 
> would solve that problem with caching if performance were to take a hit.
>
> I understand that sometimes you can get an organization to change, but 
> you still had to implement an large degree of extra effort that is 
> only available to one specific platform to achieve your goals.  With 
> root-relative URLs those issues disappear entirely.  You are left with 
> one filter for one type of content that is already being filtered with 
> more complexity than what would be necessary with an alternative architecture.
>
>
I didn't get the organisation to change, they insisted it be like that, because it meant that it was then easy to have wp-admin completely blocked from the www access route and allowed from the cms route. And it really wasn't a large degree of effort, I'm really good at what I do, it was easy.


 Mike
--
Mike Little
http://zed1.com/
_______________________________________________
wp-hackers mailing list
wp-hackers at lists.automattic.com
http://lists.automattic.com/mailman/listinfo/wp-hackers