Michael

In IP.Board 2.x, on the page where we manage our skin templates, you could easily tell which skin group had one or more modified skin templates in it as the little icon beside it would be red. This functionality was removed in 3.x. I found this to be helpful for a number of reasons, and would like to see it return.

First, if an upgrade to the forum software modifies some skin templates, the upgrade script won't touch your modified skin template groups, and you'll have to patch those manually. When we look at a difference report, we used to be able to quickly see whether or not any of the templates changed in this new version needed this manual patching; if you could see that only 3 of your skin's template groups had been modified it made the job of patching a whole lot quicker. Secondly, it can be kind of an annoyance on a development board where you do things like test out code snippets. Again, when you upgrade that board, any modified templates you had won't get updated, so you may run into issues where you just fiddled with a bit of code, forgot to revert it, and now you have some code for the page that is out of whack.

In IP.Board 2.x, on the page where we manage our skin templates, you could easily tell which skin group had one or more modified skin templates in it as the little icon beside it would be red. This functionality was removed in 3.x. I found this to be helpful for a number of reasons, and would like to see it return.

First, if an upgrade to the forum software modifies some skin templates, the upgrade script won't touch your modified skin template groups, and you'll have to patch those manually. When we look at a difference report, we used to be able to quickly see whether or not any of the templates changed in this new version needed this manual patching; if you could see that only 3 of your skin's template groups had been modified it made the job of patching a whole lot quicker. Secondly, it can be kind of an annoyance on a development board where you do things like test out code snippets. Again, when you upgrade that board, any modified templates you had won't get updated, so you may run into issues where you just fiddled with a bit of code, forgot to revert it, and now you have some code for the page that is out of whack.

The problem is we don't want to reveal too much about how the system works or spammers could just find a way to trick it...

Yeah, it's exactly like that. :rolleyes:

In IP.Board 2.x, on the page where we manage our skin templates, you could easily tell which skin group had one or more modified skin templates in it as the little icon beside it would be red. This functionality was removed in 3.x. I found this to be helpful for a number of reasons, and would like to see it return.

First, if an upgrade to the forum software modifies some skin templates, the upgrade script won't touch your modified skin template groups, and you'll have to patch those manually. When we look at a difference report, we used to be able to quickly see whether or not any of the templates changed in this new version needed this manual patching; if you could see that only 3 of your skin's template groups had been modified it made the job of patching a whole lot quicker. Secondly, it can be kind of an annoyance on a development board where you do things like test out code snippets. Again, when you upgrade that board, any modified templates you had won't get updated, so you may run into issues where you just fiddled with a bit of code, forgot to revert it, and now you have some code for the page that is out of whack.

In IP.Board 2.x, on the page where we manage our skin templates, you could easily tell which skin group had one or more modified skin templates in it as the little icon beside it would be red. This functionality was removed in 3.x. I found this to be helpful for a number of reasons, and would like to see it return.

First, if an upgrade to the forum software modifies some skin templates, the upgrade script won't touch your modified skin template groups, and you'll have to patch those manually. When we look at a difference report, we used to be able to quickly see whether or not any of the templates changed in this new version needed this manual patching; if you could see that only 3 of your skin's template groups had been modified it made the job of patching a whole lot quicker. Secondly, it can be kind of an annoyance on a development board where you do things like test out code snippets. Again, when you upgrade that board, any modified templates you had won't get updated, so you may run into issues where you just fiddled with a bit of code, forgot to revert it, and now you have some code for the page that is out of whack.

In IP.Board 2.x, on the page where we manage our skin templates, you could easily tell which skin group had one or more modified skin templates in it as the little icon beside it would be red. This functionality was removed in 3.x. I found this to be helpful for a number of reasons, and would like to see it return.

First, if an upgrade to the forum software modifies some skin templates, the upgrade script won't touch your modified skin template groups, and you'll have to patch those manually. When we look at a difference report, we used to be able to quickly see whether or not any of the templates changed in this new version needed this manual patching; if you could see that only 3 of your skin's template groups had been modified it made the job of patching a whole lot quicker. Secondly, it can be kind of an annoyance on a development board where you do things like test out code snippets. Again, when you upgrade that board, any modified templates you had won't get updated, so you may run into issues where you just fiddled with a bit of code, forgot to revert it, and now you have some code for the page that is out of whack.

I think, personally, that this shouldn't be a site-wide setting that changes the behavior for all members, but rather it should be something individual members set as a preference in their My Settings pages. Clearly as we can see from this topic, we have some folks who really like external links opening in a new window, and some who always want to control whether or not this happens. As it is on this site, the powers that be decided that they would leave this setting to No, and so that means that all of us members here have to live with that.

Hi
Just to let you know, that URL filtering should also apply to signatures.

Not everyone would like to have porn or competitors links on their site.

Yeah, it's exactly like that. :rolleyes:

Since it often happens that a new version gets released, some bugs slip through the testing process and a new build of that version needs to be uploaded to our client centers, I think it would be very helpful if the Your Downloads page where we download our copies of the software showed the date (or some other such indicator) of when this particular version was last uploaded. Maybe a build number there would be a good idea instead?

I'm just thinking of all of the topics we get where folks talk about bugs they have that have already been fixed, but they might not necessarily have known the version was rebuilt.

Since it often happens that a new version gets released, some bugs slip through the testing process and a new build of that version needs to be uploaded to our client centers, I think it would be very helpful if the Your Downloads page where we download our copies of the software showed the date (or some other such indicator) of when this particular version was last uploaded. Maybe a build number there would be a good idea instead?

I'm just thinking of all of the topics we get where folks talk about bugs they have that have already been fixed, but they might not necessarily have known the version was rebuilt.

Download and import this file into your settings area.

The you can go to Settings > Forums > Topics, Posts and Polls
And under "Making a Post", you'll find "Disable URL truncating?". Enjoy!
settingGroup_topics-posts-and-polls.xml

Please see
http://forums.invisionpower.com/topic/287067-link-wraping/page__pid__1840069__st__0

As the internet slowly moves to longer URLs, with better descriptions of the content, truncating the link's text should be an option in ACP (either enable/disable, or enable and x amount of characters, with your default of ~35 characters). It's easier to see what content your link is going to if it's longer than the truncating number, especially if it's all from a domain with a long name, and multiple links from the same website's directory within the same post.

Since it often happens that a new version gets released, some bugs slip through the testing process and a new build of that version needs to be uploaded to our client centers, I think it would be very helpful if the Your Downloads page where we download our copies of the software showed the date (or some other such indicator) of when this particular version was last uploaded. Maybe a build number there would be a good idea instead?

I'm just thinking of all of the topics we get where folks talk about bugs they have that have already been fixed, but they might not necessarily have known the version was rebuilt.

Since it often happens that a new version gets released, some bugs slip through the testing process and a new build of that version needs to be uploaded to our client centers, I think it would be very helpful if the Your Downloads page where we download our copies of the software showed the date (or some other such indicator) of when this particular version was last uploaded. Maybe a build number there would be a good idea instead?

I'm just thinking of all of the topics we get where folks talk about bugs they have that have already been fixed, but they might not necessarily have known the version was rebuilt.

Got it straightened out with Charles, thanks :)

I don't see it there anywhere. :unsure:

The announcement mentioned this:



I don't see where in my Client Center this is located, is it just not ready yet?

Bump to bring this back up for discussion, this is currently the big stumbling block preventing some really awesome uses of the Hooks system. :)

Please see http://forums.invisionpower.com/topic/288523-hook/

Can it be made possible for the hook to access data that is being processed where the hook is placed ?

In previous versions, it was possible to click a link in the permission masks page to preview that permission mask. It seems that this has been removed in 3.0? I found it pretty helpful when creating a new group to be able to verify this was set correctly. In fact, I think it should be something you should get to from the groups page. Let me explain.

The way I set up my masks is by having the default 'members' mask give access to the standard forums, and is in use by the Members group. Additional groups I create also use this mask, as well as their own unique mask which just gives them those additional forum(s) that group gets access to. It would be nice if I could preview a group's overall permissions considering all of their masks. The only way I could test an issue I had with this recently was by creating a test account, I shouldn't need to do that to check this.

I don't like cleancut :(

neowin forum skin is great!

Can a sticky not be put in this forum? Every weekend people post this topic and it's clearly a stumbling block that many of your newest customers are unaware of (or not understanding in their excitement once they've bought the software). :)

Well, I suppose we COULD have held up the IPB 3.0 release for the relatively small minority of customers who use subscription manager. However, I think the majority of our customers are glad that 3.0 has been released, minus a feature that is being released separately.

Subscription manager is nearly done. MSSQL is in development. We simply decided to concentrate on the functionality that the majority of our customers need, and hold up ever so slightly the functionality that only a minority of the customers use (but takes a while to develop).

We can't really say anything else about it at this point, nor am I sure what you would like to be said. It's in development. It's almost done. The past is done with, and we can't go back in time to hold things up to include the subscription manager.