A do-over for understanding the absolute url side...
5 views
Skip to first unread message
Marcus Pope
Oct 30, 2011, 6:12:48 PM10/30/11
to Absolute vs relative
So I'll be the first to admit that I have my "prejudices" against
absolute urls. In an effort to better understand the approach I'll
start the discussion as a student versus a teacher.
I went back through the debates and here's what I gleamed as the
problems with root-relative urls:
1. Limits the scope of your content to webpages only. It won't work
in RSS feeds, XML exports, Books, and other future uses of web
content.
2. There is no other reason to use root-relative urls other than
moving domains, which is a rare use-case.
3. Might break other plugins.
4. Would be difficult to implement.
5. There is no scenario that justifies using root relative urls
because "simple dns tricks" and "find-replace strategies" can solve
every scenario.
6. If you use root-relative urls or spending a lot of time on
migrations you are doing it wrong. (of course I'd like some
elaboration on this point but it was made multiple times.)
7. Using root-relative urls would add a bunch of new and extra code
and increase processing overhead.
8. It's easier to use a script to find-replace your database content
and existing deployment steps.
9. 5-10-30 minutes per migration isn't a big deal.
10. Most people in the wordpress community don't need root-relative
urls so as a feature or toggle option it's not worth the processing
overhead to check even once per page load.
And that's what I was able to extract from the thread. As a first
step I'd really like to see this list filled out further. Mike? Otto?
Are there cons you would like to add to the list? Clarifications
you'd like to add to the existing items? I'm interested in hearing
everything, learning as much as I can about the benefits of absolute
urls and the pitfalls of relative urls.
Only when we have a firm understanding behind the design decision will
we be able to have a discussion about the results.
Thanks!
-Marcus
absolute urls. In an effort to better understand the approach I'll
start the discussion as a student versus a teacher.
I went back through the debates and here's what I gleamed as the
problems with root-relative urls:
1. Limits the scope of your content to webpages only. It won't work
in RSS feeds, XML exports, Books, and other future uses of web
content.
2. There is no other reason to use root-relative urls other than
moving domains, which is a rare use-case.
3. Might break other plugins.
4. Would be difficult to implement.
5. There is no scenario that justifies using root relative urls
because "simple dns tricks" and "find-replace strategies" can solve
every scenario.
6. If you use root-relative urls or spending a lot of time on
migrations you are doing it wrong. (of course I'd like some
elaboration on this point but it was made multiple times.)
7. Using root-relative urls would add a bunch of new and extra code
and increase processing overhead.
8. It's easier to use a script to find-replace your database content
and existing deployment steps.
9. 5-10-30 minutes per migration isn't a big deal.
10. Most people in the wordpress community don't need root-relative
urls so as a feature or toggle option it's not worth the processing
overhead to check even once per page load.
And that's what I was able to extract from the thread. As a first
step I'd really like to see this list filled out further. Mike? Otto?
Are there cons you would like to add to the list? Clarifications
you'd like to add to the existing items? I'm interested in hearing
everything, learning as much as I can about the benefits of absolute
urls and the pitfalls of relative urls.
Only when we have a firm understanding behind the design decision will
we be able to have a discussion about the results.
Thanks!
-Marcus
Dagan Henderson
Oct 31, 2011, 12:15:17 PM10/31/11
to Absolute vs relative
Here's my own opinion in a nutshell:
1. The site's domain should always be dynamically generated in URL
requests (e.g. get_permalink()).
2. Pages should always be served with absolute URLs. Always.
As for what gets stored in the database, I do think relative URLs are
(generally) best. The problem arises with the GUID assigned to
attachments and internal links embedded in content. The latter is
easily solved with two filters, one to strip the domain when writing
to the database, and one to append it to relative URLs when reading
from the database. The former, my thinks, may lead down a dark and
dirty rabbit hole, but maybe not.
As for why the page's themselves should always have absolute URLs:
it's cleaner and more accurate. Consider content being (legitimately)
scraped and re-posted elsewhere, copy-and-pasted (without browser-
feature intervention) and stored for reference, etc. In a semantic
Web, absolute URLs are just plain more appropriate.
That said, it seems like what we're really going after here is the
ability to share a single database among multiple installations. Of
course, without some DB privileges in place, that opens the door to
users mistakenly updating production content via a staging or dev
site, which to me, is the biggest challenge. Or am I missing something?
1. The site's domain should always be dynamically generated in URL
requests (e.g. get_permalink()).
2. Pages should always be served with absolute URLs. Always.
As for what gets stored in the database, I do think relative URLs are
(generally) best. The problem arises with the GUID assigned to
attachments and internal links embedded in content. The latter is
easily solved with two filters, one to strip the domain when writing
to the database, and one to append it to relative URLs when reading
from the database. The former, my thinks, may lead down a dark and
dirty rabbit hole, but maybe not.
As for why the page's themselves should always have absolute URLs:
it's cleaner and more accurate. Consider content being (legitimately)
scraped and re-posted elsewhere, copy-and-pasted (without browser-
feature intervention) and stored for reference, etc. In a semantic
Web, absolute URLs are just plain more appropriate.
That said, it seems like what we're really going after here is the
ability to share a single database among multiple installations. Of
course, without some DB privileges in place, that opens the door to
users mistakenly updating production content via a staging or dev
site, which to me, is the biggest challenge. Or am I missing something?
Marcus Pope
Oct 31, 2011, 10:55:05 PM10/31/11
to Absolute vs relative
Well, I think the first points are in line with absolute url theory.
It's a little different from how wordpress core operates, and I'd take
that dynamic generation approach over existing architecture any day.
I think I answered your last concern about the multiple sites on the
the wp-hacker's list. It isn't that we want to access "different"
sites on the same database. WP Multi-site actually supports such an
arrangment.
But in honor of being the student in this arrangment, I'm curious
about #2.
The main points of your position are:
1. It's cleaner / more accurate
2. It appropriately matches the target when legitimately scraped or
copied for later reference.
I'm not so sure that the semantic web has much to do with how urls are
delivered in a browser so I'll leave it to the main points you made.
In response I'll offer a different perspective on the concept of
cleaner and see what your thoughts are before making any other
judgement on accuracy and scraping. Let's say you have a database of
people, and their addresses. People can have multiple addresses, so
generally you have two tables. One table contains information about
the user, and another contains information about the address with a
foreign key to the user who owns them. In the user table you have a
first name, last name and let's say a birthday. In the address table
you have a userid, street1 & 2, a city, a state, a zipcode (we'll
assume it's a US only database for the sake of simplicity.)
To me, putting the user's name in one table and their address in a
separate table is like putting a domain in one field in the database
and the root-relative url in the other fields. I think we see eye to
eye on this based on your position in #1. I think you would agree
that repeating the user's first name, last name and birthdate for
every address in the address table would be a waste. Plus when you
need to update the last name (like in a marriage) you have to change
it in multiple rows.
But let's say you have to present this information to a user. If you
are going to display one of their addresses, you'd probably display
their first & last name, and their primary address. But what if you
wanted to show all of their addresses? Would you repeat their first
and last name over every address? What about when you have two users
with multiple matching addresses? My wife and I both have the same
home and work addresses. Would you show both names on top of every
respective address?
To me the correlation between domain name and file uri are very
similar to user's names and their respective addresses. If I were to
design a "view user's addresses" page I would put their full name at
the top of the page, and then list each of their addresses beneath.
This follows the practice of Dont Repeat Yourself (DRY.) And it
presents, at least to me, a cleaner view to the user. In my view, the
domain at the top of the page is that name that is associated with
every link in the document that starts with "/".
But maybe we see it differently, and that's what I'd like to find
out. Perhaps you have never seen it this way, and can see where I'm
coming from.
On a different aspect I see the idea of giving a computer more
information than it needs a waste in the system, entropy if you will.
A browser already knows where those urls are coming from because it
was given the domain name first. For conservation's sake (and
considering back in the days of modems and painfully slow connection
speeds) it seemed really important to not repeat that information if
it wasn't necessary. Granted performance reasons are far less of an
issue today, but what does remain constant is the consistency of the
relationship. In database terms this is considered "first normal
form" or the lowest level of proper relationship abstraction.
From that perspective, is there a way that you can help me
differentiate the preference for repeating the domain name for all
internal links where as with a database you would only want to put the
related user table row (or a "/" that relates to the domain at the top
of the page in terms of the url.)?
What is it about the practice of repeating the domain in each url
improves accuracy? In my view the "/" is accurate enough to indicate
that the URL belongs to the domain in the url bar.
To play devil's advocate, if I just look at the address table of a
database, I wouldn't know who's address they each belonged to, unless
I kept track of the user_id's in my head. So is this a good reason to
repeat that user's first and last name in the address table? And if
that is a cleaner more accurate approach, do I keep duplicate rows of
the address for every nick name / maiden name a user has?
Might be the case. It's easier for a human to read it, and a machine
could certainly keep up with the duplicate rows. But I think the
idea, while capable on a small scale, starts to break down when the
scale grows.
I'll add those two points to the original post, and we'll see how the
discussion evolves.
Thanks,
Marcus
On Oct 31, 11:15 am, Dagan Henderson <dagan.hender...@epyllion.com>
wrote:
It's a little different from how wordpress core operates, and I'd take
that dynamic generation approach over existing architecture any day.
I think I answered your last concern about the multiple sites on the
the wp-hacker's list. It isn't that we want to access "different"
sites on the same database. WP Multi-site actually supports such an
arrangment.
But in honor of being the student in this arrangment, I'm curious
about #2.
The main points of your position are:
1. It's cleaner / more accurate
2. It appropriately matches the target when legitimately scraped or
copied for later reference.
I'm not so sure that the semantic web has much to do with how urls are
delivered in a browser so I'll leave it to the main points you made.
In response I'll offer a different perspective on the concept of
cleaner and see what your thoughts are before making any other
judgement on accuracy and scraping. Let's say you have a database of
people, and their addresses. People can have multiple addresses, so
generally you have two tables. One table contains information about
the user, and another contains information about the address with a
foreign key to the user who owns them. In the user table you have a
first name, last name and let's say a birthday. In the address table
you have a userid, street1 & 2, a city, a state, a zipcode (we'll
assume it's a US only database for the sake of simplicity.)
To me, putting the user's name in one table and their address in a
separate table is like putting a domain in one field in the database
and the root-relative url in the other fields. I think we see eye to
eye on this based on your position in #1. I think you would agree
that repeating the user's first name, last name and birthdate for
every address in the address table would be a waste. Plus when you
need to update the last name (like in a marriage) you have to change
it in multiple rows.
But let's say you have to present this information to a user. If you
are going to display one of their addresses, you'd probably display
their first & last name, and their primary address. But what if you
wanted to show all of their addresses? Would you repeat their first
and last name over every address? What about when you have two users
with multiple matching addresses? My wife and I both have the same
home and work addresses. Would you show both names on top of every
respective address?
To me the correlation between domain name and file uri are very
similar to user's names and their respective addresses. If I were to
design a "view user's addresses" page I would put their full name at
the top of the page, and then list each of their addresses beneath.
This follows the practice of Dont Repeat Yourself (DRY.) And it
presents, at least to me, a cleaner view to the user. In my view, the
domain at the top of the page is that name that is associated with
every link in the document that starts with "/".
But maybe we see it differently, and that's what I'd like to find
out. Perhaps you have never seen it this way, and can see where I'm
coming from.
On a different aspect I see the idea of giving a computer more
information than it needs a waste in the system, entropy if you will.
A browser already knows where those urls are coming from because it
was given the domain name first. For conservation's sake (and
considering back in the days of modems and painfully slow connection
speeds) it seemed really important to not repeat that information if
it wasn't necessary. Granted performance reasons are far less of an
issue today, but what does remain constant is the consistency of the
relationship. In database terms this is considered "first normal
form" or the lowest level of proper relationship abstraction.
From that perspective, is there a way that you can help me
differentiate the preference for repeating the domain name for all
internal links where as with a database you would only want to put the
related user table row (or a "/" that relates to the domain at the top
of the page in terms of the url.)?
What is it about the practice of repeating the domain in each url
improves accuracy? In my view the "/" is accurate enough to indicate
that the URL belongs to the domain in the url bar.
To play devil's advocate, if I just look at the address table of a
database, I wouldn't know who's address they each belonged to, unless
I kept track of the user_id's in my head. So is this a good reason to
repeat that user's first and last name in the address table? And if
that is a cleaner more accurate approach, do I keep duplicate rows of
the address for every nick name / maiden name a user has?
Might be the case. It's easier for a human to read it, and a machine
could certainly keep up with the duplicate rows. But I think the
idea, while capable on a small scale, starts to break down when the
scale grows.
I'll add those two points to the original post, and we'll see how the
discussion evolves.
Thanks,
Marcus
On Oct 31, 11:15 am, Dagan Henderson <dagan.hender...@epyllion.com>
wrote:
Dagan Henderson
Oct 31, 2011, 11:28:54 PM10/31/11
to Absolute vs relative
First,as long as we're discussing my own personal view (for whatever
the hell that's worth), let's drop the concept of "in a browser." How
about, in a Facebook thread, in a tweet, or in the Library of Congress
(seriously, think of the digital archaeology that is already
happening)? If four different conversations all revolve around a
single blog post, but each discussion references a different URL for
that blog post, it's *way* more difficult to reassemble the overall
conversation. That's why absolute URLs are important.
Also, WordPress is a blogging platform. Blogs are social. Social =
conversation. Conversation needs a topic. And topics should be
identifiable to the vessels of communication. That's why I personally
think it's important that every blog post have its own, unique
absolute URL (which differs from your example of multiple people
living at the same address). Maybe there's more than one Dagan
Henderson. If there is, it's important that you specify
roseville.ca.us/dagan.henderson when you're talking about me. Sure,
the first part may change if I move, but to still know it's me, you
may have to go so far as to say manhattan.ny.us/dagan.henderson
(a.k.a. roseville.ca.us/dagan.henderson). If you don't, the topic of
your conversation (which has some how turned to me :-P) becomes
ambiguous.
Even in your own use cases, the content only lives in one spot on the
public Internet (the production site). Referencing it anywhere else
will only work if the person you're sharing it with resides within (or
has access to) the private network.
You also still haven't answered what I consider to be my most pressing
question: How does accessing the same database tables from different
sites actually solve a problem in the long term? If I access your
staging site and click "Publish," the content becomes live on the
production site, and isn't that contrary to your own goals?
Cheers.
the hell that's worth), let's drop the concept of "in a browser." How
about, in a Facebook thread, in a tweet, or in the Library of Congress
(seriously, think of the digital archaeology that is already
happening)? If four different conversations all revolve around a
single blog post, but each discussion references a different URL for
that blog post, it's *way* more difficult to reassemble the overall
conversation. That's why absolute URLs are important.
Also, WordPress is a blogging platform. Blogs are social. Social =
conversation. Conversation needs a topic. And topics should be
identifiable to the vessels of communication. That's why I personally
think it's important that every blog post have its own, unique
absolute URL (which differs from your example of multiple people
living at the same address). Maybe there's more than one Dagan
Henderson. If there is, it's important that you specify
roseville.ca.us/dagan.henderson when you're talking about me. Sure,
the first part may change if I move, but to still know it's me, you
may have to go so far as to say manhattan.ny.us/dagan.henderson
(a.k.a. roseville.ca.us/dagan.henderson). If you don't, the topic of
your conversation (which has some how turned to me :-P) becomes
ambiguous.
Even in your own use cases, the content only lives in one spot on the
public Internet (the production site). Referencing it anywhere else
will only work if the person you're sharing it with resides within (or
has access to) the private network.
You also still haven't answered what I consider to be my most pressing
question: How does accessing the same database tables from different
sites actually solve a problem in the long term? If I access your
staging site and click "Publish," the content becomes live on the
production site, and isn't that contrary to your own goals?
Cheers.
Dagan Henderson
Oct 31, 2011, 11:34:15 PM10/31/11
to Absolute vs relative
Sorry, Marcus. You actually did answer my question on database issues,
but it was on the wp-hackers list. I posed a new question back,
though, which is: If all content requires 2- or 3-database workflows
to be published, why the heck would you be using WordPress to begin
with? That sounds much more like static, long-term content than a blog
post. And, yes, WordPress does support pages and custom post-types,
but if you're primary need is non-time-relative CMS, why a blogging
platform? There are other, perhaps more suitable, solutions available.
but it was on the wp-hackers list. I posed a new question back,
though, which is: If all content requires 2- or 3-database workflows
to be published, why the heck would you be using WordPress to begin
with? That sounds much more like static, long-term content than a blog
post. And, yes, WordPress does support pages and custom post-types,
but if you're primary need is non-time-relative CMS, why a blogging
platform? There are other, perhaps more suitable, solutions available.
Marcus Pope
Nov 1, 2011, 12:21:00 AM11/1/11
to Absolute vs relative
Starting with the last point first, because I thought I made the
clarification in response to your question on wp-hackers. I don't
think anyone is advocating hosting dev staging and production on the
same database. Maybe copies of the same database for isolation of
each environment, but certainly not the very same single database. As
you point out clicking publish in staging would do exactly what you
say in production. I posted a longer thread on wp-hackers about that
since it wasn't really about the preference for which style of url.
And the point I made there was that regardless of absolute urls or
relative urls, hosting three sites on one database (something you can
do with the current wordpress architecture with absolute urls) would
be a very bad idea, and isn't in line with the goals of the root
relative site.
But let's talk about your examples in the first paragraph. You
mention what about urls in a tweet or facebook post. What would
happen if each discussion references a different URL? I'm not really
advocating changing the url for that post. In my mind the URL is
still very much absolute if the url starts with a "/" and exists on
www.wordpress.org. When I copy that address, regardless of whether
the browser helps me or not, I'll be sure to include the domain if I
see a URL that begins with "/". Thankfully every browser handles that
for me, because I would probably forget every now and then.
Interestingly enough, if you view the source of both facebook.com and
twitter.com they use root relative URLs for all of their internal
links. Says a lot about the practice when Facebook, Google, Blogger
and Wordpress.com all use root relative links on their sites. Links
going outside the domain, like links in a facebook post from a user to
your website would still reference the fully qualified absolute domain
URL. So using those sites as a model, if I were to publish a post
that contained links to my own wordpress site, say to an image or
another post, they should probably be root relative at least according
to facebook and twitter. And if I post a link to an external
resource, the link should 100% guaranteed reference a full absolute
url. And crawlers, websites, browsers and various other technology
have worked under this framework since day one, so you should be
pretty safe to copy those urls and that content (in a legitimate way)
without worry of losing the domain for those "/" links. And you can
rest assure that if you used those links web crawlers will figure out
how to work with them because they manage to do so on millions of
sites every day.
Using your city.state.us/name analogy - if you take the content that
resides on roseville.ca.us/dagan.henderson, and you move your house.
The process of moving is like moving a domain. You'd still get your
mail, because you'd put in a change of address form. You still get
web traffic because you changed your DNS. But what if you wrote your
address on all of your possessions? Well, when you move you'd have to
change that address to your new address manhattan.ny.us/
dagan.henderson (if you didn't you'd have a lot of aka's on your
property if you moved houses like a military family would.) Our
perspective is that you don't need to write rosevill.ca.us on all of
your property because it's inside your house (aka your domain) and you
already know that if it's in your house it's your property (ignoring
theft in this analogy.) Now that you've moved, you either have to
update the address on all of your property, or people will think
things in your house belong to someone in roseville.ca.us. Just the
same, if you move sites, but if you don't update all of the urls in
your website to reflect the new domain, every time you click on an
internal link it's going to point back to your old domain (or house.)
In our world, we'd just put "/" on all of our property, that way when
we move houses, we only need to reference the home address once, and
know that everything in it belonged to that house just as I know that
every URL starting with "/" belongs to that domain.
Obviously theft of property breaks down in this analogy but hopefully
you can see the benefit of not putting your address on all of your
belongings. If you borrow someone else's stuff, sure you might label
it with that person's name and address (a police department does this
if you get arrested, so they can keep track of your stuff from
everyone else's, I guess they'd be like a search engine in this
regard.)
In my world, moving houses happens a lot. I move content from dev to
qa a lot. From qa to production less frequently but still more often
than I'd ever consider moving in real life. When I copy that data
from my dev database to my qa database, in the same way I'd move my
belongings from one house to another, it would be nice to know that
when I visit my dev home, the property in there always references my
dev environment by starting with a "/". And if I visit my QA home,
all of the duplicated content in there is guaranteed to reference my
QA environment without any extra effort. With root-relative URLs I
don't have to worry about finding every belonging and changing the URL
so that QA departments don't accidentally point back to the dev
environment in their testing.
On Oct 31, 10:28 pm, Dagan Henderson <dagan.hender...@epyllion.com>
wrote:
clarification in response to your question on wp-hackers. I don't
think anyone is advocating hosting dev staging and production on the
same database. Maybe copies of the same database for isolation of
each environment, but certainly not the very same single database. As
you point out clicking publish in staging would do exactly what you
say in production. I posted a longer thread on wp-hackers about that
since it wasn't really about the preference for which style of url.
And the point I made there was that regardless of absolute urls or
relative urls, hosting three sites on one database (something you can
do with the current wordpress architecture with absolute urls) would
be a very bad idea, and isn't in line with the goals of the root
relative site.
But let's talk about your examples in the first paragraph. You
mention what about urls in a tweet or facebook post. What would
happen if each discussion references a different URL? I'm not really
advocating changing the url for that post. In my mind the URL is
still very much absolute if the url starts with a "/" and exists on
www.wordpress.org. When I copy that address, regardless of whether
the browser helps me or not, I'll be sure to include the domain if I
see a URL that begins with "/". Thankfully every browser handles that
for me, because I would probably forget every now and then.
Interestingly enough, if you view the source of both facebook.com and
twitter.com they use root relative URLs for all of their internal
links. Says a lot about the practice when Facebook, Google, Blogger
and Wordpress.com all use root relative links on their sites. Links
going outside the domain, like links in a facebook post from a user to
your website would still reference the fully qualified absolute domain
URL. So using those sites as a model, if I were to publish a post
that contained links to my own wordpress site, say to an image or
another post, they should probably be root relative at least according
to facebook and twitter. And if I post a link to an external
resource, the link should 100% guaranteed reference a full absolute
url. And crawlers, websites, browsers and various other technology
have worked under this framework since day one, so you should be
pretty safe to copy those urls and that content (in a legitimate way)
without worry of losing the domain for those "/" links. And you can
rest assure that if you used those links web crawlers will figure out
how to work with them because they manage to do so on millions of
sites every day.
Using your city.state.us/name analogy - if you take the content that
resides on roseville.ca.us/dagan.henderson, and you move your house.
The process of moving is like moving a domain. You'd still get your
mail, because you'd put in a change of address form. You still get
web traffic because you changed your DNS. But what if you wrote your
address on all of your possessions? Well, when you move you'd have to
change that address to your new address manhattan.ny.us/
dagan.henderson (if you didn't you'd have a lot of aka's on your
property if you moved houses like a military family would.) Our
perspective is that you don't need to write rosevill.ca.us on all of
your property because it's inside your house (aka your domain) and you
already know that if it's in your house it's your property (ignoring
theft in this analogy.) Now that you've moved, you either have to
update the address on all of your property, or people will think
things in your house belong to someone in roseville.ca.us. Just the
same, if you move sites, but if you don't update all of the urls in
your website to reflect the new domain, every time you click on an
internal link it's going to point back to your old domain (or house.)
In our world, we'd just put "/" on all of our property, that way when
we move houses, we only need to reference the home address once, and
know that everything in it belonged to that house just as I know that
every URL starting with "/" belongs to that domain.
Obviously theft of property breaks down in this analogy but hopefully
you can see the benefit of not putting your address on all of your
belongings. If you borrow someone else's stuff, sure you might label
it with that person's name and address (a police department does this
if you get arrested, so they can keep track of your stuff from
everyone else's, I guess they'd be like a search engine in this
regard.)
In my world, moving houses happens a lot. I move content from dev to
qa a lot. From qa to production less frequently but still more often
than I'd ever consider moving in real life. When I copy that data
from my dev database to my qa database, in the same way I'd move my
belongings from one house to another, it would be nice to know that
when I visit my dev home, the property in there always references my
dev environment by starting with a "/". And if I visit my QA home,
all of the duplicated content in there is guaranteed to reference my
QA environment without any extra effort. With root-relative URLs I
don't have to worry about finding every belonging and changing the URL
so that QA departments don't accidentally point back to the dev
environment in their testing.
On Oct 31, 10:28 pm, Dagan Henderson <dagan.hender...@epyllion.com>
wrote:
Mike Schinkel
Nov 1, 2011, 12:30:18 AM11/1/11
to absolute-v...@googlegroups.com
On Oct 31, 2011, at 11:28 PM, Dagan Henderson wrote:
First,as long as we're discussing my own personal view (for whatever
the hell that's worth), let's drop the concept of "in a browser." How
about, in a Facebook thread, in a tweet, or in the Library of Congress
(seriously, think of the digital archaeology that is already
happening)? If four different conversations all revolve around a
single blog post, but each discussion references a different URL for
that blog post, it's *way* more difficult to reassemble the overall
conversation. That's why absolute URLs are important.
Just out of curiosity I wrote the following HTML file and saved it to the root of one of my websites:<html><head></head><body><a href="/foo/">Foo</a>, <a href="/bar/">Bar</a> and <a href="/Baz/">Baz</a></body></html>I then loaded it first in Safari then in FireFox and each time I selects the entire page and then pasted into a Word document. Then I hovered over the links and, sure enough, the full URLs were copied over. What that tells me is that during copy and paste, at least with those two browsers and probably all browsers, root relative URLs don't cause any additional difficulty WRT reassembly during copy & paste. IOW the browser's copy & paste is intelligent enough to figure it out.Now, my point is no more than to mention that root relative URLs are probably not an issue during copy and paste, nothing more on the subject at the moment.But then it occurred to me and after a quick check it became clear; the W3C has established standard for relative URLs in both RFC1808 and in the spec for HTML4.0; NOT doing the above would violate that aspect of the standards is so fundamental, you're not going to find much software that doesn't handle root relative URLs correctly:
FWIW.
That's why I personally
think it's important that every blog post have its own, unique
absolute URL (which differs from your example of multiple people
living at the same address).
I agree with you strongly on the value of URLs (yes, I wrote this blog for 6 months until I realized most people didn't care enough: http://blog.welldesignedurls.org/) but that is an orthogonal issue WRT to root relative URLs as shown above.
Even in your own use cases, the content only lives in one spot on the
public Internet (the production site).
That is clearly not true (and appears to be a very blogger-centric perspective.) If I make a copy of the site, which I can do for many reasons including automated site testing, the content now lives in two places, each with their own base domain URL.Referencing it anywhere else
BTW, I'm not arguing for or against root relative URLs, I'm just trying to make sure any points of the debate are solid. (What do I think we should do? Create a switch in core to enable one or the other and let the site owner decide.)
-Mike
Dagan Henderson
Nov 1, 2011, 12:33:46 AM11/1/11
to angl...@gmail.com, absolute-v...@googlegroups.com
Well said, but a canonical URL should be absolute, or at least I don't see why it shouldn't be.
Plus, you haven't answered my question about why WordPress over Joomlla! or Drupal if you need dev-staging-production workflow for content.
Seems like a very atypical use case for WordPress, at least to me.
Plus, you haven't answered my question about why WordPress over Joomlla! or Drupal if you need dev-staging-production workflow for content.
Seems like a very atypical use case for WordPress, at least to me.
wrote:
> First,as long as we're discussing my own personal view (for whatever
> the hell that's worth), let's drop the concept of "in a browser." How
> about, in a Facebook thread, in a tweet, or in the Library of Congress
> (seriously, think of the digital archaeology that is already
> happening)? If four different conversations all revolve around a
> single blog post, but each discussion references a different URL for
> that blog post, it's *way* more difficult to reassemble the overall
> conversation. That's why absolute URLs are important.
>
> First,as long as we're discussing my own personal view (for whatever
> the hell that's worth), let's drop the concept of "in a browser." How
> about, in a Facebook thread, in a tweet, or in the Library of Congress
> (seriously, think of the digital archaeology that is already
> happening)? If four different conversations all revolve around a
> single blog post, but each discussion references a different URL for
> that blog post, it's *way* more difficult to reassemble the overall
> conversation. That's why absolute URLs are important.
>
> Also, WordPress is a blogging platform. Blogs are social. Social =
> conversation. Conversation needs a topic. And topics should be
> conversation. Conversation needs a topic. And topics should be
> identifiable to the vessels of communication. That's why I personally
> think it's important that every blog post have its own, unique
> absolute URL (which differs from your example of multiple people
> living at the same address). Maybe there's more than one Dagan
> Henderson. If there is, it's important that you specify
> roseville.ca.us/dagan.henderson when you're talking about me. Sure,
> the first part may change if I move, but to still know it's me, you
> may have to go so far as to say manhattan.ny.us/dagan.henderson
> (a.k.a. roseville.ca.us/dagan.henderson). If you don't, the topic of
> your conversation (which has some how turned to me :-P) becomes
> ambiguous.
>
> Henderson. If there is, it's important that you specify
> roseville.ca.us/dagan.henderson when you're talking about me. Sure,
> the first part may change if I move, but to still know it's me, you
> may have to go so far as to say manhattan.ny.us/dagan.henderson
> (a.k.a. roseville.ca.us/dagan.henderson). If you don't, the topic of
> your conversation (which has some how turned to me :-P) becomes
> ambiguous.
>
> Even in your own use cases, the content only lives in one spot on the
Mike Schinkel
Nov 1, 2011, 12:37:10 AM11/1/11
to absolute-v...@googlegroups.com
On Nov 1, 2011, at 12:21 AM, Marcus Pope wrote:
Interestingly enough, if you view the source of both facebook.com and
twitter.com they use root relative URLs for all of their internal
links. Says a lot about the practice when Facebook, Google, Blogger
and Wordpress.com all use root relative links on their sites.
Because bandwidth costs money and when you have a lot of traffic you can say a not-insignificant amount of money by serving root relative URLs (or purely relative URLs, for that matter. :-) Clearly Google, Facebook et. al. have figured out this best practice.What's even more interesting is the WordPress.com itself does this; I want if the people on wp-hackers who are so adamant that to use root relative URLs is "doing it wrong" are aware that WordPress.com does so? And I wonder how the architects of WordPress.com would feel about being told they are "doing it wrong?"
-Mike
Marcus Pope
Nov 1, 2011, 12:37:30 AM11/1/11
to Absolute vs relative
Hey no problem, I figured it was a mistake on my part given the
response was on a completely different forum.
To answer this derrivative, Wordpress does a lot of other things
really *REALLY* well. And I'm interested in using the platform for
more work because of those benefits. However in the model of software
I work in, the hinderances that this behavior causes actually turn
into hourly problems.
Wordpress is trying to make the jump from a blogging platform to a
fully functioning CMS. Other solutions exist and I have had the
pleasure and pain of working with many of them (drupal, joomla,
codeigniter, django, ror, asp.net, mvc.net, catalyst, embperl, j2ee,
and a few others most have never heard of.) But wordpress has at its
core a potential edge on all of them.
The software I design doesn't in itself require 2 or 3 database /
environments. But the companies I work for do. Even for a simple
blogging/product website like drinktradewinds.com we go through that
process of develop and create content in development. Migrate to QA
so our QA department can check our work, and do so without worry that
we might still be making changes on it that will affect them. Then we
push the new code and content to a client site for our client to sign
off (maybe they want a change and we start the process over again.)
And finally when all is said and done we push the content to
production. We would never consider making a single change in
production because if we did, and we made a mistake (no matter how
small) it would reflect poorly on the company that is represented on
the website, as well as ourselves.
And I'll tell you, it took 1/3rd the time to build that website over
other frameworks. But since the first deployment, we have since eaten
up a lot of time waiting on our build scripts to convert urls from
environment to environment. I can updated our QA environment three to
four times daily, and at 10 minutes a piece, it starts to add up. On
bigger sites with a bigger database, the process really starts to slow
down, and that's expensive time to our clients.
It's not for everyone, but one of my main opinions is that root
relative urls wouldn't actually affect those who want to continue
writing personal blogs. Wordpress.com shows that this is a very
feasible practice for their own site's blog.
On Oct 31, 10:34 pm, Dagan Henderson <dagan.hender...@epyllion.com>
wrote:
response was on a completely different forum.
To answer this derrivative, Wordpress does a lot of other things
really *REALLY* well. And I'm interested in using the platform for
more work because of those benefits. However in the model of software
I work in, the hinderances that this behavior causes actually turn
into hourly problems.
Wordpress is trying to make the jump from a blogging platform to a
fully functioning CMS. Other solutions exist and I have had the
pleasure and pain of working with many of them (drupal, joomla,
codeigniter, django, ror, asp.net, mvc.net, catalyst, embperl, j2ee,
and a few others most have never heard of.) But wordpress has at its
core a potential edge on all of them.
The software I design doesn't in itself require 2 or 3 database /
environments. But the companies I work for do. Even for a simple
blogging/product website like drinktradewinds.com we go through that
process of develop and create content in development. Migrate to QA
so our QA department can check our work, and do so without worry that
we might still be making changes on it that will affect them. Then we
push the new code and content to a client site for our client to sign
off (maybe they want a change and we start the process over again.)
And finally when all is said and done we push the content to
production. We would never consider making a single change in
production because if we did, and we made a mistake (no matter how
small) it would reflect poorly on the company that is represented on
the website, as well as ourselves.
And I'll tell you, it took 1/3rd the time to build that website over
other frameworks. But since the first deployment, we have since eaten
up a lot of time waiting on our build scripts to convert urls from
environment to environment. I can updated our QA environment three to
four times daily, and at 10 minutes a piece, it starts to add up. On
bigger sites with a bigger database, the process really starts to slow
down, and that's expensive time to our clients.
It's not for everyone, but one of my main opinions is that root
relative urls wouldn't actually affect those who want to continue
writing personal blogs. Wordpress.com shows that this is a very
feasible practice for their own site's blog.
On Oct 31, 10:34 pm, Dagan Henderson <dagan.hender...@epyllion.com>
wrote:
Mike Schinkel
Nov 1, 2011, 12:38:36 AM11/1/11
to absolute-v...@googlegroups.com
On Nov 1, 2011, at 12:33 AM, Dagan Henderson wrote:
Plus, you haven't answered my question about why WordPress over Joomlla! or Drupal if you need dev-staging-production workflow for content.
I'll answer that one, at least for Drupal vs. WordPress:And Drupal is a lot better designed than Joomla...
-Mike
Marcus Pope
Nov 1, 2011, 12:39:22 AM11/1/11
to Absolute vs relative
Hey sorry, we're crossing thread's here, I was actually replying to
your other post before I saw the short followup, I've replied to that
one below, hopefully this is fast enough of a response to catch up :D
On Oct 31, 11:33 pm, Dagan Henderson <Dagan.Hender...@epyllion.com>
wrote:
> still very much absolute if the url starts with a "/" and exists onwww.wordpress.org<http://www.wordpress.org>. When I copy that address, regardless of whether
> > Cheers.- Hide quoted text -
>
> - Show quoted text -
your other post before I saw the short followup, I've replied to that
one below, hopefully this is fast enough of a response to catch up :D
On Oct 31, 11:33 pm, Dagan Henderson <Dagan.Hender...@epyllion.com>
wrote:
>
> - Show quoted text -
Marcus Pope
Nov 1, 2011, 12:43:30 AM11/1/11
to Absolute vs relative
Mike you beat me to it, and yeah it's an interesting point indeed. I
was writing up my response and when I submitted it I saw this.
Actually I noticed that their blog does use full urls on some of the
links, but not all of them (or even most of them.) So I'm guessing
they deal with the issue in blog posts. They probably only publish
blog posts in production, while the rest of the site is served with
root relative urls. Still an interesting fact that I wish I had known
to point out on Friday! :D
On Oct 31, 11:37 pm, Mike Schinkel <mikeschin...@newclarity.net>
wrote:
was writing up my response and when I submitted it I saw this.
Actually I noticed that their blog does use full urls on some of the
links, but not all of them (or even most of them.) So I'm guessing
they deal with the issue in blog posts. They probably only publish
blog posts in production, while the rest of the site is served with
root relative urls. Still an interesting fact that I wish I had known
to point out on Friday! :D
On Oct 31, 11:37 pm, Mike Schinkel <mikeschin...@newclarity.net>
wrote:
Dagan Henderson
Nov 1, 2011, 12:51:27 AM11/1/11
to mikesc...@newclarity.net, absolute-v...@googlegroups.com
I think we store relative URLs in the DB and serve absolute URLs in pages. That makes it easy to move and meets my own personal needs. Unfortunately, I don't think the use case justifies the amount of work. I still see too many holes.
----- Reply message -----
From: "Mike Schinkel" <mikesc...@newclarity.net>
Date: Mon, Oct 31, 2011 9:31 pm
Subject: [absolute-vs-relative] Re: A do-over for understanding the absolute url side...
From: "Mike Schinkel" <mikesc...@newclarity.net>
Date: Mon, Oct 31, 2011 9:31 pm
Subject: [absolute-vs-relative] Re: A do-over for understanding the absolute url side...
On Oct 31, 2011, at 11:28 PM, Dagan Henderson wrote:
First,as long as we're discussing my own personal view (for whatever
the hell that's worth), let's drop the concept of "in a browser." How
about, in a Facebook thread, in a tweet, or in the Library of Congress
(seriously, think of the digital archaeology that is already
happening)? If four different conversations all revolve around a
single blog post, but each discussion references a different URL for
that blog post, it's *way* more difficult to reassemble the overall
conversation. That's why absolute URLs are important.
Just out of curiosity I wrote the following HTML file and saved it to the root of one of my websites:
<html><head></head><body><a href="/foo/">Foo</a>, <a href="/bar/">Bar</a> and <a href="/Baz/">Baz</a></body></html>
I then loaded it first in Safari then in FireFox and each time I selects the entire page and then pasted into a Word document. Then I hovered over the links and, sure enough, the full URLs were copied over. What that tells me is that during copy and paste, at least with those two browsers and probably all browsers, root relative URLs don't cause any additional difficulty WRT reassembly during copy & paste. IOW the browser's copy & paste is intelligent enough to figure it out.
Now, my point is no more than to mention that root relative URLs are probably not an issue during copy and paste, nothing more on the subject at the moment.
But then it occurred to me and after a quick check it became clear; the W3C has established standard for relative URLs in both RFC1808 and in the spec for HTML4.0; NOT doing the above would violate that aspect of the standards is so fundamental, you're not going to find much software that doesn't handle root relative URLs correctly:
That's why I personally
think it's important that every blog post have its own, unique
absolute URL (which differs from your example of multiple people
living at the same address).
I agree with you strongly on the value of URLs (yes, I wrote this blog for 6 months until I realized most people didn't care enough: http://blog.welldesignedurls.org/) but that is an orthogonal issue WRT to root relative URLs as shown above.
Even in your own use cases, the content only lives in one spot on the
public Internet (the production site).
Marcus Pope
Nov 1, 2011, 1:02:12 AM11/1/11
to Absolute vs relative
Hey Dagan, hopefully we've gotten back on track by now... I was
writing posts before I saw the previous two responses from you :)
I think I've covered the stuff so far, but I wanted to note this one
more time:
> Seems like a very atypical use case for WordPress, at least to me.
This we completely agree on. But wordpress.org is trying to garner
support from/for people like me. The more often I use their software
the more often lots of money is poured into the framework and the
better it gets. Custom Post Types and the likes were built
specifically to support more business-y type uses of wordpress. I
think you'll find that if you used my plugin, your world wouldn't
change at all. (there is one bug related to the "comments" url in rss
feeds that I'm asking WP core to patch for 3.3, but it's a really
minor issue that most would never find, but I can't fix without the
core's help.) And then with my world working more smoothly with
wordpress as a solid foundation for future projects I can confidently
recommend it to future clients. The more businesses that buy into the
product the more time I have to dedicate towards building better
plugins that the community can use, and trust me I can knock out some
pretty amazing plugins given the opportunity in the same way I knock
out great features on platforms like joomla and zendframework that
others don't get to benefit from because of they way they are
architected.
I've got dozens of ideas on how to improve wordpress for everyone, not
just myself. But that relationship starts with forehand knowledge
from me that I can provide input that molds the wordpress core to meet
those needs. In many open source projects this is very easy to do for
anyone, and very welcomed by the project owners. In wordpress, so far
anyway, it's been really difficult. Even getting support for
something like html5 anchor tags, when they already support every
other html5 tag like section & article, has proven to be a brick wall
- and in this case the reasoning was "because HTML5 is not universally
supported yet." To which I'd like to know why did they add section,
article and other tags if they don't think it's universally supported
yet! :D I digress.
Questions like yours are the questions I love to hear. It means you
are interested in understanding more and are curious about where I'm
coming from. There are a few people who would rather not hear that
perspective at all, and will even respond with untruthful statements
as an excuse for why they don't need to hear it. But yet again, I
digress even further.
Well, it's bed time for me, but I'll keep up on this thread if you
have any other questions. The more people that see how well this idea
would support everyone means the closer we are to changing wordpress.
And my alternative at this point is to branch the project off into a
separate project of it's own, something I'd really hate to do.
Convincing the community one by one is relatively easier (no pun
intended ;)
Regards,
Marcus
> still very much absolute if the url starts with a "/" and exists onwww.wordpress.org<http://www.wordpress.org>. When I copy that address, regardless of whether
writing posts before I saw the previous two responses from you :)
I think I've covered the stuff so far, but I wanted to note this one
more time:
> Seems like a very atypical use case for WordPress, at least to me.
support from/for people like me. The more often I use their software
the more often lots of money is poured into the framework and the
better it gets. Custom Post Types and the likes were built
specifically to support more business-y type uses of wordpress. I
think you'll find that if you used my plugin, your world wouldn't
change at all. (there is one bug related to the "comments" url in rss
feeds that I'm asking WP core to patch for 3.3, but it's a really
minor issue that most would never find, but I can't fix without the
core's help.) And then with my world working more smoothly with
wordpress as a solid foundation for future projects I can confidently
recommend it to future clients. The more businesses that buy into the
product the more time I have to dedicate towards building better
plugins that the community can use, and trust me I can knock out some
pretty amazing plugins given the opportunity in the same way I knock
out great features on platforms like joomla and zendframework that
others don't get to benefit from because of they way they are
architected.
I've got dozens of ideas on how to improve wordpress for everyone, not
just myself. But that relationship starts with forehand knowledge
from me that I can provide input that molds the wordpress core to meet
those needs. In many open source projects this is very easy to do for
anyone, and very welcomed by the project owners. In wordpress, so far
anyway, it's been really difficult. Even getting support for
something like html5 anchor tags, when they already support every
other html5 tag like section & article, has proven to be a brick wall
- and in this case the reasoning was "because HTML5 is not universally
supported yet." To which I'd like to know why did they add section,
article and other tags if they don't think it's universally supported
yet! :D I digress.
Questions like yours are the questions I love to hear. It means you
are interested in understanding more and are curious about where I'm
coming from. There are a few people who would rather not hear that
perspective at all, and will even respond with untruthful statements
as an excuse for why they don't need to hear it. But yet again, I
digress even further.
Well, it's bed time for me, but I'll keep up on this thread if you
have any other questions. The more people that see how well this idea
would support everyone means the closer we are to changing wordpress.
And my alternative at this point is to branch the project off into a
separate project of it's own, something I'd really hate to do.
Convincing the community one by one is relatively easier (no pun
intended ;)
Regards,
Marcus
Marcus Pope
Nov 1, 2011, 1:12:25 AM11/1/11
to Absolute vs relative
> Unfortunately, I don't think the use case justifies the amount of work. I still see too many holes.
Ok, last reply I promise! :D In response to this, I'm here to fill
in those holes in every case. I know I can do that so keep em
coming. And the amount of work is something I'm willing to take on
myself as well. But to put it into perspective, when I wrote my
plugin, I didn't actually start with the plugin. I actually rewrote
the entire core of wordpress to use root-relative URLs. I didn't
think it would be possible to do via a plugin and didn't want to get
stuck half way down the road only to find that out. After I finished
the work, I realized that it was possible (99% anyway) to be done via
a plugin. So I reverted my work and used all of the hooks and filters
you see in it today.
What seems like a lot of work to some people actually only took me
about 16 hours to do. I was able to write the plugin in 4, and so a
total of 20 hours later I had created a solution to a problem that
people have been complaining about for over 4 years. Given my
understanding of the problem now, I could probably refactor the
codebase in about 4 hours. So don't let fear of the amount of work
factor into this judgement. I'm not saying I'd release the
architecture into production after only 4 hours or even 20 hours of
effort. But what it would actually take is a drop in the bucket of
what wordpress has invested in fixing http/https and other url
problems they've experienced in the past as a result of going with
absolute urls. There are over 500 tickets opened and over 420 fixed
related to http/http switching. This problem only ever occurs when
you use hard-coded absolute urls in your framework.
And again, I would back you 100% on dynamically joined urls, meaning
root relative in the database and joined with the domain for all links
on the front end. But you won't find any support for that on the
wordpress core team either. So if I'm going to campaign for anything
I'll go for gold.
Thanks again Dagan,
-Marcus
Dagan Henderson
Nov 1, 2011, 1:43:24 AM11/1/11
to Absolute vs relative
Last post tonight. My wife is quite literally yelling at me to come to
bed. :-)
I'm all for a WP-enterprise list, but I think we need to think long
and hard about the answer to a question posed by Otto (I think):
what's the difference for enterprise? If we can answer that in no more
than three very agreeable bullet points, I'm 100% in. Although I think
we should distribute the wp-enterprise-hackers list. :-)
Also, I can't emphasis how anti-forking I am. No matter how much we
may come to disagree with the core developers, forking should be 100
percent out of the question. As an example, consider the MSSQL fork
that's already available. What's an MSSQL-centric enterprise to do,
choose us or choose them? No matter the pain and agony, I say we 100
percent commit to a plugin and work towards core inclusion if/when we
make a viable-enough argument.
If we can agree on three simply stated points that define an
enterprise WP framework, I think we'll be off to a really good start.
I also think we'll attract more talent that way.
Thoughts?'
BTW, where is everyone at geographically? I'm in northern California.
bed. :-)
I'm all for a WP-enterprise list, but I think we need to think long
and hard about the answer to a question posed by Otto (I think):
what's the difference for enterprise? If we can answer that in no more
than three very agreeable bullet points, I'm 100% in. Although I think
we should distribute the wp-enterprise-hackers list. :-)
Also, I can't emphasis how anti-forking I am. No matter how much we
may come to disagree with the core developers, forking should be 100
percent out of the question. As an example, consider the MSSQL fork
that's already available. What's an MSSQL-centric enterprise to do,
choose us or choose them? No matter the pain and agony, I say we 100
percent commit to a plugin and work towards core inclusion if/when we
make a viable-enough argument.
If we can agree on three simply stated points that define an
enterprise WP framework, I think we'll be off to a really good start.
I also think we'll attract more talent that way.
Thoughts?'
BTW, where is everyone at geographically? I'm in northern California.
Mike Schinkel
Nov 1, 2011, 2:37:22 AM11/1/11
to absolute-v...@googlegroups.com
On Nov 1, 2011, at 1:43 AM, Dagan Henderson wrote:
Last post tonight. My wife is quite literally yelling at me to come to
bed. :-)
heh. ;-)
I'm all for a WP-enterprise list, but I think we need to think long
and hard about the answer to a question posed by Otto (I think):
what's the difference for enterprise?
"Enterprise" is a simply a convenient term and doesn't require a lot of explaining for people to realize what it is not: an individual blogging for personal interest. I've actually been thinking about this market for a little over a year and I've been referring to is as "professional website builders", but "enterprise" is shorter for a mailing list name.
If we can answer that in no more
than three very agreeable bullet points, I'm 100% in.
I'll give you five (5) point, and there are probably more. Note that not all points need to apply to every use-case:
1.) Sites used by medium-to-large organizations that do not have blogs and/or where the blog is one of the lesser important aspects of the site.
2.) Sites with at least two installations if not three or more in support of a single public domain: i.e. dev/test/staging/production/etc.; bonus points if version control is use.
3.) Sites maintained by full time professional developers and/or system admins; bonus points if more than one professional on the team.
4.) Sites developed and/or managed by professional agencies for clients where the budgets are are least US$25k
5.) Sites with traffic that overwhelms a single VPS or dedicated server and that requires the sites to be hosted on multiple nodes or in the cloud in some manner.
Otto will tell you he has experience on "billion dollar sites" (is there really such a thing that is not Google?) but his most recent experience is working for Matt Mullenweg of Audrey Capital. Matt's intense passion is empowering end-user bloggers to have a voice, and to empower them with free software, and Otto works in support of that. I great applaud Matt's passionate and his accomplishments, without them we would not be having this discussion, but Matt's focus and thus the core WordPress team's focus is decidedly not "enterprise."
Although I think
we should distribute the wp-enterprise-hackers list. :-)
That name? tl;dr. ;-)BTW, another reason *not* to start the list name with "wp-" is it implies it is an official WordPress list. I think it would be best if this list is *not* assumed to be an official list. WordPress Answers being independent is one of the reasons I think the culture is so great there, btw.
Also, I can't emphasis how anti-forking I am.
Did Marcus bring up forking? Not sure why it is something you'd mention?Anyway, there is "forking" and then there is "forking." Joomla forked Mambo, and I completely agree that forking WordPress to create a divergent solution a.l.a. Mambo would be a very bad idea, and I am completely against it.OTOH, did you know that WP Total Cache "forks" WordPress? I understand that it modifies some of WordPress's core files, because it has to. It is one that only forks the current install on activation and one that can refork the next version of WordPress if it needs to. And most users don't really even know any difference. Now THAT is the type of fork I would consider viable if left with no other alternative.
No matter the pain and agony, I say we 100
percent commit to a plugin and work towards core inclusion if/when we
make a viable-enough argument.
For the root-relative issue the the scope of this discussion is simple. But I proposed growing the scope of the list because there are literally tens if not hundreds of things we can do to improve WordPress for enterprise use (some of which I've been working on for over a year and plan to move to a closed beta before year end), and some of those might require WP Total Cache like forks.Of course getting the core team to provide the appropriate hooks when and where we need them would be great, but in my experience they don't like to provide hooks that enable professional use cases; best reason I can tell is that they don't want to see WordPress used that way. Or to spite us, I can't tell (Should I give you the list of trac tickets where I've asked for hooks to which they simply just closed the ticket? A hook, for god-sake, not a feature request; only a one-line simple hook?!?)
where is everyone at geographically? I'm in northern California.
-MikeIn in Atlanta, GA. And I'm up later than you even though it's 3 hours later here. :-)
Dagan Henderson
Nov 1, 2011, 7:11:25 AM11/1/11
to Absolute vs relative
>In in Atlanta, GA. And I'm up later than you even though it's 3 hours later here. :-)
>I'll give you five (5) point, and there are probably more. Note that not all points need to apply to every use-case:
(which is an arbitrary number I seem unnaturally in support of):
1. multi-developer and/or multi-install sites
2. sites requiring content workflow beyond what WordPress has baked in
3. sites requiring content and/or code versioning
>Did Marcus bring up forking? Not sure why it is something you'd mention?
I'd have sworn he did. If so, I sure as hell can't find it now. :-)
Still, I agree with your view on this, too.
All that said, I've got some ideas that I need to get out (and peer-
reviewed), so I'm going to start a new thread for a couple of features
I've been thinking about.
Mike Schinkel
Nov 1, 2011, 11:19:58 AM11/1/11
to absolute-v...@googlegroups.com
I really like your points, but I think we can dwindle it down to three
(which is an arbitrary number I seem unnaturally in support of):
1. multi-developer and/or multi-install sites
2. sites requiring content workflow beyond what WordPress has baked in
3. sites requiring content and/or code versioning
I see the benefit of a more concise list, but think your list doesn't hit the point I think is most important, to explicitly identify uses that incorporate code deployment It also doesn't acknowledge CMS-centric use vs. Blog-centric use, which is a key aspect in many but uses of WordPress. Further I can see many people identifying with #2 simply because they use a plugin to enhance workflow for 2 authors.
So here is my list. I think it addresses your 3 points (my #3 indirectly addresses your #2)
1.) Multi-install use with code and/or content versioning and deployment2.) Multiple person teams, especially those in larger orgs and agencies3.) Non-blog/CMS use and/or high traffic use
If you (and Marcus) likes this list, great. If not, we may need more than 3. :-)
-Mike
Dagan Henderson
Nov 1, 2011, 11:23:13 AM11/1/11
to absolute-v...@googlegroups.com
Love it.
Marcus Pope
Nov 2, 2011, 1:14:08 AM11/2/11
to enterprise-wp
Just to chime in, then I have to crash because I've been coding
literally all day. I like the idea of consolidating the purpose of
the group (which I changed to enterprise-wp, as mentioned somehere in
this thread :D) but my brain is too fuzzy right now to evaluate the
completeness of the list at this point from my perspective.
I may have mentioned forking, which in my mind is still preferable
(but not required) but only in the context of being completely
compatible with plugins and themes. The way I see it, if you can
improve the core without breaking the community, you've lost no real
value, and have gained the best value which is an optimized core. A
lofty goal I realize, but it's something that I feel is possible.
But I also like the idea of programmatic patches, and the idea of
delivering a well rounded set of plugins that virtually transform the
platform. And perhaps some recommended practices for things like
migrations.
I'm going to try to read the remaining posts, but I'm fading quickly.
I'm in Austin, TX btw.
The week is only getting more slammed for me so I might go silent
until Friday, but I'll be back :D
On Nov 1, 10:23 am, Dagan Henderson <Dagan.Hender...@epyllion.com>
wrote:
literally all day. I like the idea of consolidating the purpose of
the group (which I changed to enterprise-wp, as mentioned somehere in
this thread :D) but my brain is too fuzzy right now to evaluate the
completeness of the list at this point from my perspective.
I may have mentioned forking, which in my mind is still preferable
(but not required) but only in the context of being completely
compatible with plugins and themes. The way I see it, if you can
improve the core without breaking the community, you've lost no real
value, and have gained the best value which is an optimized core. A
lofty goal I realize, but it's something that I feel is possible.
But I also like the idea of programmatic patches, and the idea of
delivering a well rounded set of plugins that virtually transform the
platform. And perhaps some recommended practices for things like
migrations.
I'm going to try to read the remaining posts, but I'm fading quickly.
I'm in Austin, TX btw.
The week is only getting more slammed for me so I might go silent
until Friday, but I'll be back :D
On Nov 1, 10:23 am, Dagan Henderson <Dagan.Hender...@epyllion.com>
wrote:
Reply all
Reply to author
Forward
0 new messages