rct2·com

I knew my blatant pandering to your fondness for Radiohead would pay off. :) :frantics:

[quote name='rct

As for my websites, I have domain names, for instance http://www.bellepierre.info.

All this is really not clear at all... I'll keep things like that, for a moment and I will contact the hosting company and ask them what I should do.

Thank you ! :)

Multi-moderation can just about achieve all you want, based on your description.

Just added that back in for 3.0.4 (locally). You're welcome.

bfarber grammar police alert: That's "well" not "good". ;)

@Telemacus2: While I have some your sympathy with your love of post icons, I doubt you're going to attract many people to your cause by claiming that it's Invision's biggest MISTAKE (your emphasis). :)

You used to be able to turn the board offline by editing conf_global.php. Perhaps that what you remember?

I thought they were missing too but they're not. They were NOT written by IPS staff, so they are not in the official documentation section, they are in the Community section.

All the community written articles are at http://community.invisionpower.com/resources/articles.html?category=28

Under the Developer Articles tabs are the hooks articles to which I think you're referring.

Huzzah!

Woohoo. [img]

[/img]

:thumbsup: Thank you

I'd like my mod to take advantage of the output class logErrorMessage and SendErrorNotification functions. They are called from output::ShowError but I need some inline error messages that I want to log and notify, and not stop execution with a big red ShowError message!

I can get at these functions by extended the output class with a subclass of my own. But is there any reason why these particular functions are not declared Public?

Out of interest, how do people go to the first post in the topic?

No need to hack it, just clicking on the icon to the left of the topic title does the trick. That way people have a choice.

Just added that back in for 3.0.4 (locally). You're welcome.

Ian, it's true that people don't use them, but the reason is they're not really post icons: they're mood icons, there are only 14 of them and they don't add any additional information to a thread.

However, if you add your own post icons (and that's the whole point, they can be very useful)

I thought when you right-clicked on the post icons that you were showing a feature that I didn't know existed. But it would appear that you have a hack installed on your board.

Personally I don't agree. Sure your nice large icons help people find posts within a forum that may interest them, but a more efficient way (IMO) of organising the topics would for them to have their own forums. e.g Apple forum, Linux forum, ... Organising like that helps visitors focus much more quickly on what they may be interested in, rather than having to find the correct post icon.

I do use post icons a lot, and will miss them. But I guess I'm not so bothered about their deprecation that I bother to make a YouTube video. :)

My 'must have' feature I want back is the link to go to the 'first unread' post in the search results screens. I don't want the last post if I cannot see the unread posts before the last one. That's their biggest mistake.

Surely there's no point in using IPB in an organisation of 1 or less? Or do people who talk to themselves a lot like to use it? :lol:

For each domain on the server yes, but for the overall server 'root' PLESK account I think it uses the server name (or IP address).

I'll add to that the PLESK Control Panel

http(s)://chosen-prefix.myhostingcompany.com:8443

They can really give it any name you like. It *might* be important to you that it has the same name as before. It's normally passed on by any mail server programs running on your server for example. If external spam filters have 'trusted' your server name, it's useful to keep it.

However, if you were on shared hosting, the server name will already exist, and you won't be able to use it again.

As you point out, if the server name included the name of the previous hosting company, neither company is going to be happy if you want to move it.

It seems to me that heated/contentious topics can often cause flaming/trolling and excessive use of positive and negative reputation. A single topic could skew reputation values for certain members.

Good moderators often close topics that are overly inhabited by flaming/trolling posts. Much better that than hide them completely. What I am thinking is that it would be good if, once a topic has been closed, that it should be no longer possible to add/subtract reputation from posts in that topic.

Similarly for topics with polls. Once closed, no more voting.

If I were a director of InVision, with the well documented turmoil going on at vbulletin, and a tranche of new versions of stuff here, plus some brand new products, some good strong user documentation would be right near the TOP of my list of things to do,to make it (as far as possible) a 'no brainer' decision to both buy the product if I didn't have a board, and to transfer over to it, if I didn't.

I say that even though I have been very public in my discontent about the lack of support in general (not just documentation) for developers. I think a user manual would be a priority.

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.

I don't fully understand threading/execution/memory handling either m4rtin. But I have seen servers DIE because Apache has too many processes loaded into memory simultaneously. While they wait their 'turn' for some CPU they sit in memory. If the amount of memory each Apache process 'reserves' is influenced by this 128MB PHP setting, then that memory will fill up faster.

As soon as all the memory is used up, the system starts 'paging', swapping out processes onto disk. Eventually, the server locks up as it spends more time paging stuff in and out of memory rather than doing any processing.

The maximum number of Apache processes that will be allowed to simultaneously occupy memory is set by the MaxClients setting in httpd.conf. If the server becomes especially busy for some reason, and each process is asking for a lot of memory, the server soon 'dies'.

When one considers that each Apache process (and there are usually many running simultaneously) has its own instance of the PHP interpreter running, 128MB per Apache process is an awful lot.

I'm managing on my test board at the moment with 32MB.