bfarber

I think you'll like what we have in store for the editor in 4.0.   We actually have a proof of concept up and working already, but it's not done yet.  When we have something to show, we'll blog about it.

There are probably a dozen editors out there and everyone will have their personal preference.  We need something flexible that is able to accommodate the customizations we are going to throw at it (while also being reliable, maintained, etc.).  In our previous investigations, very few editors are up to this task.

There's a reason CKEditor and TinyMCE are amongst the most-used WYSIWYG editors after all.  Nothing against other editors out there of course, but it's hard to compete with a full developer team when it's a one-person show working on the editor in their spare time.   (I'm not speaking of redactor specifically here, I know little about it personally).

Dear IPB,

 

To give you a little bit of background: I've been a user of your product for about seven months now, and am a susbcriber to IP.Board, IP.Downloads, IP.Blog, IP.Gallery, IP.Content (including databases and articles, but not the media system), and IP.Nexus.  My website gets about 5,000 hits a day.

 

These are some things that I would really like to see improved for the community suite as a whole.  These should not be taken as criticisms of any of your existing work, but merely one user's personal experiences and obstacles with using your product.  I'm sure you've probably heard some of these ideas before too, so consider my information to simply be another 'vote' in favor of making particular changes:

• Plugins, extensions, and hooks -- One of the biggest things that makes me cringe is how hard it is to administrate plugins, hooks, and extensions.  First, one thing that I'd really like to see in your Marketplace is to see mandatory information regarding compatibility with versions.  The information is currently optional, which makes downloading and using the plug-in risky.  Second, the plug-ins and hooks could be better centralized in the ACP.  A new System Settings tab in the ACP per developer is too much; all non-IPB plug-ins and extensions ought to be grouped together (or even better, custom grouped by the administrator).  Third, make it easier to cleanly uninstall and delete all files from an extension.  From what I understand, there's really no easy way unless you manually go in and delete the files individually.  This highly discourages administrators from testing and trying new extensions, since his server will be littered with leftover files.
• Consistency -- Consistency in both design and user interface across all of the apps.  IP.Board obviously has much more developed moderation interface than, say, IP.Blogs.   
• Skinning and design -- If you could offer a built-in simple 'skin creator' that offers administrators basic options to change the  background, header, color, and logo, then you will have satisfied the design preferences of a vast majority of your clients.  I would still encourage you to offer skin plug-ins from the marketplace for people who desire a more dramatic change to their community's appearance.
• Balance among the IP.Apps -- Clearly you have a historical legacy of IP.Board being your focal point.  For people who are looking for a broader solution, however, this is almost a handicap since your bias for the forums is manifested in small and large ways.  My only suggestion here is for you to continue your innovation in forum development, but to strike an equally innovative development and balance amongst all of your apps.
• Blocks -- It would be nice to be able to use blocks across all IP.Apps.  It was definitely an awkward moment when I realized that blocks for IP.Content were not the same blocks that could be chosen on IP.Board.

In any case, best of luck on your development with 4.0

 

The plugin system will change in 4.0.

The consistency in the areas you are talking about will be much improved in 4.0.

We already have a visual skin editor available which allows you to click on the front end and change colors visually and easily.  If you need assistance using this tool feel free to ask.

The balance will be improved in 4.0 as forums will no longer be a required component of our framework (you would be able to just buy IP.Content or IP.Gallery for instance).

Blocks in IP.Content can be used in other apps by adding the special block tag to your skin templates.  They are not the same as IP.Blog blocks, however.  This goes back to consistency though which as I said you will see many improvements with.

Personally, I'm not a fan of giving users on a site the power to bulk mail the rest of the users on that site.  That's an administrator-level task IMO.

The Dodo bird had no intentions of disappearing either but, stuff happens. As for migrating to other scripts, I don't expect your 2 main competitors to be around if they keep putting out garbage or taking years for new releases.

Well, we can't really control what our competitors do.

A few questions.
 
1. I understand IP Blog allows for multiple blogs to be operational as a subset within the IPB installation. But it's also necessary for an active blog/website to be focused on a specific topic, for SEO purposes. So my question is, can search engines tell the difference between each blog within the IP Blog framework, or does it look at it all as one large website and penalize for variety of topics? (Bacon, sadness, domesticated squirrels, donuts, artillery production.)

I couldn't tell you... I would assume search engines see "content" on a site and treat it as part of that site, regardless of what page it is on.  You could always modify the HTML template to add a noindex HTML meta tag in the HTML perhaps, if you had concerns.  You could do it conditionally so that it is only added for non-admin blogs perhaps.

2. I understand that in IPB4 the permissions core will be decoupled from IP Forums so that each application can be used in a standalone fashion, separate from each other. So will each application come coupled with the core, such that you will only need one license per application to be able to run them? Or will you also need a core license in addition to an application license in the event that you suddenly want to use one of the IP applications separate from the rest of the suite? (IE for its own installation with its own domain name elsewhere.)

Every application will require the "core" in order to function.  You would need to buy the core + any applications you wish to use.

It is a violation of our copyright to use the software if you do not own a legitimate license.

From reading just the first 5 replies. Well why not hire some staff for just the support forums? They will work free of charge and will help out and answer every topic they can.

I'm not aware of too many people willing to "work" for free lol.

Yeah, what I've done to "overcome" this, Is that I added a custom field that doesn't uploads an image, it's just a text input that takes the url of the image that I previously uploaded to the server, so I can re-use it.

 

Then I added that field to the article template...

You could upload to the media manager and effectively do the same thing.

I'm not sure, beyond being able to edit/disable/whatever the article image field in the ACP, what IP.Content really needs in order to accomplish this.  If we let you disable or change the article image field you could just implement the shared media field or a text input field and then use the media manager. (That's not to say we will change the article image field, just discussing the suggestion itself).

I've seen the suggestion.  I actually mostly agree.  I can't reply to everything unfortunately.

IP.Content has an articles system, and you can restrict permissions for who can submit articles based on permission masks.  Combined with IP.Nexus, you can allow paid members (only) to submit articles on your site.

It would be possible to pull their articles through external feed blocks in IP.Content to then show on their own homepage.  You would need to create the feed blocks for the members, but it would serve your purposes otherwise.

I'm not saying we won't do it, which is why I haven't written that.   I'm making sure I understand the reasons for such a request so that it can be properly considered and weighed is all.

You would be able to "disable" the responsive design in some manner, and I would expect there to be a fixed-width capability somehow.  It's important to remember that we don't just create a single default skin that we expect everyone to use as-is out of the box.  We realize different clients have different needs.

We would almost certainly not maintain a separate mobile skin with our default skin being responsive, however.  Nothing would stop a client from building a mobile skin themself though.