bfarber

What I would do if you want more images is to leave the existing article image uploader in place, and then add an attachments field (as you've apparently tested) in addition to it. Then whatever image is uploaded via the article image single upload field represents the article, but additional images (or any other files really) can be uploaded as well, should there be a need.

Yes, with a little effort. Anything is possible, realistically, however not everything is possible with the flip of a switch or the toggle of a setting out of the box.

By default we use a single file upload field restricted to images to represent the article image. This allows for a lot of various interconnected functionality (such as showing the article image in frontpage and archive listings - something that is difficult to do when you utilize an attachments field and there could be 10 files uploaded, none of which are images). This is a basic file upload field that does not let you specify various parameters by itself.

However, you can control both positioning and size by editing the appropriate templates. For instance, to change how articles are displayed, you would edit the Article Templates -> "Article View" template. When doing so, find the code

   	 <if test="$data['record']['article_image']">
            <img src='{$data['record']['article_image']}' {parse resize_image="$data['record']['article_image']" maxwidth="225"} alt='' style="float: right; padding: 10px" />
        </if>

If you wanted the image on the left instead of the right, change the float CSS to left. Or if you wanted it above the article, get rid of the float and wrap the image in a <div> (which you could then center for instance). Or cut this code out of the template and paste below the rest of the fields to move the article image to the end. Ultimately, it is a template and you have complete control to customize it.

Similarly, here you will see a maxwidth value of 225. You could change this, or you could even embed some PHP code to proportionately resize the image if you wanted. There are many options, depending on your level of comfort with modifying the templates, coding PHP, understanding our HTML logic, etc. As I said, anything is possible.

The truth is, our site will be biased towards IP.Board because virtually everyone here is a client or user of IP.Board. If you would like an objective opinion, your best option is to pose the same question on a neutral third party site such as theadminzone.com, however if you truly want our opinion....IP.Board is your best bet.

One benefit not mentioned above that should be considered is that because we solely focus on hosting IP.Board websites (and addon applications), our servers are more finely-tuned to the needs of a package like IP.Board. On typical shared or VPS hosting, the server will be setup in sort of a standard configuration that should work for most people, but may not be optimal for a specific application, where-as our hosting is dedicated to this application, and thus is tuned routinely to best support it.

Further, our development and hosting departments work very closely together to (1) improve the software efficiency based on hosting observations, and (2) improve the server configurations based on knowledge the development department has. By working closely together, we can focus on making the best software and best hosting configuration possible.

IP.Board does not have a feature to restrict administrator logins via an IP address out of the box, however you could very easily add a .htaccess file to your /admin directory to do this.

order deny,allow
deny from all
allow from 123.45.6.7

Something along those lines. There are many guides out there to help you understand .htaccess formats.