Mark

Well I certainly hope they do explain a little bit should I need that help. It's no way to learn just to have people do it for you.

Oh of course - if you ask us where a setting is, we'll show you. I think IP.iBaLLiN meant if, for example you said "my members aren't able to log in" - rather than saying something like "okay, well first check this, then that" and continuously going back and forth, we tend to look for ourselves and come back with what the problem was.


The thing I hear most from vBulletin converts is how amazed they are that we'll install and upgrade the software for them at no extra charge :)

I think the point is, while we can appreciate that today you had a ticket that was open slightly longer than usual, and we understand that can be frustrating - a quick look at your recent support tickets shows that this isn't indicative of our normal service, as your original message suggested.

As always, we strive for the best support times we can deliver, however some times we have a larger ticket volume than usual (as was the case today). At all times we guarantee that your ticket will be responded to within 48 business hours, and it seems that we have been delivering this.
We also offer a feature to mark tickets as critical should your forums be completely unusable, in which case your ticket will go straight to the top of the queue, and do also offer options for purchasing phone support, and the Business license which has a shorter (24 business hours) guaranteed response time.

Since there's little more to say and I think this topic is just derailing, I'm going to close it. If you (or anyone) have any other questions or concerns, please do not hesitate to contact customer services or give us a call.

everytime i open a ticket i receive a response in not less than 48h

So, actually, you've never had to wait 48 hours?

Looking at your most recent tickets:

608369: We waited for you to accept our disclaimer, which you eventually refused to do and closed the ticket yourself.
606915: We responded about 4 hours after the ticket creation.
604629: We responded about 40 minutes after the ticket creation.
603845: We initially responded about 15 minutes after the ticket creation, and then you replied on a Saturday, and even then we got back to you about 8 hours later.

In fact, I can't see any tickets that have been open anywhere near 48 hours. I see one that is open now, but that was also only created yesterday.

Am I missing something? If you can provide the ticket IDs for the cases your referring to where you've had to wait, we can see what's going on.

Skins should continue to function so long as you apply the changes in the skin difference report we provide.

Point changes are only bug fixes - we don't "change our minds every twenty seconds" - if there is a bug in the skin... we have to fix it ;)

It's probably best your "friend" submits a support ticket - if they need to renew or whatever we can let them know :)

I believe the plan is to scrap most of what we have in the knowledgbase at some point, since most of the stuff in there is outdated.

Things like installs and upgrades are now here: http://community.invisionpower.com/resources/official.html

Matt did loads of optimisation for 3.0.4. Glad to hear it's improved things for you :)

please leave resource issue to us, just make a option for us to easily turn ON/OFF :)

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...

Any security checks would be server-side and in the source files; them being in the templates would only mean that it could be removed by the client making it utterly useless [that is, the security hole would be there regardless of the state of the skin]. I realize that there are conditionals which are not public-facing, but again, those would not be the final layer of security. The worst that could happen in that regard, that I can see, is that a form key would be mistyped [which there are a couple cases of in prior versions] causing a particular action to not work. Not quite board-compromising caliber.

There is definitely the potential for bad things to happen through custom skins, particularly if the creator includes their own special PHP for whatever purpose, but for a general skin and especially one of Sherri's, I'm pretty sure that would not be the case.

Michael is correct, it is certainly possible, although it's a bit of a long shot.

I don't think it's really appropriate to speculate on what has happened to a particular site - if the owner has concerns they will contact us and we will investigate what happened. At the moment there are no known vulnerabilities in IP.Board's latest supported versions (3.0.3 or 2.3.6).

If you're already a customer, you should submit a ticket in the client area for support. This forum is for feature suggestions :)
If you're not, and are considering purchasing IP.Board - it is possible. Once you purchase, just send in a ticket and a technician will be able to advise.

rct2dotcom is right - you'd need to query the database to get the admin Email address - while in *some* cases we'd be able to still get that info (depending on the nature of the error) - it might not be possible.


What would probably be the best thing to do is make an edit yourself with a hardcoded Email like Dark Slipstream says.
That's actually a pretty simple edit. Something like this should suffice:

In ips_kernel/classDb.php - find:

else if ( $this->obj['use_error_log'] AND $this->obj['error_log'] ) {

Add below:

if ( !file_exists( $this->obj['error_log'] ) ) { mail('youremail@example.com', 'Driver Error', 'A driver error has been encountered on the forums!'); }

The if( !file_exists ... bit is to make sure that only one of these Emails gets sent out.

Maybe also for system settings? For example, which value to change and where if you want to turn your board off via phpMyAdmin if the board is inaccessible.

Settings are cached - you can't just change the value in phpMyAdmin.

Yes.

The OP has requested this topic be closed. I would just like to reiterate that if anyone believes anything is missing from our documentation - this can include ACP pages you feel needed articles which do not currently have them, or guides you feel need to be written, then please PM me and I will add it to our list. But we do not intend to release one all-encompassing manual.

Actually, the key you get is entered in ACP > System Settings > IPS Apps (tab) > IPB License Settings

But that has nothing to do with downloading resources, like m4rtin said.

In fact, does this key get verified somehow? I think I have tried a lot of time ago to erase it to see what happens, and if I recall nothing happened...

Nothing happens.
It was used in the past. It may or may not be used again in the future.
We currently ask you what URL your board is installed at and then to validate a board's license we just search our database for the URL.

Tom,

We're kind of going round in circles here. I don't know whether it's just that you don't like the new system, or you're having trouble finding what you need.

If there is something in particular that you are having trouble finding documentation on, please let me know and I will either direct you to it or get something written up if it is not available, but continuously making blanket statements of our documentation lacking doesn't help us help you. Tell us what you want, and we will do our best to provide.

If it's just that you don't like the idea of inline help and would prefer a single manual, then I'm sorry to hear that, but it's what the majority of our customers asked for.

so, which is it? Will there be a manual, or will there not be a manual? Please, do clarify.

The types of documentation described previously work somewhat well (though articles are not documentation by any means) for new users, yet these do not relieve the need for a manual of some kind.

Getting started guides, great idea, and could easily be a 'chapter' in the manual, but definitely don't take the place of it.

Inline help, as well, great idea, but this doesn't cover everything at all, and it shouldn't.

Articles, too wordy and opinion based, definitely not documentation.

There needs to be some sort of manual here, which, as already said before (not by me, mind you) would cut down on needs for support, and promote some sort of customer satisfaction. Somewhere a customer can go and say "ahah, THIS is how I do this", whether it's an advanced customer wanting to learn how to change a theme, or a new customer just wanting a step by step guide to creating a new forum. Both of those are just examples, but you still have a major need for documentation here , because the product obviously does not document itself.

There will not be a single manual. Our users told us it was hard to find what they were looking for, and we found it hard to update. Having one in addition to the other resources we have available would result in duplicate content.

We will continue to expand on the inline help and knowledgebase, and will be releasing our additional walkthrough-type guides soon.

As said many times - the main documentation source is the inline help, additional guides will be supporting that inline help where a particular process either spans many areas of the software or is particularly complicated and examples are needed. Everything that was in the 2.3 manual will be available - 80% of it already is.


While I appreciate that you find a manual would be very helpful, the vast majority of customers I have spoken to find the new system much easier, and it has cut benefited out support department.

I think the fact of the matter is that we cannot please everyone: some users would prefer a large pdf that they can read the whole way through - others prefer inline help that easy to locate a specific article and always up to date. We can't have both, it's just not feasible - we have to go with one and we have gone with the new system.


As always, thank you for voicing your feedback and let us know if you have any other suggestions :)

File Name: Ultimate Referrals 1.3
File Submitter: Mark
File Submitted: 19 Jun 2008
File Category: Components

For those familiar with Ultimate Referrals...

UTR 1.3 is an upgrade to the 1.2 version of the mod with the following new features:


It is developed by Professor P as opposed to baxter_jb who developed Ultimate Referrals up to 1.1 (who was unable to continue providing support and updates).

As of version 1.3, Ultimate Referrals is a paid modification, but costs only $10 for use on a single forum.
- Full compatibility with Invision Power Board 2.3.0
- Numerous frequently requested bug fixes
- Feature to allow users to delete lines pending referral requests
- Enhancement of contests feature to allow contest to close automatically when a user reaches a specified number of referrals
- Enhancement of Administration pages


For those not familiar with Ultimate Referrals...

Ultimate Referrals in a referral system that allows users to refer their friends to the site and tracks referrals.
Features inclde:

• Ability to refer members via importing GMail contacts, manually typing in their EMail addresses or clicking a referral link. Guests who have not come to the board from a referral link (either in an EMail or the manual link) will have the option of typing in the username of the member who referred them (if applicable) on the registration page. EMails going out will also include a 'decline' link so that no more referral EMails can be sent to that address.
• Integrates with iPoints, IBProArcade, the forum's post counts and other points systems to provide reward members with points when a new member is referred by them, if a member referred by them is placed into a different user group (such as a 'premium members' group), if a member referred by them purchases a paid subscription, if a member referred by them refers more members or they then refer more members and so on (set as a percentage as the downline goes on)
• Ability to view your referrals, your downline (the referred members of members you have referred) and the points it's earned you
• Contests - allows you to create a contest to reward your members with who can refer the most new members in a given time frame, highly customizable including reccuring contests, automatically posting results when the contest ends and more

Click here to download this file

That's a good question... why don't they include it ???

Because some hosts are blocked and won't work ???

It could indicate as advanced modifications at your own risk...

Not only will it not work on some hosts, attempting to set it will result in an error.

The thing is, if we believe that IPB3 is well-written and doesn't need 128MB, then maybe asking hosts to raise the limit is a BAD idea, especially in a shared hosting environment? It increases the risk that another badly written script on another site on the same server could cripple the server and thus your site.

If the PHP group recommends 128, I'd take their word that's a suitable value for most ;)

Yes, IPB uses on an average request 7-10 - but if you upload an image thats 1000x1000px large - it's going to take some horsepower to resize that to a thumbnail, and it's not unheard of for us to get tickets from people with limits of 32 or 64 with that exact problem.

One can normally upgrade their memory_limit value with a local php.ini file, or by adding a php ini_set() call, or a htaccess file. Google will tell you how to do those.

You could also always contact your host and ask them to do it for you :)

There is a chance you might have problems with more memory-intensive operations such as uploading large files or importing a language pack.

Most of the times the issue is that hosts upgraded from PHP4 (which had a much lower default memory limit) and have just forgotten to increase the value. Normally I've found if you ask your host to bump it up to 128M they will.
Any host which lowers the limit from the default is being quite restrictive - there's a reason the default is 128 ;)

If you need to contact technical support, then yes, send in a ticket - that's what that system is for. Things would get messy if have technicians had to answer both tickets and topics here :)

To answer your question - the default PHP 5 memory limit is 128M, which should be sufficient.
Our system requirements are documented, while some people may find some settings need to be tweaked if they have a particularly large site - the default configuration should be fine for most, and that is what that page assumes you have.

What you're looking for sounds like developer documentation - which is quite different to user documentation.

For developer documentation - there's this for creating an application: http://community.invisionpower.com/topic/292645-creating-an-application-documentation/
Along with all of this: http://resources.invisionpower.com/index.php?appcomponent=cms&module=articles&category=135