cuny-academic-commons / commons-in-a-box Goto Github PK

Set up a system for interacting with APIs via HTTP actions.

Have to decide between one of two schemas:

• a single API endpoint, like example.com/api/v1/; and
• a more RESTful strategy where you interact with content at URIs - eg example.com/members/boone/

Research forthcoming

We need a way for plugins to register their dependencies (or for us to register them on their behalf). Must decide on the data model as well as the technical means of storage (a separate manifest file, plugin header, defined constants, etc).

Hi @r-a-y -

As we've discussed before, we'll want to have links from the cbox plugin list (in the Dashboard) to our commonsinabox.org documentation (on the website). I was thinking it could work like this:

• In the register_plugin() method, accept a parameter 'documentation_url' or something along those lines.
• 'documentation_url' would have a default value concatenated like this: 'http://commonsinabox.org/documentation/plugins/' . $plugin_slug (eg http://commonsinabox.org/documentation/plugins/buddypress-docs)
• Render 'Documentation' links in the following places: 1) On the Cbox Plugins page, and 2) in the Quick Links box

Does this sound like the right approach? Does it sound do-able?

There will be other documentation links throughout the interface, but they'll probably mostly be hardcoded, so let's worry about that separately.

Mary reports issues with BP Docs upgrade:

She says she gets the following:

Thanks for updating BuddyPress Docs. We need to run a few quick operations before your new Docs is ready to use.

Click here to start the upgrade.”
And when we proceed to upgrade the screen says ”migrating” and continues on endlessly. The status bar flashes quickly indicating the program is accessing various locations including the host site but it never completes. This is not unique to commons in a box, it appears others are having similar problems for the last five days or so.

Don't know if this is a known issue. She says other have noted it.

There may be some cases where Commons In A Box wants to change the settings that a plugin saves in the database upon activation, but only to do it once as opposed to filtering it at runtime. We'll need a separate system in place to get this working.

If you attempt to update WP from "Dashboard > Updates" in the admin dashboard, it will fail because CBOX includes the Plugin_Upgrader class ahead of WP and WP does not check to see if it already exists.

Error message below:

 PHP Fatal error:  Cannot redeclare class Plugin_Upgrader in \wp-admin\includes\class-wp-upgrader.php on line 632

Giannis reports that he created a doc (only one), but when he looks on his profile page, the number of Docs is displaying as 4. He did this on the demo site.

http://demo.commonsinabox.org/members/giannis/docs/

On a clean install of WordPress 3.4.2 and CBox master branch I get an update notification in the Dashboard > Updates and Plugin admin fly-put menus. I also have an update icon in the Toolbar showing one update available when viewing the front end of the site.

When I navigate to the Updates admin page it says everything is up to date. Let me know if this is already a know bug or if you'd like me to investigate further.

This would be something like oAuth, but in the meantime I just need to put something in place to provide dummy values in the Server class.

Amelia Manders reports in http://commonsinabox.org/groups/help-support/forum/topic/group-admin-menu/ 👍

When I click on the Admin link inside a group my menu display like this, defaulting to Details.

Details | Setting | Avatar | Members | Group Blog | Email Options | Docs | Forum | Delete

It stays the same for Settings, Avatar, Members, and Forum

When I click on Group Blog, it changes to:

Details | Setting | Avatar | Members | Group Blog | Delete

When I click on Email Options, it changes to:

Details | Setting | Avatar | Members | Group Blog | Email Options | Delete

When I click on Docs, it changes to:

Details | Setting | Avatar | Members | Group Blog | Email Options | Docs | Delete

Sorry if this is a known issue.

Before we release 1.0-beta2, we'll need to type up a changelog for the readme.txt and for the "What's New" page.

Here's a brief rundown of CBOX core changes:

New Plugin

BP Group Announcements - (recommended) creates a new tab on a groups page for group administrators to post activity updates.

New Features

CBOX Settings page - configures some special options for certain CBOX plugins

Plugin Updates

• bbPress 2.2.2
• BuddyPress GES 3.2.2
• BP Docs 1.2.6
• BP Docs Wiki 1.0.2
• CAC Featured Content 1.0.3
• External Group Blogs 1.5

Would be nice to add a general CBOX Theme changelog here as well!

I'm also working on RBE this weekend so it'll make 1.0-beta2. Trying to add bbPress support, but might ditch it if I don't have enough time!

When I click on Forum>>New Topic, I have to scroll all the way to the end of the page to find the place to enter the topic. On the Commons, there seems to be some script in place that immediately brings you to the appropriate place - i.e. you just can start typing.

I think that might be why a lot of people end up using the Announcement section when they really should be using the New Topic dialog.

Thanks.

It would be nice to use the text-free, b&w version of the cbox logo as the screen_icon() throughout the cbox dashboard (currently we use a mix of theme, plugin, and index screen_icons()). Not urgent, obviously :)

I've started testing out CBox so I can contribute to the development discussion and documentation as we move closer to an alpha release.

First I just wanted to say, all of you are badasses! CBox is slick, user friendly and a breeze to use. I had NO issues whatsoever getting it installed and setup. The theme is BEAUTIFUL and the features look more like a 2.0 release than an alpha!! :-)

For my first issue here I just wanted to point out a small error in the path to the image for the Features custom post type menu item. It is currently set to:

'menu_icon' => get_stylesheet_directory_uri() . '/base/feature-slider/assets/images/slides-icon.png'

But it should be:

'menu_icon' => get_stylesheet_directory_uri() . '/engine/includes/feature-slider/assets/images/slides-icon.png'

To install CBox I just cloned the master branch. I assume the directory structure of the cbox-theme changed and line 34 of setup.php wasn't updated to reflect the change.

As a member of the cuny-academic-commons Github account I have read-write access to the cbox-theme repo so I can push this change if you'd like me to. If so, please let me know if you'd like me to push directly to master or in a topic branch.

CBox currently has a theme installer for the CBox and Infinity themes, but it doesn't have a theme updater. This was intentionally left out initially to see if Infinity had their own updater routine.

Bowe just confirmed that Infinity has some type of updater (needs investigating), but the CBox Theme will need to have one for sure.

For the theme updater, do the same thing as the plugin updater.

I think we should follow the precedent established on the CAC and have member profiles show static identity information rather than activity as the default. We made that decision on the CAC because we wanted people to use profile pages to create profile pages they could link to, something that shows their identity, rather than to a list of recent activity items.

http://wordpress.org/extend/plugins/bebop/

Kathy Tarochione reports:

"OMG, I just updated the BuddyPress and my whole site crashed. Here is the error message. Help!! Warning: array_merge() [function.array-merge]: Argument #2 is not an array in /home/content/71/9796971/html/harrisoninsiders/wp-includes/widgets.php on line 777

Fatal error: Class ’BP_Group_Extension’ not found in /home/content/71/9796971/html/harrisoninsiders/wp-content/plugins/external-group-blogs/bp-groups-externalblogs.php on line 4

Now I can’t get into the site at all to edit. HELP!!"

Ray, this might ultimately be translated into a BP ticket.

At the very bottom of the API stack (where "bottom" means "closest to WP") is the BP action class - see #8.

At the very top of the API stack will be a set of listeners: URL endpoints that are ready to receive requests via REST (this will be the standard way of interacting with the API), but we'll also have to allow for additional kinds of interactions (like when API actions are triggered by user records from Oracle, etc.) See #10.

Between these two layers, there should be a small number of functions that will take the standardized output from the listeners and turn it into the proper actions.

Because CBOX dashboard inherits styles from the WP admin CSS, since WP 3.5 drastically modified the look of its dashboard page, it also changed the look of the CBOX dashboard.

I'd like to get rid of the intense gray used in WP 3.5 and revert back to the clean white from WP 3.4.

Before I do this, let me know what you guys think.

People are finding the group homepage confusing -- please read through this thread - http://commonsinabox.org/groups/help-support/forum/topic/bp-docs-wiki-and-forums-questions/?view=all#post-1008

"Let me understand this properly: FROM WHERE did you move my topic into the forums? I am sure I posted them in the forums… I went to COMMUNITY => Help And Support, joined the group and posted there which is here, exactly here where we are writing right now!? Totally confused"

I think that the solution to this is to follow what we do on the CUNY Academic Commons:

1. Remove the ability for people to add comments directly to the activity stream on the homepage of the group (the problem is that, upon, joining a group, most people will post directly into the textbox there rather than visiting the forum and posting there)
2. Redirect the "reply" link in the activity stream to relevant forum posts.

The whole here is to centralize as much activity as possible in the forums, where they can be easily found and retrieved, rather than having a bifurcated system where some comments go in the activity stream and some go in the forums. Just take a look at the comments above or at Scott's heroic efforts to move comments from the activity stream to the forums to see why this is needed.

See #5

Hi Ray. I had a request to make bp-groupblog one of the plugins we auto-install. Could you make it happen?

Once we have a way to proclaim dependency (#1), we need a way to parse that dependency, and deliver a set of to-dos to the user, or to our auto-upgrader

We've had a few reports of parse errors on line 88 of includes/frontend.php, where we do the following:

new static();

I assume that what's happening here is that the hosts are running PHP < 5.3, and PHP 5.2 can't even parse this line, even though Commons In A Box doesn't actually instantiate this class anywhere.

I'm going to just remove CBox_Frontend_Init for the time being.

Gary Davis reports that he set up a group, enabled forums, and upon adding the first topic, the topic page displayed a bank (white) page.

I tried the same and was able to reproduce the error.

Boone, in another issue thread, we're discussing the creation of a new plugin that would be on the recommended (auto-installed) list of CBOX plugins. How will that work for people who have already installed CBOX?

Hi - Gary Davis reports having issues when he installs BP External Group RSS.
" the site goes blank…. every page no less, can’t get any page to work. All the files seems to still be in the directory so I suspect all pages are pointing to a default blank page. Note that I did update anything that requested an update prior to these events."

I was not able to reproduce - I installed the plugin on my test site, added some RSS feeds and it seemed to work fine for me.

He is running locally on a Mac.

Hi - This is low priority - but can we add an icon on the group forum post toolbar that lets you easily add an image - rather than using HTML img tag? Also think this is an issue on the Sitewide Wiki. toolbar.

A class that has wrapper methods for any sort of action you might want to perform via external API. Start with the following (requested by MLA):

• Group membership (join group, leave group)
• Profile field management (get profile field data, update profile field data)

Assigning to myself for now, but we can toss this around.

Installation Details:

Fresh WordPress 3.4.2 install
CBOX Bleeding
LAMP Server
Single WordPress

What happens?

After CBOX is installed and the default plugins have been configured you go through the BuddyPress setup. When you go through the BuddyPress setup and click on "Finish and Activate" my install the following error is thrown

Fatal error: Declaration of BP_OAuthStore::listServers() must be compatible with that of OAuthStoreAbstract::listServers() in /home/bowe/domains/infinitythemes.net/public_html/commons/wp-content/plugins/commons-in-a-box/api/oauth-extensions/BP_OAuthStore.php on line 5

Only way to fix the white screen is by disabling CBOX again.

Got to figure out a schema that will match authentication tokens with authorization levels for specific API actions (specifically POSTs, but also some GETs that are accessing private data).

Right now I just have a dummy endpoint in place. Endpoint should have a form like:

/api/v1/members/membername/
/api/v1/groups/groupname/

etc. Need an optional parser for this.

Right now I'm just dumping the request. Should have:

• Mechanism for requesting return format (json, xml, raw). Could start with just json
• A fallback when no option is specified
• Then I have to format the results and echo them out properly, with the right HTTP headers

In part because of the bug described here http://bbpress.trac.wordpress.org/ticket/2082, and in part because it's more helpful for user engagement in Commons In A Box-type communities, we should intervene in the GES process and provide full reply/topic content. See http://redmine.gc.cuny.edu/issues/2297

As the co-author of a recommended plugin that's installed on CBox by default, I feel a responsibility to ensure the widget looks right on the CBox infinity theme. I don't think new users should be required to adjust the css of a recommended plugin right after installation.

When developing the plugin I made sure the HTML layout matched the BuddyPress default theme's sidebar so it would fit right in with the other widgets on a plain vanilla install. I think I should do something to make sure this holds true for CBox as well.

Right now the CBox infinity child defines border-bottom: 1px solid #EDEDED; on line 3142 of dynamic.css. This causes the <h4> in the plugin's HTML output to have a border that cuts underneath the <img> tag that is being floated to the left. I think a simple fix for this would be to add border: none; to the plugin's cfcw-default.css stylesheet, but I wanted to get everyone's feedback before adding it incase there's a simpler or more elegant fix.

Not sure how to do this. Probably we'll just drop BP Group Documents - but the UI part of it (a group extension for group files) should definitely be carried over.

Today I added buddypress-docs-wiki to the Recommended list of plugins. It requires BuddyPress Docs 1.2 - I bumped that version requirement too. Then I tried to install buddypress-docs-wiki through the admin interface. It downloaded successfully, but then would not activate (on the plugins page, it remains unchecked). I'm assuming that this is because of the missing BP Docs 1.2 dependency, but there is not good feedback about this.

Maybe related: the requirements notice under Wiki look like this:

Requires: BuddyPress (>=1.5) (enabled), BuddyPress Docs (>=1.2) (enabled)

BuddyPress Docs is, in fact, enabled (the custom post type is present), but (1) the Docs box is unchecked (presumably because I haven't upgraded), and (2) it would be nice if this Requirements list said something about the fact that my installed version of BuddyPress Docs isn't high enough.

I'm hoping this is just an interface issue and not something with more underlying logic. Would you mind having a look? Thanks :)

For brand-new BuddyPress installs, we should consider disabling the "Discussion Forums" component, so these installs can use bbPress from the beginning.

Also, make sure bbPress is setup so BuddyPress groups work as well.

We're getting a few support threads about this, so we should either add some defaults or have an article on the BuddyPress codex or CBOX documentation site explaining this in-depth.

This won't be an issue when BP 1.7 will only have the members, settings and profile components enabled by default.

Must consult first with UX folks.

CBox must be able to install/update its child plugins. Can we leverage WP's plugins API? What do we do about cases where server permissions block auto-installs?

@r-a-y You mentioned that you knew of plugins that do some of this. Have some links?

From cbox.org usersupport: http://commonsinabox.org/groups/help-support/forum/topic/wiki-edit-link-malformed/#post-980:

User 1: "The Edit tab on wiki pages in demo.commonsinabox.org contains a malformed link. E.g. on http://demo.commonsinabox.org/wiki/one-sweet-wiki-page the Edit tab improperly points to http://demo.commonsinabox.org/wiki/one-sweet-wiki-pageedit/ instead of http://demo.commonsinabox.org/wiki/one-sweet-wiki-page/edit "

User 2: "The history link does this as well"

Users should have the ability to decide what should be displayed in different sections of their profiles. Examples:

• RSS widget
• Recent activity, filtered
• Recent activity on another service (Twitter, Flickr, etc)

In a super-ideal world, this would somehow interface with the WP widget system.

I know that this is a potentially enormous job. It's pretty sketchily described in our grant proposal, so we shouldn't feel like it has to be done in the most robust way possible. But at a minimum, it would be nice to think about some ways that users could have at least minimal control over what appears in their profiles.

Need a way for CBox installations to make REST requests of other CBox installations. For now, really just need a skeleton (so that they can be called manually).

What is the format of writing. Po and. Mo for the translation into Spanish.
(box_Es.po)

Has there been any discussion about using one of the third party comment management systems in CBox?

http://disqus.com/
http://www.intensedebate.com/

The goal here is be able to send HTML-formatted emails in WordPress.

Admins should be able to modify the HTML template from the WP dashboard and BuddyPress users should be able to turn off HTML format in their settings panel.

A very good plugin already exists for WordPress - WP Better Emails. My initial idea is to create a companion plugin for WP Better Emails for use with BuddyPress. This will allow BuddyPress users to turn off HTML-formatted emails and use plain-text instead.

Update: A first pass of the WP Better Emails-BuddyPress companion plugin can be found here:
https://github.com/r-a-y/wp-better-emails-for-bp