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

pain in the ass Windows users

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

Will this one do ? chmod 777 -R yforums

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.

This is why we publish a skin diff so you know exactly what we changed and you can see if it impacts you or not.

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.

We are making a list of mods with known issues and we will definitely be contacting mod authors to see if they can optimize the mods.

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

There is separate debug logging if that's what you need.

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.