This forum thread is for discussing new features the community would like to see in future releases of the BP Album+ plugin.

All ideas are welcome, no matter how crazy, bandwidth-intensive, or strange …but the final call on what goes into the plugin and when will be made by the development team.

Photos and user interfaces are a uniquely “visual” thing, so when posting an idea to this thread, please try to include a LINK to a website that’s doing the thing you want included in the plugin. For original functions that don’t exist *anywhere* yet, draw a sketch of your idea in a paint program and post a link to the image.

This will make it much easier for users that don’t speak English to understand your idea.

RE: Hey Foxly is it possible to use NetBeans to edit files live on the server? Was just curious because I want to test it out, I currently use GVim.

It depends what you mean by “Live on the Server”.

If you mean “Live on a LOCAL development server”, yes, NetBeans excels at this job. It even automatically refreshes modified files, so if you’re dumping debug info to a text file and have it open in NetBeans, added text will show up in the display sort of like a terminal window.

On the other hand, if you mean “Live on a remote server”, yes it can do that as well. Ideally just by mounting the remote server HTTP directory as a network drive.

I think NetBeans might also have FTP functionality, but I haven’t tried it yet.

@foxly: Have you guys considered publishing a timeline/roadmap like BP has (or maybe you already have and I just haven’t seen it)? This might help others plan their own projects around estimated feature roll-outs.

9) “Like” feature on media items. (Possibly dependent on BP, as I think they’re adding capability to the BP core)

10) Inappropriate content flagging

Then…

At that point we basically match Facebook, Flickr, and YouTube feature-for-feature.

I’m sure after that we’ll get lots of site-specific feature requests (can you add a feature that lets users doodle on their photos, etc) but the core features give you what you need to run practically any website.

In Firefox: Content Encoding Error The page you are trying to view cannot be shown because it uses an invalid or unsupported form of compression.

In Opera: Just random character fill the page

At one point when try to view an image I got this:

Warning: Cannot modify header information – headers already sent by (output started at /home/me/public_html/mysite/wp-content/plugins/bp-album/includes/templates/album/home.php:11) in /home/me/public_html/mysite/wp-includes/pluggable.php on line 868

Can’t test it in IE because I’m at home (with a mac). But I will on Monday.

I did installed it in the plugins directory along with the old one, and in order to test it (live site), I switch the folder name of the plugin to make it active (the old with the new). When I switch for the new (beta) I think that all the previously uploaded images are not there in profiles/photos. Does that mean that members need to re-upload again?

Othewise, there were a few fixes I needed to solve with the old plugin, mainly caused by the fact that my WP installation is in a SUBFOLDER (and surely enough, I am not the only one with such a setup). So please consider coding paths to file so that it works fine for both cases (WP in root and WP in subfolder).

You can find more about it here, with code fixes kindly provided by the other plugin author, Francesco.

The original thread was closed, don’t know why and don’t know by who, without a word to me:

1) You can’t just “switch” from version 0.1.7 to 0.1.9.2, because 0.1.9.2 doesn’t have an upgrade routine (because its a beta). If you install it on a server that already has a 0.1.7 install, all sorts of strange things will happen.

If you really, really want to upgrade to 0.1.9.2, you’ll have to delete all of your user’s uploaded images, delete all of 0.1.7’s database tables, then install 0.1.9.2; but for systems with existing users that have uploaded a lot of media, it’s probably just better to wait until we put out the next release version.

2) BP Album+ works just fine when you install WP in a subfolder. The reason it doesn’t work properly on *your* installation is because you’ve used some “hack” posted on the Internet to modify your installation to hide the subfolder from the URL displayed in the browser.

Guys, there is a lot of VERY BAD advice posted on the Internet about how you can cut and paste code into WordPress to do various things, and a lot of this advice is incomplete or wrong. The hack you’re using only handles *one* way plugins get the base URI, and as you install more plugins you will start to get all sorts of problems.

If you want to install WordPress in a subdirectory, the correct way to do it is to set it up as a virtual host in your apache config file, or using a redirect:

3) It’s relatively easy for us to make the URI’s to media items in BP Album+ configurable, no matter how somebody sets up a WP installation, if that’s what you guys want.

…but based on my research so far, we *cannot* fix the problem with images not showing up in the activity stream on WP installs that are a) in a subdirectory and b) not using a redirect or virtual host method of URL shortening, because of the way *BuddyPress* stores activity stream attachments.

How BP Album+ stores an image URI:

[$offset] + [ / album / 04 / kittens_15.jpg]

How the BuddyPress activity stream stores an image URI (last I checked…. I will research this more when I have time):

So when you use a hack to dynamically change your base URI, BP Album+ can handle it (because we dynamically generate the full URI), the BuddyPress activity stream cannot handle it (because it uses a static URI) and the activity stream post items break.

But the bottom line is, all of this is happening because you haven’t set up your WP installation properly and are using “hacks” off the Internet to mess with your site.

@foxly Well, at the least somebody points me to the right direction about that.

I did suspect that having WP in a subfolder I would run into all kinds of problems with BuddyPress as I go along. But didn’t know about setting it up in another way, since WP just works fine like that.

I will have a look at the youtube links you provide (didn’t do that yet).

Do you think it is possible to use a redirect rule in .htaccess instead of going with the cPanel option from the video you provided? (I do not have cPanel, and I am on MediaTemple), to have images to doisplay fine in the activity stream?

Please note that WP itself installed in a subfolder is not a problem (https://codex.wordpress.org/Giving_WordPress_Its_Own_Directory), and URLs are generated without the subfolder. It is the BuddyPress components that generates the subfolder in URLs/permalinks. And that is the reason why I needed this code (who was provided by r-a-y) to get rid of it:

I believe that as you said, many could be the issues with WP in a subfolder if not handled properly, but I also believe that there are *many* users using a subfolder installation, and probably the core BP should take this into consideration and properly handle one option (root installation) or another (subfolder installation), without having to use workarounds.

I will add a config option to the next BP Album+ beta that lets users set a custom path for activity stream items. But… it will not fix your existing activity stream items, and if you ever change your directory structure after using the option, you’ll lose all your activity stream items again.

Remember, this is a limitation in BuddyPress, not BP Album+

Still, your best options are:

1) To put your WP installation at the HTML root, which will give you the best compatibility with plugins.

2) If you’re running multiple installs in a single HTML root, use virtual hosts.

3) And if you don’t want to learn how to use virtual hosts, you can probably use a redirect in your .htaccess file as you described (that’s what cPANEL does). Note that there could be SEO implications with using a redirect.

Depending on free sites to host your media content is BAD …because every time the other site changes something, it breaks the plugin, and then *we* have to figure out how to fix it for the changes the other site has made.

We can do that for a few sites, but not all of them; otherwise we’d never get any work done on other features. This is why Facebook only allows embeds from a few selected sites, and hosts most of their content themselves.

If you’re running even a moderate sized social community, eventually you will have to do the same, start hosting your own media files.