Matt Mullenweg (@matt)

Forum Replies Created

Viewing 25 replies - 1 through 25 (of 62 total)
  • Why not use KSES?

    WP’s user structure is scalable — we have over 14 million rows in wp_users on WP.com. It’s never been a bottleneck.

    It’s on the list, I want it for the WP support forums as well.

    In reply to: Front-end editing

    The security issues have nothing to do with TinyMCE, the editor, I’ve just avoided included that in something like P2 or QuickPress because it’s huge, and slow. It’s a lot of overhead for most forums which are largely text.

    Just from experience, XML as an intermediary format is often much, much slower than working from someone’s database directly.

    Plus we can make it so the user doesn’t have to download/upload something, which for a large forum would be intimidating or impossible.

    ashfame, I wouldn’t recommend downgrading to 0.9, it has not had updates or even a security review in a long time. If someone wants to fork it and start updating it that’s one thing, but as it stands using 0.9 is inadvisable.

    _KB_, absolutely with regards to importers for other systems. We’ve held off on any importers so far because I really didn’t feel like bbPress was ready for switchers, there was so much fundamentally broken about its experience.

    Milan, BBXF is a nice idea but, like BackPress, it’s a bit of a boil-the-ocean approach. From our point of view rather than getting every system in the world to adopt this new format, it’s better to just target importers for specific platforms as the market demands it, which has worked well on the WP side.

    Will take a look at the links, maybe we could switch the search over to use Sphinx like we do on WP.org. (Sphinx is infinitely better and faster than anything we could ever do native in MySQL.)

    In reply to: Front-end editing

    The challenge comes from the security model: WP hides a lot of things unless you’re on the backend.

    I think you have a misconception of what a core plugin is — I originally proposed it so I’m happy to clarify.

    To think of it in term of arbitrary percentages, if something is useful to above 80% of the userbase, it should not be a plugin, or a core plugin, it should be in core.

    The core plugin concept was created to address the problem best illustrated by PodPress, where you had a strategically extension of something already in core (podcasting support) that was effectively abandoned and keeping a non-trivial number of users stuck on an old version. The community could take it over we could try to structure its maintenance much in the same way WP itself is structured, with responsibility spread between multiple contributors.

    The percentage to trigger that is probably something like 20%. (For 20% of a userbase to use a plugin is actually pretty huge.)

    I think taking essential 80%+ functionality out of core and into plugins for the sake of some imaginary notion of bloat or “correctness” actually just sacrifices user experience for modularity, it creates a new kind of bloat in that people have to navigate a confusing array of add-ons with complex interactions before they have their basic needs satisfied.

    Just for the record, as someone who runs several large bbPress installs with millions of posts between them, I am supremely interested in the performance aspects and confident we can make the plugin scale better than bbPress does today or did in the 0.7-0.9 line.

    Non-plugin bbPress development is going to continue until we have a perfect importer so people will be able to bring their content out of the legacy codebase.

    In reply to: Front-end editing

    Check out how P2 does front-end editor, it’s even slicker than bbPress. Actually check out a bunch of the features of P2 like the real-time post updating, etc.

    Since the stated roadmap for whatever is going to be called “bbPress” and live at bbpress.org is to build on the success of WordPress if you disagree with that direction it’s probably best to fork at that time.

    Plugin directory is broken in a bunch of ways, might take a few to fix.

    Greg, I think we agree, just have different ideas about where that line is drawn. I’ve laid out the core philosophy as a framework for discussions above. I have never advocated making every plugin a core feature, and conversely I doubt you’re suggesting making every line of code in bbPress a plugin.

    Balancing between the two is how development happens, and is best navigated in the context of a specific anchor (feature) rather than in abstract.

    johnhiler, the assumptions are indeed an active core. In the WordPress world, people who were active in the plugin arena also become active in core. In bbPress, they haven’t. Maybe that will change now.

    wtfmatt*, please don’t force me to more permanently ban you. Either make a real account with real information, or go away.

    Shared-hosts are the bread and butter of WordPress usage. The good news is servers are way more powerful than when I wrote the first bbPress, and we can take advantage of that to provide a richer experience.

    I like the idea of plugin-centric development from a theoretical point of view, and obviously plugins have been at the core of WordPress’ success, but I think it can be taken too far and take away from the user experience.

    It’s about taking responsibility. Even though you could break down almost every feature of WordPress into a plugin and distribute everything bundled, and even activate a bunch of them by default I think you lose a “buck stops here” for other developers to target. The uncertainty of testing the interactions of N factorial plugins is daunting and gets untenable quickly.

    Better to draw a line in the sand and promise the user “these things will always work together.”

    I also remember 0.7 fondly — along with Akismet it was the released product with the highest percentage of my code. Last year I shifted most of my code to internal tools, and this year that has waned even more due to the force of nature that is Mr Momrik my Technical Assistant.

    That said, there is minimalist-beautiful, and minimalist-useless. Even Ferarris have stereo systems. I think we can find the balance between the two even though it might mean we misstep in one direction or the other along the way.

    I agree with you more than you. In hindsight BackPress was a mistake. Its goal was to unify WP and bbP development, and it just ended up crippling bbPress with needless abstraction and didn’t actually generate any user-critical improvements, like being able to use WordPress themes.

    In reply to: _ck_ owes me ten bucks

    Sorry the site broke — I didn’t notice and no one emailed me, or if they did I didn’t read it. It is inevitable things will break when you’re making improvements (WordPress.org was down for a few hours last week, several times) but we endeavor to fix it as soon as possible when aware of the problem.

    Love it. :)

    Thanks for starting a new thread. Some of your sentences are unclear to me, so if I misunderstand a question just rephrase it and I’ll do my best to answer it.

    The WordPress.org integration is done through a shared user table and the same settings for cookies. It is a bit of a hack right now because WP and bbPress have a different idea of how those global tables should look and fight to modify them, which is what took down WordPress.org the other day. (It’s very slow to modify the schema of a user table with hundreds of thousands of rows.)

    As for running multiple instances of bbPress, on different domains even, we actually did a fair amount of work for that (was going to call it mubb.org) and it’s the code that currently powers TalkPress.com. However it’s not release quality and it becomes moot because once bbPress is a full WP plugin you get multi-site for free from WP’s built-in MS feature, so you could run as many bbPresses as you like from a single install.

    Милан Динић, good point, when something is in core it is always QA’d along with the release.

    johnhiler, plugins is core, additional functionality, and performance are orthogonal topics, in that one does not necessarily mean another and I think it’s dangerous to conflate them.

    There was a bug with spam being sent out, but it was alpha software, and the bug was fixed as soon as someone left a patch for it.

    If anything it should be easier to get a patch into core rather than a plugin because core has a dedicated Trac instance and multiple commiters, something most plugins do not. (Assuming they’re not abandoned.) Core is more likely to be translated than plugins.

    Finally, it takes the emphasis off of a single person (most plugins have one author) and puts it onto the core development community, which bbPress has never had but needs to grow if it’s going to survive.

    As for bundling multiple plugins with core — ultimately it’s a cop-out. If something is good enough to be included with the core download, put it in core! At that point you don’t gain anything from keeping it separate except the increased user cognitive load of having to activate 20 plugins to get, in their view, basic functionality and the instability of new plugins being unable to depend on functionality being there to extend it.

    Probably what we will do is have the bbPress.org plugins section pull from plugins in the core WP directory with a certain tag, like how BuddyPress does it. We could probably keep the existing bbP directory running in a different directory to give people time to transition.

Viewing 25 replies - 1 through 25 (of 62 total)