paulhawke (@paulhawke)

Forum Replies Created

Viewing 25 replies - 1 through 25 (of 48 total)
  • If we are talking “blue sky” here, I’d like to propose a re-think of the content of “forum”, “topic”, “thread” and “profile” pages. WordPress site maintenance took a giant step forward with the addition of widgets.

    Blogger.com is aimed at the masses (as any good forum software ought to be) and the “blog layout” tool is a great example. Drag + drop gadgets from a palette and tweak the look of the blog without ever editing a line of code.

    Wouldn’t it be nice if forum themes revolved around skinning just the presentation, and the structure of the page could be as simple as drag + drop in the admin area?

    Wouldn’t it be nice to allow widgets developed by other people to be dropped into place on the various pages that make up the site? What would it take to allow WordPress widgets to co-exist with bbPress ones?

    Now that would make moderating and tweaking a forum easier!

    Actually, while I think of it, a “get more widgets” link in the admin area, that seamlessly downloads and activates widgets would be awesome. All the smartphones are going toward an “App Store” why shouldn’t we?

    One one of the online (MMORPG style) gaming sites they regularly post news. There is a blog of news stories but if you want to discuss and give feedback about those news stories they are cross-posted in an “announcements” (read-only) forum, and to a “news discussion” (read-write) forum. The main community surrounding the game live in the forums and I’d say rarely go view the blog. So, I can see the use-case of where a forum would act as a comment/discussion repository.

    Both PhpStorm and Netbeans 6.8 allow you to [ctrl | command] click on a method and jump to its definition. Its invaluable! There’s nothing quite like being able to click your way through the [bb | word]Press code and actually see what is going on. NetBeans is free to download and is a friendly full-featured IDE (great for the VisualStudio folks).

    With the ease of code navigation in these tools, anyone interested in doing a “find in files” search for things like “add_action” and documenting what you find … as a way to help out the other plugin writers and bbPress coders?

    I’m running into an issue writing the “import” side of things – my first thought is to create a plugin that mimics what is in WordPress. I found myself creating the infrastructure that is already present in the main body of WP.

    Writing both import and export tool really would be a lot simpler when bbPress is a WordPress plugin. Why make it like the WP one, when we can utilize the real one? :-)

    Coming at this as a software engineering problem I cant see why a both/and rather than either/or situation shouldn’t prevail. Let me explain, as it’s not particularly outside the box for it to happen.

    I write a lot of automated tests for the code I produce day-to-day and that means I need to isolate the most important pieces of business logic from how they are invoked. For instance, a given request comes into the a webservice telling it to create a user for the system. I would separate the code that handles the webservice part (pulling parameter data from the incoming HTTP request, etc) from the code that then creates the user. I would isolate the steps, wrap automated unit tests around each, and be done.

    Applying the same thing to bbPress, there is some core code that handles the management of forums containing topics, that contain posts by users. This code is packaged into a clean unit of deployment – the WordPress plugin – and there is absolutely no reason why the code shouldn’t also have a second wrapper that allows for its deployment stand-alone from the main body of a WordPress installation.

    Just as I might have a webservice making calls to a body of well-tested code in my day-job, I dont see why a cleanly written WordPress plugin shouldn’t make calls into the tested bbPress core code. The body of WordPress code provides additional services that another wrapper could also provide – the core of bbPress should be unaware of the actual physical storage mechanisms being employed, or how it’s being invoked (assuming its written correctly).

    At the end of the day the conversion to a WordPress plugin should bring health to the codebase – a level of focus on what is most important (managing structured conversations in a forum/topic format), and an abstraction from what is not important (that is, the underlying physical storage, web-hosting, etc).

    Part of the problem (as I see it) is we have some cleanup to do. Do we know which plugins work with which versions of bbPress? Are there multiple plugings that do the same thing, and which of them is the best to choose? Which plugins are “abandonware” right now? Which are actively supported? Are the tags appropriately chosen for the plugins we have?

    Kudos to whoever made the change … the new look for the site is a huge step forward. If, for no other reason, than to send the message that “something is happening around here” :-)

    I can tell you one thing – the site is using my Topic Icons plugin. That is very gratifying to see! :-) In fact, they are running with the default skin.

    In reply to: Continuing Topic Icons

    I took a look at the original plugin – if I read the code correctly it let you specify a series of keywords that get associated to a given icon, and if those keywords are seen in the name of a given forum then it (the forum) gains that icon?

    I am inclined to create an admin interface for that functionality rather than having you edit the plugin itself.

    If keyword matching against the topic/forum name is the way you want to go, then I will happily code something into my topic-icons plugin. This will come in three parts:

    1. a new “plugin” bundled with my topic icons one that adds a new admin interface for associating keyword lists to icon names
    2. A new rule-processor for my topic-icons plugin that reads these keyword-to-icon names rules and applies them
    3. a new icon-set (skin) that gives you access to the old icons that _ck_ used before.

    I believe that I can replicate (and improve upon, given that it had no admin interface) what the original plugin offered.

    In reply to: Continuing Topic Icons

    paulhawke
    Member

    @paulhawke

    Take a look at another “topic icons” plugin – this time, one I wrote – https://bbpress.org/plugins/topic/bb-topic-icons/.

    It is written to allow you to upload new image sets – new “skins” – and detects them automatically, making them available in its admin area. The code was written to be modular and allow another plugin to supply new “rules” to determine which icons go where, and I’d be happy to work with you on a small extension plugin that implements your rule-set, so that you get the icons you want.

    How do you want icons on your bbPress install to behave?


    paulhawke
    Member

    @paulhawke

    @crosescu – there’s an interesting argument that would say more people would use wordpress (and for that matter bbPress too) if the codebase werent a monolithic structure. For instance, the ability to swap out user authentication to do single-signon against a Kerberos server rather than the built-in user-auth, or against the code in Mediawiki, should I want to integrate there. My hope is that merging yet more code in wont cause the entire house of cards to collapse around our ears.


    paulhawke
    Member

    @paulhawke

    I wrote a plugin recently called “freshness” that filters the list of recent topics to only show the ones newer than a particular date/time. Filtering the list to only show topics from a given list of forums wouldnt be too bad. If there isnt already a plugin to do this, I’d be happy to write you one that would.

    I lifted the following list from functions.bb-core.php where bbPress defines the set of fields that should make up the user profile:

    'first_name' => array(0, __('First name')),
    'last_name' => array(0, __('Last name')),
    'display_name' => array(1, __('Display name as')),
    'user_email' => array(1, __('Email'), 'email'),
    'user_url' => array(0, __('Website'), 'url'),
    'from' => array(0, __('Location')),
    'occ' => array(0, __('Occupation'), 'role'),
    'interest' => array(0, __('Interests'))

    If you want any of these fields to appear in your custom profile, you will need to add them to the list of fields you were building. Basically, the filter in your plugin takes over defining the definitive list that will be used, not a list of additions above-and-beyond the defaults given by bbPress … least I think that is what the code is telling me! :-)

    I just loaded the code into an editor, and reformatted for clarity

    <?php
    /*
    Plugin Name: jbs_own_plugin
    (etc....)
    */

    add_filter( 'get_profile_info_keys',
    array('user_email' => array(1, __('Email')),
    'user_url' => array(0, __('Website')),
    'from' => array(0, __('Location')),
    'occ' => array(0, __('Occupation')),
    'interest' => array(0, __('Interests')),
    'extra' => array(0, __('Extra'))));

    ?>

    Basically, it was missing a closing ) and semi-colon on the line. I cant promise that it does exactly what you are after, but this ought to solve the PHP syntax error. :-) Good luck.

    @chrishajer – D’oh! You’re right – it does say when an email is already in use. What was I thinking? ;-)

    I’ve also seen the situation you are talking about where a user registers a new account but the email address matches one that is already in the database. In that situation bbPress silently kills the registration – no email is sent and no notification given of the “duplicate”.

    One of the best little chat-boxes I’ve integrated into a forum was from Meebo – they provide nice levels of customization for size and how it looks. If you use the Meebo chat box, you can have someone edit your front page template to include it. Anyhow, take a look at http://www.meebo.com for more details.

    “bbPress without backpress” is not the same as “bbPress 0.9”

    In version 0.9 there was bbPress specific code to perform a variety of functions. Those method calls were migrated to use a sub-set of the WordPress codebase (“backpress”). That became version 1.0 … and what was done was to move from “a subset of WordPress” to “the whole of WordPress”.

    A more accurate statement would therefore be that bbPress specific code was dropped, it moved to using WP features divorced of the rest of WP, and then was made to work with WP as a whole — a continuation of forward momentum and not a step backward at all.

    As far as I know, there’s no way to modify the text from the admin area of bbPress. However it’s not that hard to find the file to change – if you look in either ‘bb-templates’ or ‘my-templates’ you will find your theme. In the theme directory you’ll find “register.php” – you can make your edits there.

    I’ve put up a diagram of the current (1.0.2) database schema – http://devt.caffeinatedbliss.com/bbpress/bbpress-data-model – and I plan as a next step to dig deep into the bb_meta and bb_user_meta tables as there’s a goldmine of important details tucked into them that isnt immediately obvious.

    OK, now THAT is one fantastic design – innovative and clean. I like it!

    In theory you would make a backup of your my-plugins and my-themes directories. Then, delete the files in your existing bbPress install. Next step, run through the famous “5 minute install” of WordPress, and download the bbPress plugin and activate it. That’s the obvious part.

    I would assume that a bbPress plugin would create a new top-level menu in the WordPress admin area. In a brand-new install, this would allow you to create the bbPress specific data structures in your database or to migrate existing bbPress data from an old version. After that step, the bbPress admin menu would switch to showing admin options for forums / topics / posts, etc.

    My guess (if data structures remain largely the same) is that the “installation” of the plugin would merely write a WordPress option value telling the bbPress plugin what its database prefix is, and all the data already there would appear automatically.

    Assuming that a bbPress plugin is connected to its data, it would need to be connected to the GUI somewhere. My guess is that you would create a WordPress static page and its content would be a short-code that the bbPress plugin replaces with its entire display.

    @kevinjohngallagher

    … but if you give the data-structure to a DBA or heck, a basic developer they’ll scratch their heads.

    The datastructures underpinning both WordPress and bbPress are shocking to me, as a senior level developer. Just because you can do a thing doesnt mean you should do a thing; just because you have “*_meta” tables that store key/value pairs (that is, post_meta, user_meta, topic_meta, etc) doesnt mean that you should use them for absolutely everything. Tables like those are a commercial DBA’s worst nightmare.

    There is no way to set any forum as read only, or hidden, or anything else. Forums don’t have settings, and why is that? because they’re exactly the same as categories in wordpress. Which suits the current need of one type of forum, and that’s one that has no need for parentage (such as this forum and the WordPress support forums).

    bbPress was originally designed to be simple and lightweight. There are heavy-weight PHP based forums out there and I dont believe that bbPress was designed to compete. Lean, mean and simple seem to be the guiding principles, and it shows. The design of the code is very much the minimal working set you need for a basic forum. Problem is, people expect more, so you get to the point of needing a half-dozen plugins to reach the new “baseline” expectation. Suggests to me that certain plugins need to be [a] pulled into core and need some decent data-modelling done before getting released as “core” functionality.

    Hey has anyone used XML_RPC to post to their forums yet? it’s awesome…

    ROFLMAO

    I’d like to stress i’m not advocating a massive change to the core, honestly I’m just up for discussion. I’m really just wanting to know people’s feelings or thoughts on this. Far too much data is not readily/intrinsically/obviously available especially when said data is on a predefined 1-to-1 relationship.

    I would be willing to go through and document the database, including a nice clear diagram. I would also be happy to talk (deeply) about database design issues. It wouldnt be hard to pull together a patch to submit to Automattic to enhance the internal data structures. The issue I have though, is the number of plugins that would need to be massaged after such an event. Still, I’d be up for it.

    @johnhiler

    My general sense is that most of what you describe can be pulled off with plugins…

    Adding the end-user functionality, yes, but the issue isnt so much the functionality as the data-structures a plugin needs to wrangle to accomplish its desired purpose. Right now the low-grade of data model design hurts.

    @Marius-

    I would love to have a dynamic sidebar I could add or remove things with ease. Have polls on the sidebar, not arrested in a topic, and maybe a chatbox instead of having an “Off Topic” category or thread.

    I would like to see all of the major pages in bbPress be “widget enabled” – the “forums list” and the “topics list” simply be widgets, the heat-cloud for tags be another and so on. That would allow me to create an alternative display of topics, and drop it onto my own forum wihtout needing to hack the template.

    Not to be too controversial here, but if/when bbPress becomes a WordPress plugin, we would get that functionality for free, pretty much.

    I really enjoy the beautiful minimalism of BBPress, and I dont want it to get more complicated.

    Amen! Preach it brother!

    I am currently working on a plugin that adds import capability to bbPress. The framework provides a 4-step wizard

    1. Choose the input source
    2. Configure the import
    3. Verify what you’re about to import looks good
    4. Perform the import

    The “importers” for the first step are read dynamically, to allow for easy extension. The parameters names for step 2 come dynamically from the selected importer and the values entered are supplied to steps 3 and 4. The plugin provides methods for creating users, posts, topics and forums, the importer provides the methods needed to get that data from whatever the input source is.

    My experiment was to import a fake phpBB 2 forum (3 users, 2 forums, and maybe a dozen or so posts). All looks good. I would value other sets of eyes on the project though. What would be awesome would be other people to write some importers for other platforms. The framework is there in the plugin, it just needs extension into the other platforms.

    7:00 – 7:30 EST – silence, no-one arrived.

    7:30 – 8:00 EST – chit-chat about the positives of Chrome as a browser, and a couple of bbPress topic/post admin related feature requests.

    Basically, extremely quiet.

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