Find content
Male
Honestly, I think the banning system is one of the worst things about IPB. Moderators can't ban members and have them moved to a banned group, bans can't be set to expire and move the member back to their original group (although "suspensions" can), there are both bans and "suspensions" which just ends up making things way more confusing than they should be, and there's no obvious indication anywhere at all that a member is "suspended" which can easily lead to confusion about whether someone is banned or not.
And the warning system, I think it's useless. It should be able to give bans and restrictions based on warning points, and it should log all warnings in an obvious place.
I really think that this whole "just because vB has it doesn't mean IPB should have it" attitude is holding IPB back. Face it, vB does some things a lot better than IPB does, yet there seems to be this resistance to changing some features to be better just because it happens to be like how vB does it.
#2000885 Close to Moving Back to Vbulletin
Posted
on 05 August 2010 - 04:21 PM
#1993962 Undecided: IPB or vB
Posted
on 26 July 2010 - 02:27 PM
Switching forum software is a big commitment in terms of cost and effort. You're wise to do your research and consider it fully. Most of your members probably couldn't care-less what software you're running.
However, you have to have faith and trust in any software you upload to your web server. You have to have faith that it will work as advertised and be satisfactory to your community and you have to trust the company behind it to ensure it has the very best security and that they're responsible when it comes to future updates. You enter a relationship with a software vendor and like any good relationship, you can have some ups and downs as long as you believe that it's worth the time and effort.
No software is perfect, we certainly don't claim that. What we do stand by is our core principals to be honest, open and give a fair deal. This is our livelihood and how we pay our bills. We put our heart and soul into our software not because we want to be proud of it, but because we want *you* to be proud of it.
We all love what we do, and I think that shines through our work and puts a little magic into our software.
So really, the only question you have to answer is "Do you see a future with us, or with your current vendor?".
However, you have to have faith and trust in any software you upload to your web server. You have to have faith that it will work as advertised and be satisfactory to your community and you have to trust the company behind it to ensure it has the very best security and that they're responsible when it comes to future updates. You enter a relationship with a software vendor and like any good relationship, you can have some ups and downs as long as you believe that it's worth the time and effort.
No software is perfect, we certainly don't claim that. What we do stand by is our core principals to be honest, open and give a fair deal. This is our livelihood and how we pay our bills. We put our heart and soul into our software not because we want to be proud of it, but because we want *you* to be proud of it.
We all love what we do, and I think that shines through our work and puts a little magic into our software.
So really, the only question you have to answer is "Do you see a future with us, or with your current vendor?".
#1990951 Suggestion: Pagination tutorial for custom databases
Posted
on 21 July 2010 - 09:25 AM
I'm sorry - re-reading my reply it is rather confusing huh.
The link I gave was merely meant to illustrate that pagination is built in already.
i.e. at this page http://community.inv...rd-3x/skinning/ you see this
Now, the "Media Demo" database is nothing more than a standard database in IP.Content, but using customized templates (the idea being, to give people an idea of some of the ways they can customize their templates so that they don't look identical to everyone else's). So, going back to the original post
1) No tutorial is needed because in DEFAULT database templates, pagination is already there.
2) With a little usage of the tools available, it's quite easy to add actually. I've made a short video showing how to do it exactly.
http://www.screencas...45-9431b32044b7
The link I gave was merely meant to illustrate that pagination is built in already.
i.e. at this page http://community.inv...rd-3x/skinning/ you see this
Now, the "Media Demo" database is nothing more than a standard database in IP.Content, but using customized templates (the idea being, to give people an idea of some of the ways they can customize their templates so that they don't look identical to everyone else's). So, going back to the original post
1) No tutorial is needed because in DEFAULT database templates, pagination is already there.
2) With a little usage of the tools available, it's quite easy to add actually. I've made a short video showing how to do it exactly.
http://www.screencas...45-9431b32044b7
#1984826 Skinning system improvements
Posted
on 09 July 2010 - 05:54 PM
Hello,
IPB has a great skinning system. However, as time goes by, our skins at Skinbox become more and more complex and we feel limited on some points. I may have other suggestions in a very near future but here are a few ones.
1. I18n
Some of our skins include some additional text which is hard-coded because we have no choice. What I would like is the ability to embed a language pack in the skin set file which would be automatically installed. This would make our lives easier when dealing with non-English-speaking clients: no need for the clients to spend a lot of time to go through all of our templates or no need for us to find a workaround (such as having a javascript file as a language file...).
2. Hooks
Some advanced functionality may require hooks in order to work, even if they are still presentation-related: for example, we have a background picker on some skins. It would be great for us to use a little php to help users to set up their desired backgrounds. However, the users which would need that kind of help will mess if they have ten things to install... That's why it would be cool to be able to embed hooks as well.
3. Apps
In the same way, I would like to be able to embed a full IPB app in the skin set itself in order to provide users with a configuration interface. I know we may use settings to do this, but I think an IPB app would be more flexible. It could be a special app, accessible through the dropdown in the skin list. This would lead to wordpress-like theme admin. I would love to be able to do that.
In fact, what I would like is a new way to import skins. Like a "Import skin installer package" thing. And this installer package could embed any IPB element: hook, app, skin, setting, etc.
4. Remote install
Finally, I would also love to have a remote install thing. It could be the exact same process as now, but instead of clicking browse to select the skin zip, the user would just type the skin install url. This url would leave ALL size limits for exported skins. In fact, these size limits - which are due to php - make the install process of our skins harder again... For some skins, we cannot give the user the imageset and the skinset only, we need to add a third file with the backgrounds inside. So the user has to put the backgrounds in the right directory himself.
Thanks in advance for reviewing my suggestions, I hope you will be able to include at least some of them in the future
S. Penet.
IPB has a great skinning system. However, as time goes by, our skins at Skinbox become more and more complex and we feel limited on some points. I may have other suggestions in a very near future but here are a few ones.
1. I18n
Some of our skins include some additional text which is hard-coded because we have no choice. What I would like is the ability to embed a language pack in the skin set file which would be automatically installed. This would make our lives easier when dealing with non-English-speaking clients: no need for the clients to spend a lot of time to go through all of our templates or no need for us to find a workaround (such as having a javascript file as a language file...).
2. Hooks
Some advanced functionality may require hooks in order to work, even if they are still presentation-related: for example, we have a background picker on some skins. It would be great for us to use a little php to help users to set up their desired backgrounds. However, the users which would need that kind of help will mess if they have ten things to install... That's why it would be cool to be able to embed hooks as well.
3. Apps
In the same way, I would like to be able to embed a full IPB app in the skin set itself in order to provide users with a configuration interface. I know we may use settings to do this, but I think an IPB app would be more flexible. It could be a special app, accessible through the dropdown in the skin list. This would lead to wordpress-like theme admin. I would love to be able to do that.
In fact, what I would like is a new way to import skins. Like a "Import skin installer package" thing. And this installer package could embed any IPB element: hook, app, skin, setting, etc.
4. Remote install
Finally, I would also love to have a remote install thing. It could be the exact same process as now, but instead of clicking browse to select the skin zip, the user would just type the skin install url. This url would leave ALL size limits for exported skins. In fact, these size limits - which are due to php - make the install process of our skins harder again... For some skins, we cannot give the user the imageset and the skinset only, we need to add a third file with the backgrounds inside. So the user has to put the backgrounds in the right directory himself.
Thanks in advance for reviewing my suggestions, I hope you will be able to include at least some of them in the future
S. Penet.
#1932129 New Powered By in 3.1
Posted
on 25 March 2010 - 05:34 PM
I really don't see why people get hyped over the copyright on something. In fact... why even look at it?! 
Still, Matt has said you can change it back yourself if you want to, so I'm not seeing an issue anyway.
Still, Matt has said you can change it back yourself if you want to, so I'm not seeing an issue anyway.
#1932036 Switch from Rich Text to Regular Editor
Posted
on 25 March 2010 - 02:29 PM
Can we please have the option to switch from rich text to the regular editor directly on the post screen again? Sometimes the Rich Text editor screws up the post code, and you wish to edit the bbc manually. (For example I have had instances where I unbolded in the richtext editor, and it wouldn't actually unbold when you submit it.)
#1928666 jQuery vs. Scriptaculous
Posted
on 19 March 2010 - 10:39 AM
I understand where you're coming from, a lot of developers have mentioned jquery to us and we do see the advantages. Unfortunately, we have to weight the development time that would cost against the features we could have added using that same development time. For the moment, we feel that most of our customers would rather we spent time on adding/polishing features, rather than recreating a lot of JS code. That's not to say we'll never move to jquery, only that it won't happen in the near future.
#1925049 Templates in_dev mode
Posted
on 12 March 2010 - 05:22 PM
The Geek, on 12 March 2010 - 11:30 AM, said:
Still fairly confused, but getting there thanks to you guys. I appreciate your help.
Any new system requires a learning curve (it's inevitable), but given your existing knowledge, I'm confident you will come to love how powerful the skin system truly is once you learn it.
You can create new parse tags just by dropping in php plugin files, you can execute raw php right in the templates, you can do a lot once you learn how the system works. And it sounds like you're just about there to be honest.
As Josh pointed out, PHP is *always* executed at the beginning of a php template. One common "gotcha" I run into (or see others run into) is doing something like this
<php>$variable = "a";</php>
<foreach loop="$test as $_test">
{$_test}: {$variable}
</foreach>
This won't work as you expect, and the reason is that foreach loops actually compile into separate functions, so the variable isn't in scope. Easy work around is
<php>$this->variable = "a";</php>
<foreach loop="$test as $_test">
{$_test}: {$this->variable}
</foreach>
(Assign as a class property so you can access from a separate function). Just throwing this at you now, cuz I expect you'd run into it yourself in short order.
#1924867 Templates in_dev mode
Posted
on 12 March 2010 - 11:12 AM
You should use
EDIT: Parse Tags are particularly useful for this sort of stuff.
The <php> Template Logic tags should really only be used if you are doing more in depth php manipulations...
&fk={parse expression="md5(IPS_UNIX_TIME_NOW);"}
EDIT: Parse Tags are particularly useful for this sort of stuff.
The <php> Template Logic tags should really only be used if you are doing more in depth php manipulations...
#1924806 Templates in_dev mode
Posted
on 12 March 2010 - 09:15 AM
bfarber, on 12 March 2010 - 09:01 AM, said:
I'm 99% sure the template engine parser requires the comment to be there for the function. Parsing the skin file is tricky business. Try changing
to
As I said, I'm pretty sure the skin file MUST be formatted exactly as you see it formatted for the other skin files (//--starthtml--// and //--endhtml--// comments for instance).
<?php
class skin_global_1 extends output {
function hiThere() {
return "<!-- YO MAMA -->";
}
}?>
to
<?php
class skin_global_1 extends output {
//===========================================================================
// <ips:entry_email_form:desc::trigger:>
//===========================================================================
function hiThere() {
$IPBHTML = "";
//--starthtml--//
$IPBHTML .= <<<EOF
<!-- YO MAMA -->
EOF;
//--endhtml--//
return $IPBHTML;
}
}
?>
As I said, I'm pretty sure the skin file MUST be formatted exactly as you see it formatted for the other skin files (//--starthtml--// and //--endhtml--// comments for instance).
Looking through the classTemplateEngine (line 317) you do need the $IPBHTML, however it doesn't *need* the comment from what I can see:
//=========================================================================== // <ips:entry_email_form:desc::trigger:> //===========================================================================instead it detects on the
function hiThere() {
line.
#1924770 Just Wanna Say....
Posted
on 12 March 2010 - 08:22 AM
Just wanted to drop in some feedback on Invision Power Board!
Its Brilliant and I think that your software is the best out there!
Thanks for making and dreaming up IPS!
Its Brilliant and I think that your software is the best out there!
Thanks for making and dreaming up IPS!
#1921330 Well, am I beating a dead horse?
Posted
on 05 March 2010 - 06:26 AM
Search is being dramatically overhauled. I'll be blogging about this later this week.
#1913957 For Rikki... Skinning Suggestions
Posted
on 15 February 2010 - 08:47 PM
This follows on from the discussion in the Customer Lounge regarding skins.. specifically my objection to there being no backgrounds and or borders on a lot of CONTENT areas of the board.
Dearest Darling Rikki....
It would appear that there are a large number of areas of Content blocks within the Default skin (upon which all skins are based) that do not have backgrounds specified.. they are relying on the body background, which is not best practice imho...If you could see your way clear to changing this, I am sure the community of skinners, and individuals trying to skin would be hugely grateful
Here is a visual example for you....
1. New Blogs screen in the IPB Default skin.
2. New Blogs screen with the base IPB default skin, but just a different darker body background - as you can see the lack of a background behind the content areas is significant when you start making any changes.. there are a lot of areas of the board like this too.
3.... You might say "well just add a background colour and a border to that div wrapper"... in this case #main_column, however that just gives one an ugly box of colour, without any ability to style it without changing the functionality of that div. (and god forbid if it is a class used elsewhere as well) It also breaks in Firefox in this case... so then you have to fiddle around adjusting margins/padding... and hope and pray to various Greater Entities.. that it works in all browsers, and doesn't create 10 other problems in other areas.
To work around this I have included my own wrapper class in all those areas of the board thus affected (and there are a number).. however that has led to a huge workload whenever upgrades roll around, as then every template I have edited to add this wrapper has to be manually upgraded, in every skin. Additionally the blogs no longer supports this (that I can find..) I spent days trying to get it to work before giving up.. but not before much screaming and pulling my hair out and generally turning the air blue around me in the process.
4. This is something like I (and my customers) would WANT it to look like... far more styled and in keeping with the rest of the skin.. only problem is this is proving to be almost impossible to achieve (in the blogs anyway). The other areas throughout the board the look can be achieved, but only with a lot of work.
imho... having easily adjustable and editable backgrounds to content areas is a must - I think it is pretty fundamental to have a background behind content areas, not rely on the body background. Same with borders to content areas... I haven't checked lately because I have been using my wrapper everywhere instead.. but last time I tried it you couldn't add a border attribute to the main content areas because of the border-collapse: collapse - has this changed? If not.. could it... you should be able to add a border to content areas without drama.
To close dearest Rikki, I know I am not the world's greatest coder, and perhaps I have missed some blatantly obvious way of achieving my aims without all this rigmorole... (Highly likely - But if so you got to ask how total noobs are feeling!!!) and I also know that many of the youngie skinners and grooovsters don't feel borders or footers etc to be totally cool and web2ish etc etc.. but most of us grown ups quite like those things... as my customer base and queue for custom skins says.......and rully trullly it would be most excellent to not have to cry everytime IPS releases a new update because of all the useless non productive, non creative work it creates.
Edit to add other areas...
Profile
User Control Panel - all pages
Sign In
Dearest Darling Rikki....
It would appear that there are a large number of areas of Content blocks within the Default skin (upon which all skins are based) that do not have backgrounds specified.. they are relying on the body background, which is not best practice imho...If you could see your way clear to changing this, I am sure the community of skinners, and individuals trying to skin would be hugely grateful
Here is a visual example for you....
1. New Blogs screen in the IPB Default skin.
2. New Blogs screen with the base IPB default skin, but just a different darker body background - as you can see the lack of a background behind the content areas is significant when you start making any changes.. there are a lot of areas of the board like this too.
3.... You might say "well just add a background colour and a border to that div wrapper"... in this case #main_column, however that just gives one an ugly box of colour, without any ability to style it without changing the functionality of that div. (and god forbid if it is a class used elsewhere as well) It also breaks in Firefox in this case... so then you have to fiddle around adjusting margins/padding... and hope and pray to various Greater Entities.. that it works in all browsers, and doesn't create 10 other problems in other areas.
To work around this I have included my own wrapper class in all those areas of the board thus affected (and there are a number).. however that has led to a huge workload whenever upgrades roll around, as then every template I have edited to add this wrapper has to be manually upgraded, in every skin. Additionally the blogs no longer supports this (that I can find..) I spent days trying to get it to work before giving up.. but not before much screaming and pulling my hair out and generally turning the air blue around me in the process.
4. This is something like I (and my customers) would WANT it to look like... far more styled and in keeping with the rest of the skin.. only problem is this is proving to be almost impossible to achieve (in the blogs anyway). The other areas throughout the board the look can be achieved, but only with a lot of work.
imho... having easily adjustable and editable backgrounds to content areas is a must - I think it is pretty fundamental to have a background behind content areas, not rely on the body background. Same with borders to content areas... I haven't checked lately because I have been using my wrapper everywhere instead.. but last time I tried it you couldn't add a border attribute to the main content areas because of the border-collapse: collapse - has this changed? If not.. could it... you should be able to add a border to content areas without drama.
To close dearest Rikki, I know I am not the world's greatest coder, and perhaps I have missed some blatantly obvious way of achieving my aims without all this rigmorole... (Highly likely - But if so you got to ask how total noobs are feeling!!!) and I also know that many of the youngie skinners and grooovsters don't feel borders or footers etc to be totally cool and web2ish etc etc.. but most of us grown ups quite like those things... as my customer base and queue for custom skins says.......and rully trullly it would be most excellent to not have to cry everytime IPS releases a new update because of all the useless non productive, non creative work it creates.
Edit to add other areas...
Profile
User Control Panel - all pages
Sign In
#1911855 My personal praise for IPB
Posted
on 10 February 2010 - 03:38 PM
I don't often post feedback, but I feel I owe it to the staff at Invision Power to let you know what a great product range you have. I have IP.Board, Blog, Gallery, Content, Downloads and they are all remarkable products. I also congratulate you on your general attitude, which is polite and professional, and also on the amount of updates you lot churn out. IP.Board 3.1 looks set to be a great update, as does IP.Content 2.
The only one suggestion I have, is that you please improve the navigation bar. Sub Menus would be great, as would improved re-ordering. I'm sure others would agree with that. Other than that, you have supplied us with a perfect product.
Keep it up, and well done.
The only one suggestion I have, is that you please improve the navigation bar. Sub Menus would be great, as would improved re-ordering. I'm sure others would agree with that. Other than that, you have supplied us with a perfect product.
Keep it up, and well done.
#1908478 Suggestions after 2.0 Dev update
Posted
on 03 February 2010 - 07:16 AM
Copied from the support forum -
Read the blog update last night, looking forward to what 2.0 has in store! I'm slightly worried about developing stuff on 1.2 though in the mean time...
Anyway, that aside, what I'd like to see in 2.0
- Navigation links in board header per database - at the very least it should stop people making new topics about how to do it! But it would be handy to have the functionality integrated with CCS. I think I remember that some stuff in IPB would need to be refactored to make this possible, so hopefully its a consideration for the next version of IPB.
- Search result tabs per database - hopefully self explanatory. At the moment I believe all results are listed on the 'Pages' tab. The improvements to the search in ipb3 could the most underrated improvement, it'd be great to see it even better.
- Profile tabs per database - listing basic database submissions by the user, extendable/skinnable by us lot. Pretty sure at the moment that individual files drive these tabs, so I guess this would be a lot of work to implement, but it'd be nice to see. This would maybe need a new template type 'profile database listing' or something.
Edit: just creating some DB hooks - bloody brilliant they are too. Could we get a postSave hook? I need to access the filename of an attachment after it's been attached (so I can convert the file to FLV after upload).
Read the blog update last night, looking forward to what 2.0 has in store! I'm slightly worried about developing stuff on 1.2 though in the mean time...
Anyway, that aside, what I'd like to see in 2.0
- Navigation links in board header per database - at the very least it should stop people making new topics about how to do it! But it would be handy to have the functionality integrated with CCS. I think I remember that some stuff in IPB would need to be refactored to make this possible, so hopefully its a consideration for the next version of IPB.
- Search result tabs per database - hopefully self explanatory. At the moment I believe all results are listed on the 'Pages' tab. The improvements to the search in ipb3 could the most underrated improvement, it'd be great to see it even better.
- Profile tabs per database - listing basic database submissions by the user, extendable/skinnable by us lot. Pretty sure at the moment that individual files drive these tabs, so I guess this would be a lot of work to implement, but it'd be nice to see. This would maybe need a new template type 'profile database listing' or something.
Edit: just creating some DB hooks - bloody brilliant they are too. Could we get a postSave hook? I need to access the filename of an attachment after it's been attached (so I can convert the file to FLV after upload).
