[@jeffsayre Participant 16 years, 7 months ago]

I’ve responded on your other thread:

https://buddypress.org/forums/topic/internal-server-error-after-activating-bp?replies=3#post-42971

[@jeffsayre Participant 16 years, 7 months ago]

First of all, an Error 500 (internal server error) message usually means something is not working properly with one of the software components on you server. It is not directly a WordPress or BuddyPress issue.

I’m guessing it’s an issue with your PHP install. Forcing the server to run PHP 5 instead of 4 may do the trick–assuming your site is being served under PHP 4. This is just an initial guess. See these threads for more detail:

https://buddypress.org/forums/topic/error-500-internal-server-error-an-internal-server-error-has-occured-please#post-23821

https://buddypress.org/forums/topic/500-error-after-uploading-buddypress-102#post-18421

However, there could be something else causing the problem. What you need to do is distill your environment down to the lowest common denominator. Make sure WordPress is working fine by itself before installing BuddyPress. To do that, you deactivate all other plugins and test WP by itself. If it is working without issue, then you reinstall BP and activate. You should not have any other plugins besides BP activated and you should be using the default theme that comes with BP when testing.

By the way, I suggest doing a clean install of BuddyPress. This means making sure the entire BP directory is removed and then starting over with a clean install of BP. Of course, as always, backup any data before you do any upgrades or reinstalls.

If you do not have any issues with WP running only the BP plugin using the default BP theme, then you know it has something to do with a custom theme, one of your other plugins, or some combination of the two.

You then start going back up the ladder one step at a time. Switch the default BP theme to your custom theme. Does the problem return? It not, then is has to do with your plugins. Activate one plugin at a time until the issue returns.

But, with an Error 500, I’m guessing it is something outside of WP and BP causing the issue. Show the links above to your hosting firm. They are the only ones that can help you.

Also, as another resource, search the WordPress forums to see if anyone there has reported a similar issue.

[@jeffsayre Participant 16 years, 7 months ago]

@oneill1234-

You have a subdirectory install of WordPress. So, the RewriteBase directive in the .htaccess file needs to point to that directory. Change this:

RewriteBase /

to this:

RewriteBase /community

[@jeffsayre Participant 16 years, 8 months ago]

@Tyler Regas-

Haha! No problem.

Privacy, permissions, authorization, ACL (access control list), and even security could all be used to describe this topic. So, I understand.

Suffice it to say, this issue is being worked on, it will just be a little while longer.

[@jeffsayre Participant 16 years, 8 months ago]

@idotter-

Work is progressing–albeit slowly.

I do realize that many people are waiting for my marvelous elixir of data obscurity. I am working on it but I have projects with higher priority. I probably only get to spend a day or so each week working on it–much of that time late at night when I’m prone to making mistakes.

But, it is coming along. A late March beta release is not out of the question.

[@jeffsayre Participant 16 years, 8 months ago]

So, how many people are employed by Auttomatic to work on this project?

One. Andy.

I’ve been poking around for some time and I’m a little surprised that not one person has been confused by the complete lack of security in BuddyPress.

You need to poke around a little more.

https://buddypress.org/forums/topic/privacy-1

https://buddypress.org/forums/topic/privacy

https://buddypress.org/forums/topic/buddypress-privacy-component-an-update

Also, privacy is on the BuddyPress roadmap.

As Andy states, implementing privacy in BP or any social network is not an easy task. I am working on updating my older privacy component to work with BP 1.2 and WP/WPMU 2.9.x. It will be awhile longer before I have a working alpha for testing. But, privacy is coming to BuddyPress!

[@jeffsayre Participant 16 years, 8 months ago]

@Erich73-

Haha! I appreciate the thought. I’m sure Automattic is able to afford to buy many things! I have no issue with Automattic. I do not expect them to pay me.

@everyone

My code, like any other GPLed theme or plugin is freely available for all to use. So, if Automattic wants to merge my code into BP core, I would be honored and not expect anything else in return.

I hope that my posts (in this thread and on my website concerning this issue) do not come across as me being bitter. That is not the case.

I fully support and believe in the Open Source model as expressed via the GPL. I also believe in giving back to those Open Source projects from which you have benefited. I of course have done that with the hundreds of hours I’ve donated as a moderator on these forums.

The referenced-to post above was just my attempt to try to figure out a possible way where I could actually earn part of my living by creating great-quality plugins for the WordPress / BuddyPress community. I think talented programmers should be able to do that without having to resort to consulting. I have no interest in providing consulting services. I owned a consulting company for 7 years. It was great, but I have no need or intention of going back down that road.

So, enough said with all of this stuff about me and my needs. I appreciate people’s concerns and suggestions.

Let’s put this thread back on track. Please try to limit your comments to the future of privacy in BuddyPress and not about me!

[@jeffsayre Participant 16 years, 8 months ago]

@idotter-

Eventually my plugin will encompass group and blog privacy as well.

@paulhastings0-

The graph represents about $125 of funding–which is close to my original goal!

I never expected to achieve the funding goal. That post was for two reasons: an experiment to see if raising development funds was even feasible; an awareness campaign to get people talking and thinking about plugin developers and the vast amount of time that they put into WordPress/Buddyress projects so that the community can benefit from their work.

The goal is an honest assessment of the amount of time (which is then converted to dollars) that I will be required to put into the project in 2010–coding and supporting the plugin. It also covers some of my time already spent on coding the plugin.

As I state in that post, I’m already committed to bringing my privacy plugin up to date to work with BP version 1.2. When that will happen is the question. I am working on it, but not full time as I have another project that has top priority (my startup). Just like anyone else, I must focus most of my efforts on activities that will help me actually earn a living.

Once my BP 1.2-compatible privacy plugin is released, I’m not sure where it will go from there. We will see. Of course, if my privacy plugin gets merged into core (in some form or another), that would be great!

[@jeffsayre Participant 16 years, 8 months ago]

Burt Adsit, a past forum moderator and talented developer, created a plugin that did exactly what you are suggesting. It is woefully out of date. I believe it only works with BP V 1.0. But, some other talented developer could possibly use Burt’s code, adapting it to the current version of BP.

https://wordpress.org/extend/plugins/bpcontents/

[@jeffsayre Participant 16 years, 8 months ago]

Since this forum is meant to discuss possible enhancements for future BuddyPress versions in 2010, the idea of forking the project is beyond scope. You of course are free to continue discussing this topic but it might be better to start a new thread in the Miscellaneous Forums.

As to this example:

Lets say if i want to use Buddypress to set up an organic farming community for example I am going to have many of my users getting confused with having a backend and a front end and all of the options and admin stuff in the backend.

The only reason users would need access to the backend is if the Site Admin has set up their BuddyPress community to allow users to have their own blogs. If the mulitblog feature is not enabled, then users only have access to the frontend menus to set options and navigate the network. Also, the Site Admin could choose to build their community on the single-user version of WordPress. Then offering blogs to users is not even an option.

Whereas your assertion that

…stripping out the WP centric features surely won’t be an issue in the context of running a social network.

might be the case from a user’s perspective, it is a huge issue with regards to the amount of programming and code refactoring that would be required.

I can state with a high-degree of certainty that Andy nor Automattic will not be forking their own creations. The only way I could see that happening is if a few Automattic employees break off and form their own shop.

Why wait for someone else to do it? As I said in my first post in this thread, forking any OS project is a lot of work, but you are free to do so as long as you follow the GPL. If you think you have a unique, under-served vision for the platform, form a team and do it.

[@jeffsayre Participant 16 years, 8 months ago]

@nexia-

Haha! Yeah, I will just have to make sure the code and instructions are perfect so that there are no support requests.

To everyone else:

I will win back my privacy!

I see the +10 and counter with a -10.

I see @podictionary’s +++ and counter with a —

Ah, the Universe is back in balance and I can go back into my cave. Problem solved.

[@jeffsayre Participant 16 years, 8 months ago]

@DJPaul-

I thought as much but I just wanted to make sure I understood what you are proposing.

So, +1. Or, maybe +2 since @nexia has already indicated his support!

[@jeffsayre Participant 16 years, 8 months ago]

As Open Source projects, anyone is free to fork any of the WordPress family of products as long as they adhere to the GPL licensing. In fact, WordPress itself started as a fork of another blogging platform.

However, Automattic will not fork its own products. With Andy as the only full-time Automattic employee working on BuddyPress, there is already too much for him to do with the current BuddyPress product, not to mention that forking your own product is basically creating a competitor.

Forking is not a task that should be taken lightly. Successful Open Source projects require a lot of supporting infrastructure: from a project repository; to an up-to-date and maintained project website; to a core team of developers; to a community that springs up and supports the project fork; to a support forum to offer help to users. These are just a few of the many requirements of creating and growing a healthy OS project.

But that should not stop you or anyone else who feels they have a different vision for the future of the platform to fork it and take it in a different direction.

http://en.wikipedia.org/wiki/Fork_(software_development)

[@jeffsayre Participant 16 years, 8 months ago]

With regards to this thread’s title, if by “linked data” you are referring to the Semantic Web, then microformats do not have anything to do with Linked Data. Linked Data (with capitals) is a very specific entity whereas, linked data (lowercase) can mean just about anything. So, I’m just trying to clearly understand what you are suggesting.

It is important to know that what the Microformats community calls POSH (Plain Old Semantic HTML) is not the same thing as semantic markup which uses RDF classes and properties to model relationships between data. Semantic Web applications are built using a stack of W3C technologies.

http://linkeddata.org/

But I agree that properly semantifying BuddyPress via Linked Data protocols is a great idea!

[@jeffsayre Participant 16 years, 8 months ago]

Well, crap!

I thought I might be able to fade away in my cave, living a private life. But I can see that some of you actually want privacy features in BuddyPress. I guess I will have to get to work.

So, if I vote a -7 will that cancel everyone’s votes out?

[@jeffsayre Participant 16 years, 8 months ago]

I am working on upgrading my Privacy Component to BP 1.2. Here you can learn more about the old version and when I hope to have the new version complete.

http://jeffsayre.com/2009/12/05/buddypress-privacy-component-released/

Also, as you will see on the current roadmap, privacy is a possible feature for BP 1.3

[@jeffsayre Participant 16 years, 8 months ago]

Human-neural interface for instant code-from-brain to Mac programming. Very hush hush and top secret stuff. I can’t provide source to device as only three exist in the world. I can write roughly 20,000 lines of code in an hour with this setup.

When I get bored with this, I switch back to the archaic methods:

1. Coda (comes with Transmit, a great FTP client)

2. Firefox with various addons

3. CSSEdit

4. Tricked-out MAMP standard with custom DNS and mail server for local dev

5. A Belkin DVI KVM to share my big Apple cinema with my MBPro and Mac Tower

6. A few alien programs

7. A few gallons of Tazo Chai Tea

I’ve used just about every IDE known to man–and a few not known to man. I prefer Coda to NetBeans for PHP dev but NetBeans hands down for Python dev.

[@jeffsayre Participant 16 years, 8 months ago]

@thebloghouse-

No worries! You’ve been very clear about your good intentions!

I just wanted to make sure that you realized a freemium approach can allow you to have one version of your plugin hosted on the WP plugin repo and another version hosted somewhere else. If both versions offer real value and are GPLed, there should not be any issues.

Also, since there are a number of people who are closely following this thread, I was providing a general overview of the freemium process and an assessment as to how I think it should be approached. So, I apologize if it seemed like I was singling you out. I was not.

[@jeffsayre Participant 16 years, 8 months ago]

@thebloghouse

…thought about selling our plugin and making some cash per user download but the main inhbiting factor for us was that we would be limiting it’s reach by it not being available in the WordPress repository.

I believe it is important to give back to the community–especially if you directly profit from using any of the WP ecosystem products. That is why many people prescribe the freemium model where you offer a standard version of your plugin for free (this is the one you host on the WP repo) and then offer your premium version on your on site or another hosted site.

It is important, in my opinion, to offer real value in the standard version, not just fluff that whet people’s appetite and then makes them trade up to the “real” plugin. With regard to this point, along with additional functionality, one of the differentiating factors between your standard and premium versions could be support level. You offer basic support for the standard version and more robust support for you premium version. It is up to you to decide what standard and robsut support actually means.

Again, in my opinion and the opinion of many others in our community, themes and plugins must be GPLed. There are certain exceptions like the few I outlined in my first post in this thread. Another exception is if you call a propritary algorithm hosted on a remote server via an API–much like the Akismet service’s code is not GPLed. However, I am not a software attorney (or any other type of attorney for that matter), so if you do want to sell non-GPLed themes or plugins for use with WordPress, I suggest you contact one before doing so.

Since a lot has been written about the GPL issue, I suggest searching the Web for more details if you’re interested.

[@jeffsayre Participant 16 years, 8 months ago]

You’re welcome.

By the way, here is a succinct explanation of what the GNU AGPL is all about:

http://www.fsf.org/licensing/licenses/gpl-faq.html#UnreleasedMods

As you can see, there may be a few circumstances where modified code may not be required to be released back into the community under AGPL. But those exceptions would basically mean that the plugin is not being used on a live site, perhaps only on a localhost environment.

[@jeffsayre Participant 16 years, 8 months ago]

You will have to license your work under some version of the GPL that at minimum offers the freedoms that the WP GPL offers.

What others have said above is basically correct. The GPL does not say anything about free as in cost. It is about freedoms of the end user. In fact, the GPL does not discourage developers or theme designers from making money off of their work or someone else’s work.

However, the GPL is very specific in how this is to be done: either by charging a distribution fee, a support fee, or both. So, in effect, you are not charging for the code itself. The vast majority of Premium plugin shops simply charge a distribution and support fee. If their plugins are not GPLed, then something is wrong.

Here are two great links from the GNU website that explain this very clearly:

Selling Free Software

The Free Software Definition

By the way, IMO there should not be a double standard in the WordPress community. Premium theme designers abound. Premium plugin developers should also be afforded the same respect and opportunity. The crucial point is that their work, like premium themes, must remain licensed under the GPL.

Of course, as Matt Mullenweg has stated on numerous occasions when discussing the issue of premium themes, although the PHP must be GPLed, the CSS and JS of the theme can be copyrighted. The same holds true with plugins. But, in my opinion, doing so is just too picky. I prefer to GPL everything–the PHP, CSS, JS, etc.

Now, you could choose to license your work under the AGPL, which is considered to offer more freedoms to the community. The basic difference from the GPL is that any changes made to your plugin, even if for private use, must be returned back to the community. Under GPLv1 through GPLv3, it is acceptable for any code changes to a plugin to remain private if the plugin is never distributed.

One final thought. I’ve stated this before in other places. Many people in the WordPress community seem to be moving beyond the spirit of the GPL, to a more utopian, share and share alike vision. There’s nothing wrong with that if it happens. But the GPL has never been about free as in cost.

[@jeffsayre Participant 16 years, 9 months ago]

@Brajesh, thank you for reminding people to behave in a civil manner. If people want to debate (in a civil fashion), it is best done by starting another thread.

Also, as Erich73 states above, let’s keep this thread on topic. Although many of the off-topic posts in this thread are perfectly civil, debate-style discussion, they do not help further the OT (original topic).

[@jeffsayre Participant 16 years, 9 months ago]

There’s no need to worry about privacy features in BuddyPress. As I have stated previously on these forums and on my blog, I am committed to bringing my current Privacy Component up to code to work with BP 1.2. With the 1.2-beta coming out very soon, I plan to use that to finalize the new privacy codebase.

As it has been discussed before, it will be up to the community to decide the fate of my BP privacy solution. If it is deemed sufficiently useful, valuable, and robust, it will be considered for eventual inclusion into the core.

But, I’ll stress once more, that this is not my decision. Going forward, I fully expect some form of privacy to make it into core down the road—whether it is my code, part of my code, or new code.

[@jeffsayre Participant 16 years, 9 months ago]

Very cool and well done!

I watched the screen cast. It is interesting to see how quickly you can auto embed an external resource.

[@jeffsayre Participant 16 years, 9 months ago]

Just a little heads up about JQuery. If you rely solely on JQ to display or hide certain fields, sometimes you will not get the intended behavior if a user has disabled javascript in their browser. It all depends on what methods/actions you are using to accomplish the hiding.

BP and WP are relying more heavily on JQ scripting to accomplish certain tasks. So, whenever you are coding JQ functions to hide or show certain objects, you have to be doubly sure to test your JQ scripts on all browser types with javascript turned off just to make sure that the behavior is consistent across the board. In other words, will the very small subset of users who turn off JS be able to inadvertently gain access to fields that they are are not supposed to see.

I struggled with this when coding my BuddyPress Privacy Component. It would have been a lot easier to simply have relied on JQ to accomplish many of the privacy filtering functions, but by doing so I would have been risking a given user’s requested privacy by exposing their data to users who had JS turned off.

The lesson here is that if your intent is to truly sequester a subset of data from certain users, JQ is probably not the best solution. I now look at JQuery as simply a nice tool for effects, for UI/UX experience. It is not a tool for basic security protocols.