Simplicity in 2.next

classic Classic list List threaded Threaded
113 messages Options
1234 ... 6
Reply | Threaded
Open this post in threaded view
|

Simplicity in 2.next

Matt Mullenweg
The last thread about the next version of WP had some interesting ideas
in it, but I think the question may have been framed the wrong way. What
I'm far more interested in working on for the next version is this:

How can we make WordPress simpler in the next release?

How can we reduce support requests on the forums?

How can we make it faster?

(To riff on an idea, consider starting a new thread.)

--
Matt Mullenweg
  http://photomatt.net | http://wordpress.org
http://automattic.com | http://akismet.com
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

RE: Simplicity in 2.next

Vogel, Andrew (vogelap)
One of the ways to make it simpler from the very start would be to make
it so the admin didn't need to disable plugins, delete WP files, upload
new WP files, and enable plugins on an upgrade. Maybe this is through a
master script that does it all behind the scenes, or maybe it is by some
other route.

When 2.0.1 was released, I attempted to upgraded my site which is
happily running 2.0 (www.drewvogel.com) to 2.0.1 and encountered
significant problems in the upgrade process that left me with a
non-functioning site and sent me scrambling back to 2.0.0 until I've got
time to get into it. Upgrades and installs should be drop-ins; the user
shouldn't be bothered by issues like disabling/enabling plugins through
an upgrade.

-andrew vogel
Manager of Professional Programs
University of Cincinnati
College of Pharmacy
 

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of
> Matt Mullenweg
> Sent: Monday, February 06, 2006 3:10 PM
> To: [hidden email]
> Subject: [wp-hackers] Simplicity in 2.next
>
> The last thread about the next version of WP had some
> interesting ideas in it, but I think the question may have
> been framed the wrong way. What I'm far more interested in
> working on for the next version is this:
>
> How can we make WordPress simpler in the next release?
>
> How can we reduce support requests on the forums?
>
> How can we make it faster?
>
> (To riff on an idea, consider starting a new thread.)
>
> --
> Matt Mullenweg
>   http://photomatt.net | http://wordpress.org 
> http://automattic.com | http://akismet.com 
> _______________________________________________
> wp-hackers mailing list
> [hidden email]
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Simplicity in 2.next

Roy Schestowitz-2
In reply to this post by Matt Mullenweg
_____/ On Mon 06 Feb 2006 20:09:59 GMT, [Matt Mullenweg] wrote : \_____

> The last thread about the next version of WP had some interesting
> ideas in it, but I think the question may have been framed the wrong
> way. What I'm far more interested in working on for the next version
> is this:
>
> How can we make WordPress simpler in the next release?
>
> How can we reduce support requests on the forums?


In my opinion, bugs should take precedence, then compatibility (browser,
platform, and host testing) amd then comes the issue of extensibility
(simplicity -> user independence).


> How can we make it faster?


Faster to /use/? Or is it a matter of load handling? Or responsiveness? It's
a rope that you can always pull in different directions.


> (To riff on an idea, consider starting a new thread.)

_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Simplicity in 2.next

Robert Deaton
In reply to this post by Matt Mullenweg
A) Inline documentation, better documentation. Tutorials on getting
started with screencasts possibly (wasn't this discussed before?)

B) (Let the flames begin) Drop support for broken hosts and
environments. Have the installer do some safe mode checks, and if safe
mode is completely broken (like most setups of it are), set an option
that disables anything that might write to disk. This includes the
theme editors, the plugin editors, file uploading, caching, etc. There
comes a point where we're spending too much time working around broken
environments and not enough time actually working on adding and
updating features. 2.0 hit way above that mark in my opinion, and its
about time we move on.

Also in this category is dropping support for old MySQL versions, <
4.1, as their charset support is terrible, and is a cause of much
grief when moving around. Also, it may be smart for us to explicitly
declare a database charset as UTF-8 or similar, which will also help
cut down support requests.

C) Our own error controlling. Let's stop this now called "WSOD" mess
with our own error handling and logging, to make sure that context
appropriate error messages are displayed and that an admin is notified
when we are able to detect potentially serious problems. People are
coming to rely more and more upon the stability of WordPress, and each
horror story is a hit against potential users.

I'm sure I'll think of more soon.

--
--Robert Deaton
http://somethingunpredictable.com

_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Simplicity in 2.next

Jon Abad
Robert Deaton wrote:
> A) Inline documentation, better documentation. Tutorials on getting
> started with screencasts possibly (wasn't this discussed before?)
>  
>
Yes, I've volunteered for this on the responsibilities page and am eager
to start whenever.
http://codex.wordpress.org/User:Matt/WordPress_Responsibilities


jon

_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Simplicity in 2.next

Podz
In reply to this post by Matt Mullenweg
Matt Mullenweg wrote:
>
> How can we reduce support requests on the forums?
>

As has been discussed elsewhere, as admirable a goal as this is all that
actually happens is that as you make WP more extensible more people want
to do more so they ask more - and round it goes :)

For the next version ? Test the hell out of the upgrade - there are an
awful lot of people who experienced problems in this upgrade and the
WSOD as mentioned here before hasn't helped.

Bounty hunt the bugs :)

P.
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: 2.next [install options]

Douglas Daulton
In reply to this post by Vogel, Andrew (vogelap)
I'll echo and expand on Drew's thought.

On install, provide an optional configuration screen which allows one to
disable and/or delete unwanted themes, plugins and files from the core
install.  

To keep the "5 minute install" intact, simply make a "Optional
Configuration" button on the page.   Folks can end the install or do all
options in one simple screen rather than jumping through the Admin UI for 20
minutes tweaking the install.

DD

On 2/6/06 12:22 PM, "Vogel, Andrew (vogelap)" <[hidden email]> wrote:

> One of the ways to make it simpler from the very start would be to make
> it so the admin didn't need to disable plugins, delete WP files, upload
> new WP files, and enable plugins on an upgrade. Maybe this is through a
> master script that does it all behind the scenes, or maybe it is by some
> other route.
>
> When 2.0.1 was released, I attempted to upgraded my site which is
> happily running 2.0 (www.drewvogel.com) to 2.0.1 and encountered
> significant problems in the upgrade process that left me with a
> non-functioning site and sent me scrambling back to 2.0.0 until I've got
> time to get into it. Upgrades and installs should be drop-ins; the user
> shouldn't be bothered by issues like disabling/enabling plugins through
> an upgrade.
>
> -andrew vogel
> Manager of Professional Programs
> University of Cincinnati
> College of Pharmacy
>
>
>> -----Original Message-----
>> From: [hidden email]
>> [mailto:[hidden email]] On Behalf Of
>> Matt Mullenweg
>> Sent: Monday, February 06, 2006 3:10 PM
>> To: [hidden email]
>> Subject: [wp-hackers] Simplicity in 2.next
>>
>> The last thread about the next version of WP had some
>> interesting ideas in it, but I think the question may have
>> been framed the wrong way. What I'm far more interested in
>> working on for the next version is this:
>>
>> How can we make WordPress simpler in the next release?
>>
>> How can we reduce support requests on the forums?
>>
>> How can we make it faster?
>>
>> (To riff on an idea, consider starting a new thread.)
>>
>> --
>> Matt Mullenweg
>>   http://photomatt.net | http://wordpress.org
>> http://automattic.com | http://akismet.com
>> _______________________________________________
>> wp-hackers mailing list
>> [hidden email]
>> http://lists.automattic.com/mailman/listinfo/wp-hackers
>>
> _______________________________________________
> wp-hackers mailing list
> [hidden email]
> http://lists.automattic.com/mailman/listinfo/wp-hackers

_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Simplicity in 2.next

Ryan Boren
In reply to this post by Podz
Podz wrote:

> Matt Mullenweg wrote:
>
>>How can we reduce support requests on the forums?
>>
>
>
> As has been discussed elsewhere, as admirable a goal as this is all that
> actually happens is that as you make WP more extensible more people want
> to do more so they ask more - and round it goes :)
>
> For the next version ? Test the hell out of the upgrade - there are an
> awful lot of people who experienced problems in this upgrade and the
> WSOD as mentioned here before hasn't helped.

Were there any upgrade problems not attributable to a plugin?  Every one
I saw was attributable to a plugin that tripped over 1 of 2 small fixes
that broke some expectations.

Ryan



_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Simplicity in 2.next

Podz
Ryan Boren wrote:

>> For the next version ? Test the hell out of the upgrade - there are an
>> awful lot of people who experienced problems in this upgrade and the
>> WSOD as mentioned here before hasn't helped.
>
> Were there any upgrade problems not attributable to a plugin?  Every one
> I saw was attributable to a plugin that tripped over 1 of 2 small fixes
> that broke some expectations.
>

You are probably right - but those 2 small fixes caused a lot of posts :)

P.
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Simplicity in 2.next

Matt Mullenweg
In reply to this post by Roy Schestowitz-2
Roy Schestowitz wrote:
> Faster to /use/? Or is it a matter of load handling? Or responsiveness?
> It's
> a rope that you can always pull in different directions.

Perceived speed of use. For example doing pings asynchronously didn't
actually speed them up, but to the user it means WP seems faster.

I think on the scaling/load side we're fine. What's needed there is
mostly better documentation and guides.

--
Matt Mullenweg
  http://photomatt.net | http://wordpress.org
http://automattic.com | http://akismet.com
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Simplicity in 2.next

Ryan Boren
In reply to this post by Podz
Podz wrote:

> Ryan Boren wrote:
>
>
>>>For the next version ? Test the hell out of the upgrade - there are an
>>>awful lot of people who experienced problems in this upgrade and the
>>>WSOD as mentioned here before hasn't helped.
>>
>>Were there any upgrade problems not attributable to a plugin?  Every one
>>I saw was attributable to a plugin that tripped over 1 of 2 small fixes
>>that broke some expectations.
>>
>
>
> You are probably right - but those 2 small fixes caused a lot of posts :)

They needed to be fixed though.  We have enough plugins to make any
change to the core likely to break one of them.

If someone wants to go through wp-plugins.org and test every plugin with
each release, I'll try to fix any breakage found.  Vigilance over the
plugin repository coupled with firefox style extension management would
go a long way toward reducing plugin problems.  That's a real solution.
  Automatically deactivating all plugins during upgrade and requiring
manual reactivation is not a real solution.  That will guarantee
everyone is annoyed rather than just a subset of people.

Ryan
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Simplicity in 2.next

Podz
Ryan Boren wrote:

> They needed to be fixed though.  We have enough plugins to make any
> change to the core likely to break one of them.
>
> If someone wants to go through wp-plugins.org and test every plugin with
> each release, I'll try to fix any breakage found.

How many plugins are there ?
How about setting up a number of blogs and installing plugins to them.
We'd need a few blogs hopefully over a few hosts and then they can be
used ? Is that feasible ? I'll happily set them up anywhere but the key
part is the plugins. Populating them with entries / images etc would be
a chore but if the end result would be used and used well then count me
in for doing it.

> Vigilance over the
> plugin repository coupled with firefox style extension management would
> go a long way toward reducing plugin problems.  That's a real solution.

Agreed.

P.
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Simplicity in 2.next

Craig-16
So by testing plugins on wp-plugins.org, is this not setting up a defacto
set of official plugins since such a large number of plugins are hosted
elswhere, esp. on the authors' own sites? I suppose this might help
encourage folks to move their plugins to the repository, but I'm sure that
lots of plugin writers rather enjoy the traffic their site gets as a result
of their work.

Just thinkin' out loud!

Craig.
Nuclear Moose.
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Simplicity in 2.next

Podz
Craig wrote:
> So by testing plugins on wp-plugins.org, is this not setting up a defacto
> set of official plugins since such a large number of plugins are hosted
> elswhere, esp. on the authors' own sites? I suppose this might help
> encourage folks to move their plugins to the repository, but I'm sure that
> lots of plugin writers rather enjoy the traffic their site gets as a result
> of their work.
>

I'd say it's a place to start if nothing else. If it works out that
these blogs are worth the work then plugin authors could be asked - or
users be asked - to send the plugin for testing ?

What about they have a link at wp-plugins.org which goes to their page
for the actual code / info / post etc ? That way they get the credit /
traffic and also are seen in what could be the 'main location'. That's
close to what FF has ?

P.
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Simplicity in 2.next

Jon Abad
So far this sounds like it would be some sort of logo certification program?
I don't agree with that direction as it would require more manpower and
would distract from the central mission of creating awesomeness. Please
correct me if I'm wrong.


As I understand it, the FF model is that the extension states which
versions they work with and then Firefox knows which are allowed to be
turned on or not in order to prevent catastrophic failures or some such.
The package can be opened and the max-version number upped to test with
a new release but for the everyday user, they just wait for a new
extension version to be announced.

At minimum, this sounds like it would be useful to us: add a
WP-Version-Range line to the Plugin file structure so that people know
which versions the plugin has been tested on. Maybe an alert could be
given if the plugin hasn't been tested on the current version or simply
not allow for the plugin to be turned on at all.

Pro: WP would know which plugins are compatible with its stated
capabilities, hooks, etc.
Con: Support costs of the initial wave as plugins get tested and this
new line added to it.
Con: How would old/abandoned plugins be dealt with? (Is this even a
concern?)

Jon

Podz wrote:

> Craig wrote:
>  
>> So by testing plugins on wp-plugins.org, is this not setting up a defacto
>> set of official plugins since such a large number of plugins are hosted
>> elswhere, esp. on the authors' own sites? I suppose this might help
>> encourage folks to move their plugins to the repository, but I'm sure that
>> lots of plugin writers rather enjoy the traffic their site gets as a result
>> of their work.
>>
>>    
>
> I'd say it's a place to start if nothing else. If it works out that
> these blogs are worth the work then plugin authors could be asked - or
> users be asked - to send the plugin for testing ?
>
> What about they have a link at wp-plugins.org which goes to their page
> for the actual code / info / post etc ? That way they get the credit /
> traffic and also are seen in what could be the 'main location'. That's
> close to what FF has ?
>
> P.
> _______________________________________________
> wp-hackers mailing list
> [hidden email]
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>
>  
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Simplicity in 2.next

Evan Broder
In reply to this post by Craig-16
I would expect that, if people don't already have their plugins
currently hosted on wp-plugins.org, they aren't going to be easily
convinced to move them.

I have a plugin that I host in my own webspace. It's a bit of a hassle
when I release a new version, but wp-plugins.org is way overkill for my
development setup. The wiki and Subversion are really overkill for what
I need.

- Evan

Craig wrote:

> So by testing plugins on wp-plugins.org, is this not setting up a defacto
> set of official plugins since such a large number of plugins are hosted
> elswhere, esp. on the authors' own sites? I suppose this might help
> encourage folks to move their plugins to the repository, but I'm sure that
> lots of plugin writers rather enjoy the traffic their site gets as a result
> of their work.
>
> Just thinkin' out loud!
>
> Craig.
> Nuclear Moose.
> _______________________________________________
> wp-hackers mailing list
> [hidden email]
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>
>
>  
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Simplicity in 2.next

Andy Skelton
In reply to this post by Jon Abad
On 2/6/06, Jon Abad <[hidden email]> wrote:
> At minimum, this sounds like it would be useful to us: add a
> WP-Version-Range line to the Plugin file structure so that people know
> which versions the plugin has been tested on.

To keep with the FF model, this should not be coded into the plugin
but available via a URL to be checked as part of the upgrade process.

Before the user copies all the new core files, one new file
(pre-upgrade.php) is copied to ABSPATH and run from the browser. It
goes through the installed/activated plugins one by one, checking the
URL for compatibility notices and ending with a message stating which
plugins are known-good, known-bad and untested. This way the user
isn't already stuck with overwritten files and new db schema. It also
provides a channel for explicit upgrade instructions, such as the
ever-ignored advice to deactivate plugins, make backups, etc.

The URL may be specified by the author in an additional line in the
plugin's leading comments. Alternatively, plugins without the URL
would be checked against a centralized list of tested plugins.

Andy
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Simplicity in 2.next

Sam Angove
On 2/7/06, Andy Skelton <[hidden email]> wrote:
> On 2/6/06, Jon Abad <[hidden email]> wrote:
> > At minimum, this sounds like it would be useful to us: add a
> > WP-Version-Range line to the Plugin file structure so that people know
> > which versions the plugin has been tested on.
>
> To keep with the FF model, this should not be coded into the plugin
> but available via a URL to be checked as part of the upgrade process.

Mozilla extensions have minVersion and maxVersion as well as
(optional) updateURL .
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Simplicity in 2.next

Ryan Boren
In reply to this post by Evan Broder
Evan Broder wrote:
> I would expect that, if people don't already have their plugins
> currently hosted on wp-plugins.org, they aren't going to be easily
> convinced to move them.
 >
> I have a plugin that I host in my own webspace. It's a bit of a hassle
> when I release a new version, but wp-plugins.org is way overkill for my
> development setup. The wiki and Subversion are really overkill for what
> I need.

If a plugin author doesn't want to use wp-plugins, that's his choice.
Plugins not in the wp-plugins repository simply won't get the developer
attention that plugins that do reside in wp-plugin will get.  If they
break, they'll be left broken. I haven't the time or the inclination to
chase plugins hither, thither, and yon.  It's the linux kernel approach.
  If it's not in the tree, it is on its own.

Those plugins in the wp-plugins tree will get some extra love.  We'll
write automation that will run over the entire repository looking for
common mistakes and deprecated usage, for example.  We'll commit fixes
and try to keep the plugins up-to-date.  It's a big task that is
thoroughly impractical without a common repository.

I'd like to have a group of plugin gardeners with full commit access to
wp-plugins.

Ryan


_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Simplicity in 2.next

Jon Abad
In reply to this post by Andy Skelton
 From the Mozilla Extension Versioning page:
http://www.mozilla.org/projects/firefox/extensions/update.html

    Firefox uses the pref |app.extensions.version| to determine
    Extension compatibility for this release. When an Extension is
    installed, Firefox makes sure that |app.extensions.version| lies
    within the range set up by the Extension's install.rdf file using
    minVersion and maxVersion. If |app.extensions.version| is less than
    minVersion, a newer version of Firefox is required to install the
    Extension, if it is greater than maxVersion, Firefox is too new to
    install the extension.

    If this basic compatibility check fails, Firefox will then attempt
    to "phone home" and obtain newer compatibility information for the
    Extension. If the Extension's install.rdf file specifies an update
    RDF file, this will be loaded and newer information discovered there
    (see below for format). If none is supplied, Firefox will check the
    generic update service running on addons.mozilla.org, and if the
    Extension is hosted there and has newer compatibility information it
    will be read and the local information updated.

    If all of these methods fail, Firefox will show a message to the
    user saying that the Extension is incompatible and cannot be installed.

The plugin has the max and min ver and then it looks for an update if
necessary.

jon


Andy Skelton wrote:

> On 2/6/06, Jon Abad <[hidden email]> wrote:
>  
>> At minimum, this sounds like it would be useful to us: add a
>> WP-Version-Range line to the Plugin file structure so that people know
>> which versions the plugin has been tested on.
>>    
>
> To keep with the FF model, this should not be coded into the plugin
> but available via a URL to be checked as part of the upgrade process.
>
> Before the user copies all the new core files, one new file
> (pre-upgrade.php) is copied to ABSPATH and run from the browser. It
> goes through the installed/activated plugins one by one, checking the
> URL for compatibility notices and ending with a message stating which
> plugins are known-good, known-bad and untested. This way the user
> isn't already stuck with overwritten files and new db schema. It also
> provides a channel for explicit upgrade instructions, such as the
> ever-ignored advice to deactivate plugins, make backups, etc.
>
> The URL may be specified by the author in an additional line in the
> plugin's leading comments. Alternatively, plugins without the URL
> would be checked against a centralized list of tested plugins.
>
> Andy
> _______________________________________________
> wp-hackers mailing list
> [hidden email]
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>
>  
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
1234 ... 6