rct2·com

And that's a very good point. People wishing to cross grade for a significant discount over existing loyal InVision customers seem to be forgetting in their arguments that they will still own a vB licenses for the current version of vB. Although they may not intend to use it as their main board, it does still have a residual value which could be realised by selling it on.

Indeed. :) As I said before, I don't think the OP's idea will work because there are too many clients to think about for a client executable to be feasible. But a few differnt distributions, that were a bit more server side savvy would be good IMO, and more feasible.

Sure, I didn't want to suggest that a tarball should be the ONLY distribution of the code. (A gzipped tarball would be better ;) ) But it would be nice if there were some extra ways that the code could be provided as a download, for those of us who are not :lol: instead of just supplying to the lowest common denominator. It's not uncommon for suppliers of scripts to provide more than one distribution version, each version being friendly to the target server operating system.

Actually from the IP.Board download it's everything in the upload folder you need, not just the admin folder. So slightly more 'science' needed. :lol: It could be simpler. Almost 2300 files in IP.Board to upload is a nuisance, especially (if like me) you have a FileZilla/proftpd interoperability problem at the moment so that the client randomly gets timeouts and disconnects.

That sounds complex, to have something running client side that then has to upload things to the server. For a start, there would need to be Windows, Mac and Lnux clients for example. But I thing there are improvements that could be made in this area. For example, providing the uploads as tarballs with all the folders and files having the correct permisions would be great. That way instead of download (from InVision), unzip, upload, change permissions we could just download (from InVision), upload, unzip. Another improvement could be that if we do have to unzip on our PCs, there are fewer files to upload, and the installer then decompresses/xml parses them on the server.

Indeed they do. They tell you who deleted it, and where they deleted if from (topic and forum).

+1 I've been asking for this since before v2. :(

You would need to rerun the upgrade script to restructure and rebuild the 2.3.6 database tables and make them compatible with v3.

What he asked was 'where can I find the IPB license agreement?' I leave the interpretation to him. ;) If indeed, it is a 'him'.

http://community.invisionpower.com/index.php?app=core&module=attach&section=attach&attach_id=20421 :)

OK well now the server admin has set it up so you can FTP onto the site, it's probably easiest to use the FTP client to change permissions, rather than having to learn Linux command line. :)

From your /home folder it will CHMOD EVERYTHING under /home/yforums to 777. Not a great idea if you're worrying about security, which is where this topic began.

So the first 5 commands move him to the /home folder And the next one RECURSIVELY changes the ownership of everything from /home/yforums downwards to owner yforums, group yforums Then the next one RECURSIVELY changes permissions to 755 from /home/yforums downwards If public_html needs to be 755 in a WHM/CPanel environment, then I guess it does. In my PLESK environment httpdocs is 750 and it works fine.

I have no explanation for that. My httpdocs folder (same as public_html) is 750.

There is no reason that you should not set up public_html as 750. Its the folders and the files underneath public_html where you need the last number to be at least '4'.

Most mail servers systems have code in them to cope with failed delivery. Messages may be rejected for various reasons, and the mail server requeues them to try again later. Each time it queues them for a resend, it puts a longer delay before the next send. Therefore with a bulk mailing, the requeue can grow quite large, quite quickly. I suspect that it what your message is about. After a certain number of resends (which is normally configurable), the mail server then usually sends an 'undeliverable' message to the original sender. If the 'reject' reason is something like 'unknown recipient', then the message doesn't get requeued and you get an immediate failure message like the one you describe. If I were you, I'd get ready for a flurry of 'failed delivery' messages in your forum email inbox in the next few days.

Indeed, but add to that the fact that AdminCP colour codes all the skin bits that you have changed in a custom skin, and the 2 together make it possible to quickly focus in on the areas that need looking at in your custom skins.

Doesn't look right. Icon Watched Content 1. Forums 2. Topics * Company News and Updates * How to give page has expired warning? by bfarber Icon Mar 29 2009 08:11 PM * PHP Project Management Software by Brett B Icon Mar 19 2009 09:06 PM * Disabling post reputation voting in certain forums by TrekkiemonsterUK Icon Sep 13 2009 06:22 PM * Amazon have just lost a loyal customer by Evanescense Icon Jul 20 2009 05:59 AM * Computer - PC Issue by tenchin Icon Jul 15 2009 02:18 AM * Links System 3.1.x Support by .Ian Icon Yesterday, 04:09 PM * Web host now blaming by forums for slow performance by The Old Man Icon Jun 25 2009 08:39 PM * Breaking a database into pieces by aeharding Icon Jul 28 2009 02:38 AM * Show your car! by Tom_F Icon Sep 21 2009 08:19 AM I aomatically subscribe to all topics (no email notification) to which I post.

*BUMP* This change to the Watched Content hook still does not appear to have been implemented here at invisionpower.

You guys have made it far too easy for people to make mods. Now anybody with low skills can produce something. You should be ashamed of yourselves. I'm joking of course. :)

@ibotPeaches: Whether something is faster or slower is surely a 'perception' rather than a firm statement? Unless you have a 'lab' type server that runs exactly the same transactions on the same database with a known load on the server both times, it's not really possible to accurately judge whether one version is faster than another. Although it is nice to get confirmation that there has been some optimisation.

I think that it is dangerous to assume that because a domain is hacked, then the 'back door' must be through the IP.Board. Sure ibskin/forums etc is posting about a hack, but it doesn't necessarily mean the attack came through the forums. For example, a few months back one of the boards I help with started serving up a Trojan virus. An <iframe> had been placed in the skins which were downloading the Trojans through vistors' browsers. Immediately, we all got worried about the security of IP.Board (v2.3.6 as it happens). However, after extensive forensic evidence gathering I discovered that the backdoor was on a completely different script on a completely different domain that was run by somebody else on our server. This forum software creates and updates a lot of files. These files belong to the web server user called 'Apache'. Every script on the server belongs to the same user 'Apache'. So when people find a backdoor where they can upload a hacking script, that script is owned and runs as user 'Apache'. Therefore every file created by a web server script is vulnerable to being attacked. whether it is in the domain being attacked, or otherwise. This vulnerability is true of ANY web-based scripting engine, and not just IP.Board. You have to rely on the developers of the scripts being as diligent as possible in preventing 'hacks' by injecting nasty commands through their URLS. I have confidence that the folks at InVision have that diligence. What is more, even modders of Ip.Board can be reassured that any URLS that they serve up will have the input thoroughly cleaned before it is passed to their code.

And that's into files yes? Are there any articles about it? From what I remember when I looked, if I switch it on, there will be messages in the logs from all over the code?

I've been exploring the ShowError routine and error logging. I've read http://community.invisionpower.com/resources/official.html?record=128 . Matt has also promised that the next release of IP.Board will make some of the logging functions public instead of protected. Would it be possible to handle a new level of error reporting, the '0' level for 'information only'. This level is not an error, it's a log of activity. It would be far preferable to have this capability, rather than having to write my own activity logging, and would be a useful facility for all modders I think. I've suggested a '0' level to make it easier to implement (I think), '1' upwards are alreay defined.

Quite hard to implement I would have thought. For example the board won't run if MySQL dies so how can the board send a message to say that it is 'dead' if the code to send emails needs to get the email address from the database? On top of that, many of the mail server software systems (postfix, qmail, sendmail) often need MySQL themselves. It is possible to specify in AdminCP what level of errors should cause emails to be sent and logs to be kept. That is a possibility: for thrid-party add-ons like hooks to be written well so that they add messages to logs when they cannot run properly. But anything to say the board as a whole has died would need to have be implemented outside of the board, and therefore cannot really be part of the product itself.