Michael

Issues with third party skins are the responsibility of the skin authors to fix. If there are issues with the default skins included with IP.Board, report them as bugs in the bug tracker.

Given most issues are upgrade problems and possibly mods I suppose the logical step would be stop upgrading or making any changes and thus not renewing.

Under "Manage Applications & Modules" I think it should be possible to order the links regardless of their category. Please consider adding the ability to reorder like this for a future release. My desired order would be:

CCS | Forums | Blog | Gallery | Members | Calendar | Subscriptions


Kindest Regards,

Andrew

It's not that simple though, is it?

When we get tickets from people saying "my board is slow" - if our response is something along the lines of "Well you're using a resource intensive feature on a huge site on a shared server - turn it off and you'll be fine", it rarely goes down well ;)
"But my board depends on it!", "You shouldn't advertise a feature that doesn't work!", etc...

It is actually feasible. IPS might have added a security check into some random form's template in a new release, and the custom skin failed to include that, thus opening a hole for some type of injection or other malicious activity.

It is actually feasible. IPS might have added a security check into some random form's template in a new release, and the custom skin failed to include that, thus opening a hole for some type of injection or other malicious activity.

It was largely my decision to remove them from topic view, so let me explain my thinking. I don't believe they serve much useful purpose to most topics on most forums. I looked extensively at a number of IPB's while developing IPB3, and very few people used them. It was an additional wasted column on forum view. It is easy to replace the default icons, yet I don't think I've ever seen a board that did it, other than yours.

Now, some boards will have a use for specific icons, like in Garrets screenshot, but I doubt it's many personally. Post icons are very rarely brought up. The other problem is what do we include? We can't include any images that contain language, so dumping 150 images marked 'wrong', 'upset', 'culture' etc. is out of the question. So that leaves us with the 'mood' emoticons, which I agree aren't very useful.

The combination of the fact that very few people use the feature as it was in 2.3, and the fact it's difficult to include anything useful by default, and the fact there's little demand, means it's not really high on our list of things to include. Perhaps the biggest issue though is this would be superseded by tagging, which we've said will appear in a later 3.x release. That'll give everyone a more flexible system of marking topics and any other content, without us investing time in a narrow feature like post icons.

Hope that explains it :)

I'd like to be able to choose to attach to a new post an attachment I had made to a previous post (rather than having to re-upload the attachment).

This would be useful if I wanted to attach a bunch of photos in a "gallery post" and then include one of the photos in a blog post just by using the attachment BBcode.

I suggest you would have an "attach previously uploaded files" section in the post form that when clicked on pops up (or opens a hidden div) that shows a list of the previously uploaded attachments by the user ordered by most recent first and paginated with an "Add to Post" link next to each attachment in the list.

This "Add to Post" link would simply paste the bbcode into the post. Then, the bbcode parser would process the attachment by looking up it's id and verifying that the id belonged to an attachment made by the same user and would display the attachment just like it would one directly attached to the post.

This is a small enhancement, but it would encourage users to upload more attachments into a single "library" post and then show them off in their various posts where they can give the attachment a better context.

Ok, that's done. From 3.0.4 you can use:

$postClass->setBypassPermissionCheck( true );

And it will not bother you with user based permission errors. It still ensures you sent across a proper user and that the forum is capable of receiving a topic/reply/edit.

So, basically, developers are left to help themselves. Nice one. Ignore the people that extend your product and functionality.

And no, that's not the only documentation I was looking for. A "getting started guide" doesn't cover everything though, and barely covers the "getting started", from one person (or group of person's) perspective, which doesn't help much. Sure, it helps a person get 'started' using your product, but what after that? What about when a user wants to change a theme? Of course, there's no 'documentation' for that.

You need real documentation, not just a guide to how to get started from a few people's perspectives. I get that the product is 'new', but you need at least the basic product documentation and howtos up before you release this stuff. Otherwise, you end up dealing with customers that have no idea what's gong on, all because you couldn't write documentation beforehand.

lol @ -rep for posting honest feedback, nothing new there I guess.
The point of this thread is to provide feedback. Just because someone doesn't agree with it doesn't mean it's not appropriate, or deserves -rep.

Is the software decent? I can't say, its only been a few hours , but it does look decent.

Is the support acceptable? From what I've experienced (so far), not in the slightest. If putting something in the 'wrong department' (which it wasn't) means it's going to get delayed 12+ hours, then perhaps those understaffed departments need more staff, or people need to think outside of the box, and stop listening to ticket systems as to when to help someone.

Anyways, the feedback's been left. No, it's not an unreasonable expectation to want tickets answered same business day at all, especially when one is a new customer.

If they did something like this, then some folks would complain that they should be included in the group. Should a person who created one really big nice mod be in the group? Or should a person who created 10 small mods that don't really work be in the group? It's too hard to come up with reliable guidelines that they can set as the group requirement, and IPS has enough on their plate as it is.

Amen. It's requirements like that that force people to have to write down their passwords, thus defeating the purpose of the security gains you're supposed to be getting from having these requirements.

I'm all for stronger passwords... just as long as the feature is suggestive, like a color coded meter showing how strong the password is. I HATE sites that force you to have at least 8 characters, contain 1 number and letter, and/or change your password every X amount of time.

this is like trying to talk to a friggin wall...

As soon as a point upgrade doesn't need to modify several hundred files, most likely.

As soon as a point upgrade doesn't need to modify several hundred files, most likely.

Probably just about as many as use the media link dropdown! :thumbsup:

Actually, I'd trade the media link dropdown for a special characters dropdown any day.

Are the reports they can't see from forums they actually have moderator privileges to? I believe those permissions do get checked when determining which reports to show.

We will not be adding it back in. It inevitably leads to the "how can I reindex member numbers sequentially" and "how can I change my member number" topics from users who don't understand the technicalities behind it.

According to their standards of service, IPS has up to 2 days to respond to your ticket. This topic isn't feedback...

According to their standards of service, IPS has up to 2 days to respond to your ticket. This topic isn't feedback...

According to their standards of service, IPS has up to 2 days to respond to your ticket. This topic isn't feedback...

According to their standards of service, IPS has up to 2 days to respond to your ticket. This topic isn't feedback...

Since it often happens that a new version gets released, some bugs slip through the testing process and a new build of that version needs to be uploaded to our client centers, I think it would be very helpful if the Your Downloads page where we download our copies of the software showed the date (or some other such indicator) of when this particular version was last uploaded. Maybe a build number there would be a good idea instead?

I'm just thinking of all of the topics we get where folks talk about bugs they have that have already been fixed, but they might not necessarily have known the version was rebuilt.