Jump to content
bbh_blocked_dnftl
Tiberium Technology® Forums

Welcome to Tiberium Technology® Forums

Welcome to Tiberium Technology® Forums, like most online communities you must register to view or post in our community, but don't worry this is a simple free process that requires minimal information for you to signup. Be apart of Tiberium Technology® Forums by signing in or creating an account.
  • Start new topics and reply to others
  • Subscribe to topics and forums to get email updates
  • Get your own profile page and make new friends
  • Send personal messages to other members.

[R]NuclearGeneral

[R]Root Admin
  • Posts

    5184
  • Joined

  • Last visited

  • Days Won

    5

Everything posted by NuclearGeneral

  1. IP.Board 3.4.5 IP.Blog 2.6.3 IP.Calendar 3.3.4 IP.Content 2.3.6 IP.Downloads 2.5.4 IP.Gallery 5.0.5 IP.Nexus 1.5.8 Installation instructions. Included: PSD Logo Blank PNG Logo Blank PSD Team icon PNG Team icon View the full article at IPS Resources
  2. In 3.x, we support HTML emails being sent by the software. However, due to constraints we had at the time, HTML emails use pretty much the same content as plain text emails, but wrapped in a simple HTML wrapper. Additionally, users had to explicitly decide whether they wanted to receive HTML or plain text emails via a preference setting - quite an anachronism. All in all, not a very satisfactory user experience. Email handling in 4.0 In 4.0, users no longer choose which type of email to receive. Our email handler sends both types in a single email, and the email client chooses the most appropriate to show based on its capabilities. If it can display a fancy HTML version, that's what they'll see by default, but plain text is used if not. Email template system In 3.x, email content is defined by the language system, and each email has one language string which forms the content for both the plain text and HTML versions. Clearly, if we were going to improve the HTML templates we ship with, this would have to change. In 4.x, each type of email has two templates - one for HTML, one for plain text. This means a better display of content can be created for HTML emails, while keeping the plain text ones simple and to the point. Email templates make use of the skinning system foundation (which we'll reveal later), meaning they have full use of logic, template tags and more - so we can also customize the emails depending on the user they are being sent to (note though that email templates are not per-skin; they are global to the site). And, of course, email templates can be added and edited via an interface in the AdminCP. This isn't groundbreaking stuff, but a vast improvement on email handling in 3.x. Email template design We also wanted to improve our email templates, so that each type of email sent was designed specifically for the purpose. The data shown in a registration email will be different to a topic digest, for example, and the email should reflect that. Coding email templates is not a trivial thing, unfortunately. The latest version of Microsoft Outlook uses the Microsoft Word rendering engine(!!), while GMail strips out all CSS included in style tags - and that's just the start of the gotchas. This makes designing email templates a tricky business, and one that requires lots of testing to ensure compatibility. For our first 10 templates alone, I reviewed 900 screenshots to spot problems. As a result, we've taken the approach of creating email templates which are simple in appearance and would work well for most sites, with the goal of hopefully avoiding the need of most sites to edit them at all (though you can, if you wish). The colors we've used are fairly neutral, for this reason. For those mail agents that are a little more... advanced, our email templates in 4.0 will be responsive. They will look great on mobile devices as well as desktop clients. I have included some examples of email templates, along with their mobile counterparts. I should note at this point that this does not reveal the main skin design. As discussed above, emails are intentionally separate in design. Admin-completed registration Friend request New personal message New profile comment Attached Thumbnails http://community.invisionpower.com/filestore/uploads/monthly_08_2013/blogentry-1094-0-99812900-1375669930_thumb.png http://community.invisionpower.com/filestore/uploads/monthly_08_2013/blogentry-1094-0-76874100-1375669939_thumb.png http://community.invisionpower.com/filestore/uploads/monthly_08_2013/blogentry-1094-0-12341200-1375669942_thumb.png http://community.invisionpower.com/filestore/uploads/monthly_08_2013/blogentry-1094-0-32516700-1375669949_thumb.png http://community.invisionpower.com/filestore/uploads/monthly_08_2013/blogentry-1094-0-37202600-1375669958_thumb.png http://community.invisionpower.com/filestore/uploads/monthly_08_2013/blogentry-1094-0-33328300-1375669968_thumb.png http://community.invisionpower.com/filestore/uploads/monthly_08_2013/blogentry-1094-0-85372100-1375669969_thumb.png http://community.invisionpower.com/filestore/uploads/monthly_08_2013/blogentry-1094-0-77897300-1375669971_thumb.png View the full article at IPS
  3. In 3.x, we support HTML emails being sent by the software. However, due to constraints we had at the time, HTML emails use pretty much the same content as plain text emails, but wrapped in a simple HTML wrapper. Additionally, users had to explicitly decide whether they wanted to receive HTML or plain text emails via a preference setting - quite an anachronism. All in all, not a very satisfactory user experience. Email handling in 4.0 In 4.0, users no longer choose which type of email to receive. Our email handler sends both types in a single email, and the email client chooses the most appropriate to show based on its capabilities. If it can display a fancy HTML version, that's what they'll see by default, but plain text is used if not. Email template system In 3.x, email content is defined by the language system, and each email has one language string which forms the content for both the plain text and HTML versions. Clearly, if we were going to improve the HTML templates we ship with, this would have to change. In 4.x, each type of email has two templates - one for HTML, one for plain text. This means a better display of content can be created for HTML emails, while keeping the plain text ones simple and to the point. Email templates make use of the skinning system foundation (which we'll reveal later), meaning they have full use of logic, template tags and more - so we can also customize the emails depending on the user they are being sent to (note though that email templates are not per-skin; they are global to the site). And, of course, email templates can be added and edited via an interface in the AdminCP. This isn't groundbreaking stuff, but a vast improvement on email handling in 3.x. Email template design We also wanted to improve our email templates, so that each type of email sent was designed specifically for the purpose. The data shown in a registration email will be different to a topic digest, for example, and the email should reflect that. Coding email templates is not a trivial thing, unfortunately. The latest version of Microsoft Outlook uses the Microsoft Word rendering engine(!!), while GMail strips out all CSS included in style tags - and that's just the start of the gotchas. This makes designing email templates a tricky business, and one that requires lots of testing to ensure compatibility. For our first 10 templates alone, I reviewed 900 screenshots to spot problems. As a result, we've taken the approach of creating email templates which are simple in appearance and would work well for most sites, with the goal of hopefully avoiding the need of most sites to edit them at all (though you can, if you wish). The colors we've used are fairly neutral, for this reason. For those mail agents that are a little more... advanced, our email templates in 4.0 will be responsive. They will look great on mobile devices as well as desktop clients. I have included some examples of email templates, along with their mobile counterparts. I should note at this point that this does not reveal the main skin design. As discussed above, emails are intentionally separate in design. Admin-completed registration Friend request New personal message New profile comment Attached Thumbnails http://community.invisionpower.com/filestore/uploads/monthly_08_2013/blogentry-1094-0-99812900-1375669930_thumb.png http://community.invisionpower.com/filestore/uploads/monthly_08_2013/blogentry-1094-0-76874100-1375669939_thumb.png http://community.invisionpower.com/filestore/uploads/monthly_08_2013/blogentry-1094-0-12341200-1375669942_thumb.png http://community.invisionpower.com/filestore/uploads/monthly_08_2013/blogentry-1094-0-32516700-1375669949_thumb.png http://community.invisionpower.com/filestore/uploads/monthly_08_2013/blogentry-1094-0-37202600-1375669958_thumb.png http://community.invisionpower.com/filestore/uploads/monthly_08_2013/blogentry-1094-0-33328300-1375669968_thumb.png http://community.invisionpower.com/filestore/uploads/monthly_08_2013/blogentry-1094-0-85372100-1375669969_thumb.png http://community.invisionpower.com/filestore/uploads/monthly_08_2013/blogentry-1094-0-77897300-1375669971_thumb.png View the full article View the full article at IPS
  4. This hook will take a users Steam info and display their basic info (Display name, online status, game they are in) and display it on their profile page. If you like this version, please consider purchasing the Pro version for $2. Added benefits include: Add as friends link When user is in game, a link to the games steam store page And more to come! View the full article at IPS Resources
  5. Diagnostics For the development team here at IPS, we're constantly striving to make the most stable and reliable software we can. We currently have three main channels through which we hear about potential issues: Our QA team and other power users submit bug reports to our bug tracker. Community owners contact our technical support team who then, where necessary, communicate issues to us. Our Community In The Cloud team monitor server error logs (etc) and where necessary, communicate issues to us. For IPS Social Suite 4.0, I really wanted to examine how potential software issues (as well as general questions and support enquiries, which I'll talk about in another blog entry) come through to us, and if any improvements can be made. The problem with all of these channels is that they're not direct (we don't get the information directly to us) which means we sometimes don't have all the information we need, and if the issue is never reported, we might not hear about it at all. Desktop applications and Operating Systems handle this in a very particular way - they send a diagnostic report straight to the vendor when something goes wrong. This means the vendor gets all the information they need about the problem in a way that requires no input from the user - it's automatic, anonymous and instant. In IPS 4.0, we're introducing the same system. When a problem happens, a report is automatically sent to our servers to let us know. Participation is optional and the report sent is entirely anonymous. What causes a diagnostic report to send? Error handling in IPS 4.0 on the programming level is handled through Exceptions. If a class does something unexpected (for example, if the class which communicates with the database gets an error from the database server, or the class which makes HTTP requests gets an unexpected response), the class will throw an Exception (specifically, a RuntimeException). If an Exceptions is not caught (accounted for in the code), a report will be sent. Also, if a PHP error of a level greater than a notice (a warning) is encountered, it will also throw an Exception (specifically, an ErrorException) which will also cause a report to be sent. What information does a diagnostic report contain? The diagnostic report contains: The trace route of the exception, with personal information (the path to your site, which is usually in the trace of all exceptions, and your database name which is often in the message for MySQL errors) removed. The version number of the IPS Social Suite you are running. The version number of the application which caused the error. The diagnostic report does not contain: Your license key. Your site URL. Any information about the user that triggered the error or any other users. Any information which would allow us to work out which site sent the report. Here's an example of the contents of a diagnostic report, which would be sent if the code tried to get information from a database table that doesn't exist: How do I opt-out? You'll be asked when you install IPS Social Suite, or upgrade to version 4.0 if you want to opt-out. You can change this choice at any time in the Admin CP by simply adjusting a setting, which is in a prominent location. Usage While we were working on diagnostics reporting, we had another thought. The other thing that we as developers really want to know besides if there are any problems in the software is how the software is being used. What features are the most popular? How many forums does the average site have? Do most people use the articles system in IP.Content to manage content or do they create pages manually? How many people have upgraded to our new version so far? While a lot of site owners post in our feedback forum (and we love having that communication) - having the raw statistics for these sorts of questions would be really helpful in knowing what we should focus on (plus, everyone loves charts and graphs). So in a similar vein, IPS 4.0 will also (assuming you've enabled it) periodically (once a month) send a report to us with this sort of information. Participation is optional and the report sent is entirely anonymous. What information does a usage report contain? The usage report contains: The number of rows in each database table. MD5-encoded values of settings - see below. The PHP and MySQL versions installed on the server. A list of the PHP extensions installed on the server. A list of installed applications (e.g. IP.Board, IP.Blog, IP.Gallery, etc.) and their versions. A number indicating the number of active applications in your license (for example, if you have purchased IP.Board and IP.Blog, and both are active, the number “2” will be sent). The usage report does not contain: Your license key. Your site URL. Any information about about users or any user-submitted content. Any information which would allow us to work out which site sent the report. For the settings values - the values are encoded we cannot see the value (so we can’t see your site name, URL, etc.) - this is a blanket protection so that we do not send anything sensitive and the information cannot be used to work out which site sent the report. The encoded values though are still useful - for text-entry settings, we can see if the value has been changed from the default value (since we know the md5 hash for the default value) which is useful to know how many people change the default configuration. For settings which have a limited number of options, for example, can only be turned on or off, or have a drop down list of options, the hash value has meaning as we know the hash values for each option. Even though values are encoded, particularly sensitive settings such as database connection details are stripped completely. Here's an example of the contents of a usage report: How do I opt-out? You'll be asked when you install IPS Social Suite, or upgrade to version 4.0 if you want to opt-out. You can change this choice at any time in the Admin CP by simply adjusting a setting, which is in a prominent location. Attached Files http://community.invisionpower.com/filestore/public/style_extra/mime_types/txt.gif diagnostics.txt (676bytes) downloads: 198 http://community.invisionpower.com/filestore/public/style_extra/mime_types/txt.gif usage.txt (12.4KB) downloads: 136 View the full article at IPS
  6. We've been hard at work on IPS 4.0 for some time now, and we're finally at a stage where we are ready to reveal the new AdminCP to you. I won't be showing you everything the ACP has to offer - some things will be revealed in more detail in later blog entries. But lets get to an overview. Background information IPS4 brings with it a new CSS framework that aims to modularize our styles. This is something we started to work towards in IPB 3.2, but at that time we couldn't completely replace our structure. We no longer have a monolithic ipb_styles.css file. We now have a bunch of small CSS files, and each one handles something in particular. There's one each for forms, tables, pagination, buttons, layout and so on. This brings a few key benefits. Firstly, when we need to make a bug fix in, say, the forms CSS file, IPS4 will still be able to automatically upgrade all the other css files for you. In 3.x, one bug fix in ipb_styles.css could mean the whole file had to be manually upgraded. Secondly, it will be a lot more obvious for skinners where to look for particular things. Need to style a button? Look like buttons.css. Easy. And thirdly, if you're building pages in IP.Content, and you want to use our button styles, you can simply include that one CSS file without needing to include the entire CSS framework. CSS is of course concatenated and compressed before being delivered to the browser, but in a development environment, it exists as I described it above. In IPS4, both front end and AdminCP share the same CSS (and Javascript) framework. Skinners will be able to ship skins that work on both the front end and AdminCP with only a little extra work - and, of course, when we make bug fixes to the framework, it'll fix both areas. Before we go further, I want to make this part clear: The front-end and AdminCP look different. What you'll see shortly isn't what the front-end looks like. We will reveal that separately later. While the same framework is used, the AdminCP extends and overrides parts of it to suit its needs and style. Goals What did we want to achieve with the AdminCP? Our current AdminCP is often regarded as the best out of the big forum software platforms, so redesigning is a big undertaking. Better user of space. Our current ACP uses vertical space for the main menu, and horizontal space for the application menu. In an era of widescreen desktops being standard, this could be improved. Get rid of dropdown menus. The main menu currently uses dropdowns for navigation, but this can be difficult to use - especially if you want access something in a 3rd party app, meaning you have to traverse the Other Apps menu. More consistency across pages. Our current ACP has some interactive tables (e.g. the member list) - but not every table makes use of the functionality. We should be enhancing every page with similar functionality, if it makes sense. Better styling. People aren't a fan of pink, it turns out. I guess it'll have to go. The blue gradients are showing their age too. And the big one: Better mobile support. You can't effectively use the AdminCP on a mobile device. It's time you were able to manage your entire community from your phone with all of the same functionality, right? Responsive by default That last one is what we're most excited about. The AdminCP in IPS4 is fully responsive, and allows you to do everything just on a phone or tablet. What is responsiveness? It means that the page automatically changes to better suit the device you're using. While a desktop user would see full navigation menus and tables of data, a mobile user will see a reduced view (but with all the same data present!). Whether you need to manage your members, change some settings, send a bulk email or run some diagnostics, it can all be done on the go. This is a first for the big community software platforms, as far as I'm aware. Preview Here is a sample page from the new AdminCP, as seen on a desktop, with the same page shown at a mobile resolution: Although I won't include it here, tablets will see an 'intermediate' view with a reduced menu on the left. So, let's go over some of the key features of the screenshots. Navigation First, and perhaps most importantly, is the navigation. On a desktop, your applications are now arranged down the left-hand side, with their respective section menus available simply by hovering on the application - no dropdown menus to traverse. The application menu can be reordered per-admin, allowing each staff member to set the menu up to best suit their role. On a mobile, there's obviously not the space for a wide navigation menu. Therefore, the application/module menu is activated by clicking the top-right icon. This opens a sidebar, from which you can navigate: Tables What you see in the screenshots are our new default way of displaying tables of data. On the desktop view, we have filters across the top, a search box (and advanced search popup), and table headers can be clicked to dynamically sort the data via ajax. On a mobile view, this all collapses down - filters and sorting become menus, while table rows collapse to show data in a more suitable view. Responsive tables are a tricky thing to do right and there's a few different approaches, but given the types of data our AdminCP tables typically show, we think this is the best approach for us. Forms As has been discussed in some of our developer blogs, the IPS 4.0 framework supports a wide range of form field types - everything from text inputs to tree selectors to matrices. All of these field types work both on desktop and with a responsive mobile view. Here's a simple AdminCP form on both desktop and mobile: Tabs Tabs are used extensively, where appropriate. Here's a screenshot showing a typical tabbed page (and it also shows a tree view): Video of the mobile view in action I've taken a short video of the member section in action, showing filtering, live searching and the advanced search popup. I'm using the iOS simulator here, which has some display jitters and requires me to use the mouse, but it should give you a good idea of how the AdminCP will work on a phone. Conclusion So there we go - an overview of the new AdminCP. We still have more to show you. Individual features and pages that are noteworthy will be blogged about in due course in more detail, so keep an eye on this blog and our developer blog for more. Please do bear in mind that this is pre-alpha software, and everything you see is subject to change. We look forward to your feedback! Attached Thumbnails http://community.invisionpower.com/filestore/uploads/monthly_08_2013/blogentry-1094-0-20085200-1375651560_thumb.png http://community.invisionpower.com/filestore/uploads/monthly_08_2013/blogentry-1094-0-46026500-1375652991_thumb.png http://community.invisionpower.com/filestore/uploads/monthly_08_2013/blogentry-1094-0-85526600-1375654840_thumb.png http://community.invisionpower.com/filestore/uploads/monthly_08_2013/blogentry-1094-0-01948000-1375666284_thumb.png http://community.invisionpower.com/filestore/uploads/monthly_08_2013/blogentry-1094-0-38359700-1375666776_thumb.png http://community.invisionpower.com/filestore/uploads/monthly_08_2013/blogentry-1094-0-26958500-1375667467_thumb.png http://community.invisionpower.com/filestore/uploads/monthly_08_2013/blogentry-1094-0-24753400-1375667677_thumb.png http://community.invisionpower.com/filestore/uploads/monthly_08_2013/blogentry-1094-0-03418300-1375725291_thumb.png View the full article at IPS
  7. We've been hard at work on IPS 4.0 for some time now, and we're finally at a stage where we are ready to reveal the new AdminCP to you. I won't be showing you everything the ACP has to offer - some things will be revealed in more detail in later blog entries. But lets get to an overview. Background information IPS4 brings with it a new CSS framework that aims to modularize our styles. This is something we started to work towards in IPB 3.2, but at that time we couldn't completely replace our structure. We no longer have a monolithic ipb_styles.css file. We now have a bunch of small CSS files, and each one handles something in particular. There's one each for forms, tables, pagination, buttons, layout and so on. This brings a few key benefits. Firstly, when we need to make a bug fix in, say, the forms CSS file, IPS4 will still be able to automatically upgrade all the other css files for you. In 3.x, one bug fix in ipb_styles.css could mean the whole file had to be manually upgraded. Secondly, it will be a lot more obvious for skinners where to look for particular things. Need to style a button? Look like buttons.css. Easy. And thirdly, if you're building pages in IP.Content, and you want to use our button styles, you can simply include that one CSS file without needing to include the entire CSS framework. CSS is of course concatenated and compressed before being delivered to the browser, but in a development environment, it exists as I described it above. In IPS4, both front end and AdminCP share the same CSS (and Javascript) framework. Skinners will be able to ship skins that work on both the front end and AdminCP with only a little extra work - and, of course, when we make bug fixes to the framework, it'll fix both areas. Before we go further, I want to make this part clear: The front-end and AdminCP look different. What you'll see shortly isn't what the front-end looks like. We will reveal that separately later. While the same framework is used, the AdminCP extends and overrides parts of it to suit its needs and style. Goals What did we want to achieve with the AdminCP? Our current AdminCP is often regarded as the best out of the big forum software platforms, so redesigning is a big undertaking. Better user of space. Our current ACP uses vertical space for the main menu, and horizontal space for the application menu. In an era of widescreen desktops being standard, this could be improved.Get rid of dropdown menus. The main menu currently uses dropdowns for navigation, but this can be difficult to use - especially if you want access something in a 3rd party app, meaning you have to traverse the Other Apps menu.More consistency across pages. Our current ACP has some interactive tables (e.g. the member list) - but not every table makes use of the functionality. We should be enhancing every page with similar functionality, if it makes sense.Better styling. People aren't a fan of pink, it turns out. I guess it'll have to go. The blue gradients are showing their age too.And the big one: Better mobile support. You can't effectively use the AdminCP on a mobile device. It's time you were able to manage your entire community from your phone with all of the same functionality, right? Responsive by default That last one is what we're most excited about. The AdminCP in IPS4 is fully responsive, and allows you to do everything just on a phone or tablet. What is responsiveness? It means that the page automatically changes to better suit the device you're using. While a desktop user would see full navigation menus and tables of data, a mobile user will see a reduced view (but with all the same data present!). Whether you need to manage your members, change some settings, send a bulk email or run some diagnostics, it can all be done on the go. This is a first for the big community software platforms, as far as I'm aware. Preview Here is a sample page from the new AdminCP, as seen on a desktop, with the same page shown at a mobile resolution: Although I won't include it here, tablets will see an 'intermediate' view with a reduced menu on the left. So, let's go over some of the key features of the screenshots. Navigation First, and perhaps most importantly, is the navigation. On a desktop, your applications are now arranged down the left-hand side, with their respective section menus available simply by hovering on the application - no dropdown menus to traverse. The application menu can be reordered per-admin, allowing each staff member to set the menu up to best suit their role. On a mobile, there's obviously not the space for a wide navigation menu. Therefore, the application/module menu is activated by clicking the top-right icon. This opens a sidebar, from which you can navigate: Tables What you see in the screenshots are our new default way of displaying tables of data. On the desktop view, we have filters across the top, a search box (and advanced search popup), and table headers can be clicked to dynamically sort the data via ajax. On a mobile view, this all collapses down - filters and sorting become menus, while table rows collapse to show data in a more suitable view. Responsive tables are a tricky thing to do right and there's a few different approaches, but given the types of data our AdminCP tables typically show, we think this is the best approach for us. Forms As has been discussed in some of our developer blogs, the IPS 4.0 framework supports a wide range of form field types - everything from text inputs to tree selectors to matrices. All of these field types work both on desktop and with a responsive mobile view. Here's a simple AdminCP form on both desktop and mobile: Tabs Tabs are used extensively, where appropriate. Here's a screenshot showing a typical tabbed page (and it also shows a tree view): Video of the mobile view in action I've taken a short video of the member section in action, showing filtering, live searching and the advanced search popup. I'm using the iOS simulator here, which has some display jitters and requires me to use the mouse, but it should give you a good idea of how the AdminCP will work on a phone. Conclusion So there we go - an overview of the new AdminCP. We still have more to show you. Individual features and pages that are noteworthy will be blogged about in due course in more detail, so keep an eye on this blog and our developer blog for more. Please do bear in mind that this is pre-alpha software, and everything you see is subject to change. We look forward to your feedback! Attached Thumbnails http://community.invisionpower.com/filestore/uploads/monthly_08_2013/blogentry-1094-0-20085200-1375651560_thumb.png http://community.invisionpower.com/filestore/uploads/monthly_08_2013/blogentry-1094-0-46026500-1375652991_thumb.png http://community.invisionpower.com/filestore/uploads/monthly_08_2013/blogentry-1094-0-85526600-1375654840_thumb.png http://community.invisionpower.com/filestore/uploads/monthly_08_2013/blogentry-1094-0-01948000-1375666284_thumb.png http://community.invisionpower.com/filestore/uploads/monthly_08_2013/blogentry-1094-0-38359700-1375666776_thumb.png http://community.invisionpower.com/filestore/uploads/monthly_08_2013/blogentry-1094-0-26958500-1375667467_thumb.png http://community.invisionpower.com/filestore/uploads/monthly_08_2013/blogentry-1094-0-24753400-1375667677_thumb.png http://community.invisionpower.com/filestore/uploads/monthly_08_2013/blogentry-1094-0-03418300-1375725291_thumb.png View the full article View the full article at IPS
  8. This hook will allow admins to change the number of recent comments in Gallery index, in Traditional and Social modes. View the full article at IPS Resources
  9. Author: Dawid Baruch (IPSBeyond.pl) Description: Application allows to send newsletter Functions: Sending custom newsletter Creating and sending interval newsletters from app: Board, Blog, Downloads, Calendar, Nexus and if you want you can create own plugin (docs: http://www.portal.ip...newslettera-r4) tracking click for links in newsletter tracking newsletter opens View the full article at IPS Resources
  10. This hook will show a sidebar block with top posters from the current month. View the full article at IPS Resources
  11. Introduction Modifications, add-ons, plugins, hooks - whatever your preferred name for them is - 3rd party code modifications are an important part of any successful web application. It wasn't that long ago that the way you did this was manually opening up files and copying and pasting bits of code in, or the really cool web applications had points scattered throughout the code for modifications to be injected into, or even scripts which opened up the files and made the changes for you (I'm not joking, that's seriously what used to go on!). In fact, IP.Board was one of the first web applications to, using OOP, support modifications in a more structured way. Currently, we largely have 2 types of modifications: applications, which add whole new areas and functionality to your site (all of our applications: IP.Blog, IP.Gallery, IP.Downloads, IP.Chat, IP.Content and IP.Nexus use this architecture) and hooks which modify or extend the functionality of the IPS Social Suite or of applications. Applications themselves are sort of self-governing so there isn't much to say about them, with one exception: applications will now be able to be downloaded and subsequently installed into your Admin CP as one file - you will not have to FTP upload application source files. The file will just be a regular .tar file, so course, if you were so inclined, you could open it and go old skool. For the rest of this blog entry, I'm going to focus on hooks. Though parts of this blog entry will be more technical in nature than our others, I've tried to keep it just to what everyone will be interested in, and leave the boring stuff until the end. Terminology The term "hook" in 3.x is ambiguous. Sometimes it refers to the whole thing (e.g. "install a hook") and sometimes it refers to a specific technical part of that - the code which overloads other code (e.g. "skin hook", "library hook"), which are, even more confusingly, sometimes called "hook files". In 4.0, we've decided to rename hooks to plugins. The technical parts which make up a plugin will still be referred to as hooks. Sandboxing Plugins, by their nature, extend functionality already present on your site. Up until now, if a plugin experiences a problem (for example, if a new version is installed which the plugin doesn't support) it can cause an error on your site, which disabling the plugin fixes. Starting in 4.0, plugins will be sandboxed. This means that if a plugin experiences an unexpected error (such as a database driver error), your site will automatically fallback to the default behaviour, and your users will never know anything went wrong. Simple (yet advanced) settings In IP.Board 3.x, the Admin CP maintained a massive central area for managing most (though not all) settings. Plugins could add settings to this area, though there was no real standard to where to do that. Also, because this area was separate from the area where you install plugins, it could sometimes be confusing how to configure a plugin after installing it. In 4.0, each plugin is allocated a settings page which is accessed just by hitting the "Edit" button on the list of plugins. Plugin authors can manage this page how they like - rather than being confined to the strictly tabular layout and specific input types in 3.x. Versioning In 3.x, unlike with applications, there was no particularly clear way to upgrade a plugin from one version to another. In 4.x, plugins now support full versioning, so you can just upload a new version, and an upgrader will take care of it. Hook Types In 3.x, there were several different underlying types of hooks: Action overloaders - which allowed overloading the PHP class for any controller. Library hooks - which allowed overloading the PHP class for some (though not all) other classes. Data hooks - which allowed the modification of variables at specific, defined places in the code. Skin overloaders - which allowed overloading the compiled PHP class representing a group of templates. Template hooks - which allowed content to be inserted at specific points in templates. For 4.0, we've made some quite radical changes: Code Hooks The first 3 have been merged into one concept we call "Code Hooks". Code Hooks can overload any class (even things which presently can't be overloaded like extensions) through a technique called monkey-patching (more details have been mentioned in the developer channel). This, combined with the use of Active Record models for all content items (so "Topic", etc. is a class that can be overloaded) also makes data hooks obsolete. Theme Hooks The last 2 have also been merged into a concept called "Theme Hooks" (we're also renaming "skin" to "theme"). The way the current template hooks work is to insert content around certain pre-defined tags in the template. The problem is, not always is the point the plugin author needs available, also this is done in a way the content being inserted isn't aware of it's surroundings, which makes it difficult for things like adding a button to every post, which would need to know information about that post. After thinking for ages about a better way to facilitate theme hooks (I was halfway through a system which injected hook points automatically at compile time), our designer Rikki reminded us that a pretty well-known method for selecting HTML elements already exists... CSS selectors. Video demonstration What's really cool about this is that the content used acts as if it was part of the template - if for example, it's inserted in a foreach loop, the variables created by that are available. It can also use template logic and everything else templates themselves can do. On the back-end, these are compiled into a file which behaves like a 3.x skin overloader - so if it is necessary (or just desired) to overload the compiled version of the template, that is still possible. Theme hooks work for the Admin CP as well as the front-end. Developer information Developers no doubt would like to know the technical information of how this all works. Rather than write a blog entry covering all the different parts of plugins, we thought you might be interested to just see the developer documentation. We have 2 articles we can show you - one covering all the technical details of plugins, and another which provides a step-by-step guide for how to create a plugin. View the full article at IPS
  12. Introduction Modifications, add-ons, plugins, hooks - whatever your preferred name for them is - 3rd party code modifications are an important part of any successful web application. It wasn't that long ago that the way you did this was manually opening up files and copying and pasting bits of code in, or the really cool web applications had points scattered throughout the code for modifications to be injected into, or even scripts which opened up the files and made the changes for you (I'm not joking, that's seriously what used to go on!). In fact, IP.Board was one of the first web applications to, using OOP, support modifications in a more structured way. Currently, we largely have 2 types of modifications: applications, which add whole new areas and functionality to your site (all of our applications: IP.Blog, IP.Gallery, IP.Downloads, IP.Chat, IP.Content and IP.Nexus use this architecture) and hooks which modify or extend the functionality of the IPS Social Suite or of applications. Applications themselves are sort of self-governing so there isn't much to say about them, with one exception: applications will now be able to be downloaded and subsequently installed into your Admin CP as one file - you will not have to FTP upload application source files. The file will just be a regular .tar file, so course, if you were so inclined, you could open it and go old skool. For the rest of this blog entry, I'm going to focus on hooks. Though parts of this blog entry will be more technical in nature than our others, I've tried to keep it just to what everyone will be interested in, and leave the boring stuff until the end. Terminology The term "hook" in 3.x is ambiguous. Sometimes it refers to the whole thing (e.g. "install a hook") and sometimes it refers to a specific technical part of that - the code which overloads other code (e.g. "skin hook", "library hook"), which are, even more confusingly, sometimes called "hook files". In 4.0, we've decided to rename hooks to plugins. The technical parts which make up a plugin will still be referred to as hooks. Sandboxing Plugins, by their nature, extend functionality already present on your site. Up until now, if a plugin experiences a problem (for example, if a new version is installed which the plugin doesn't support) it can cause an error on your site, which disabling the plugin fixes. Starting in 4.0, plugins will be sandboxed. This means that if a plugin experiences an unexpected error (such as a database driver error), your site will automatically fallback to the default behaviour, and your users will never know anything went wrong. Simple (yet advanced) settings In IP.Board 3.x, the Admin CP maintained a massive central area for managing most (though not all) settings. Plugins could add settings to this area, though there was no real standard to where to do that. Also, because this area was separate from the area where you install plugins, it could sometimes be confusing how to configure a plugin after installing it. In 4.0, each plugin is allocated a settings page which is accessed just by hitting the "Edit" button on the list of plugins. Plugin authors can manage this page how they like - rather than being confined to the strictly tabular layout and specific input types in 3.x. Versioning In 3.x, unlike with applications, there was no particularly clear way to upgrade a plugin from one version to another. In 4.x, plugins now support full versioning, so you can just upload a new version, and an upgrader will take care of it. Hook Types In 3.x, there were several different underlying types of hooks: Action overloaders - which allowed overloading the PHP class for any controller.Library hooks - which allowed overloading the PHP class for some (though not all) other classes.Data hooks - which allowed the modification of variables at specific, defined places in the code.Skin overloaders - which allowed overloading the compiled PHP class representing a group of templates.Template hooks - which allowed content to be inserted at specific points in templates. For 4.0, we've made some quite radical changes: Code Hooks The first 3 have been merged into one concept we call "Code Hooks". Code Hooks can overload any class (even things which presently can't be overloaded like extensions) through a technique called monkey-patching (more details have been mentioned in the developer channel). This, combined with the use of Active Record models for all content items (so "Topic", etc. is a class that can be overloaded) also makes data hooks obsolete. Theme Hooks The last 2 have also been merged into a concept called "Theme Hooks" (we're also renaming "skin" to "theme"). The way the current template hooks work is to insert content around certain pre-defined tags in the template. The problem is, not always is the point the plugin author needs available, also this is done in a way the content being inserted isn't aware of it's surroundings, which makes it difficult for things like adding a button to every post, which would need to know information about that post. After thinking for ages about a better way to facilitate theme hooks (I was halfway through a system which injected hook points automatically at compile time), our designer Rikki reminded us that a pretty well-known method for selecting HTML elements already exists... CSS selectors. Video demonstration What's really cool about this is that the content used acts as if it was part of the template - if for example, it's inserted in a foreach loop, the variables created by that are available. It can also use template logic and everything else templates themselves can do. On the back-end, these are compiled into a file which behaves like a 3.x skin overloader - so if it is necessary (or just desired) to overload the compiled version of the template, that is still possible. Theme hooks work for the Admin CP as well as the front-end. Developer information Developers no doubt would like to know the technical information of how this all works. Rather than write a blog entry covering all the different parts of plugins, we thought you might be interested to just see the developer documentation. We have 2 articles we can show you - one covering all the technical details of plugins, and another which provides a step-by-step guide for how to create a plugin. View the full article View the full article at IPS
  13. Included in pack: - The skin files - Layout in .PSD - Screenshot View the full article at IPS Resources
  14. View Registration statistics in Google Analytics. Track which referral domains generate the most registrations Set up goals in Google Analytics based on registration See registrations in the Real Time Report Registration is reported to Google Analytics when user confirms his account by email or an administrator confirms it (thus filtering hit 'n' run registrations) Easy to extend script to call custom code after successfull registration Only 2 settings to be configured See screenshots for demo View the full article at IPS Resources
  15. ABOUT - These team icons are simple and clean for any background. Happy labor day IPB users...we have released our psd for free with this holiday pack special. 30 images Size of images: 140x40 px Type: png Colors: blue, green and red variations PSD included? Yes Font: Nobile (included) INSTALLATION - To install our image pack, simply follow these easy steps! 1. Unzip the downloaded folder with program of your choice. We recommend "7zip". 2. Upload them to /public/style_extra/team_icons folder via your FTP program. We recommend "Filezilla". 3. Login to your ACP and go to Member Groups / Manage Member Groups. 4. Select the group you would like to apply these images to! Ex: public/style_extra/team_icons/smod.png We do not offer psd's with our free releases! (Special release for free for Labor day to IPB users !) If you wish to purchase any of our psd files, it will be a $2.00 charge. Visit us at http://www.teamfod.com for all your support questions or purchasing information ! Please rate my ranks! View the full article at IPS Resources
  16. My first ever skin made for IP Board, using minimal html edits, mainly CSS. Works with most applications but won't be updated in the future. Releasing here free for others to use. Zip file includes installation readme along with the skin and images xml files (mainly default IP Board images). View the full article at IPS Resources
  17. This hook adds a YouTube video inside a sidebar block on the board index. Features: Set the video height, width, and title Multiple or single video use Auto play the video on page start-up Select which groups are allowed to view the sidebar View the full article at IPS Resources
  18. ABOUT - These team icons are simple and clean for light backgrounds. This pack has 8 images included! Size of images: 140x50 px Type: png INSTALLATION - To install our image pack, simply follow these easy steps! 1. Unzip the downloaded folder with program of your choice. We recommend "7zip". 2. Upload them to /public/style_extra/team_icons folder via your FTP program. We recommend "Filezilla". 3. Login to your ACP and go to Member Groups / Manage Member Groups. 4. Select the group you would like to apply these images to! Ex: public/style_extra/team_icons/smod.png We do not offer psd's with our free releases! If you wish to purchase any of our psd files, it will be a $2.00 charge. Visit us at http://www.teamfod.com for all your support questions or purchasing information ! View the full article at IPS Resources
  19. Simply adds a new share link to the bottom of your topics to share to Tumblr. Please be sure to read the ReadMe.html file when installing, I am releasing this as unsupported. View the full article at IPS Resources
  20. Piracy is something that all software companies face and IPS is no exception. Our losses due to credit card fraud and software piracy are significant and to minimize passing along costs to customers, we are seeking to expand our piracy department and take a harder stance against piracy and pursue those who engage in it. The position entails: - Identifying customers, using internal tools, that have inactive licenses and are using later versions of the software than their license allows and report to customer service for license termination. - Identifying customers, using internal tools, that have shared IPS products or marketplace purchases with illegal download sites and report to customer service for license termination. - Following up on usage piracy complaints. - Vigorously pursuing distribution hubs. - Working with web hosts, ISPs and law enforcement. To qualify you MUST: - Be at least 18 years old (for legal reasons, no exceptions to this policy can be made.) - Have excellent written communication skills. English is a must. - Be familiar with identifying the owner and host of a website (i.e.: Using WHOIS and other similar tools.) - Be familiar with the DMCA and associated procedures. - Reside in the United States. If you qualify and are interested, please contact hr@invisionpower.com for more information. Thank you for your interest! View the full article at IPS
  21. Piracy is something that all software companies face and IPS is no exception. Our losses due to credit card fraud and software piracy are significant and to minimize passing along costs to customers, we are seeking to expand our piracy department and take a harder stance against piracy and pursue those who engage in it. The position entails: - Identifying customers, using internal tools, that have inactive licenses and are using later versions of the software than their license allows and report to customer service for license termination. - Identifying customers, using internal tools, that have shared IPS products or marketplace purchases with illegal download sites and report to customer service for license termination. - Following up on usage piracy complaints. - Vigorously pursuing distribution hubs. - Working with web hosts, ISPs and law enforcement. To qualify you MUST: - Be at least 18 years old (for legal reasons, no exceptions to this policy can be made.) - Have excellent written communication skills. English is a must. - Be familiar with identifying the owner and host of a website (i.e.: Using WHOIS and other similar tools.) - Be familiar with the DMCA and associated procedures. - Reside in the United States. If you qualify and are interested, please contact hr@invisionpower.com for more information. Thank you for your interest! View the full article View the full article at IPS
  22. We are back with a creative and juicy theme called "Goody" We made an easy way to get your information fast on the index. When you logged in to your site with this theme you will see a new thing at the top next to the header. http://i73.servimg.com/u/f73/16/52/46/02/goody_10.png When you buyed this theme. We include a special PSD logo for this theme so you can edit the logo itself and still used it on your forum. This theme doesn't have any setting. Next update I will probably make settings for this theme. Any Questions/Concerns Email: admin@themetree.net Website: http://www.themetree.net View the full article at IPS Resources
  23. http://oece.me/trabajos/ipb/gris_skin/gris_skin.png View the full article at IPS Resources
  24. IP.Board 3.4.5 IP.Blog 2.6.3 IP.Calendar 3.3.4 IP.Downloads 2.5.4 IP.Gallery 5.0.5 Installation instructions. Included: PSD Logo Blank PNG Logo Blank PNG Team icon http://community.invisionpower.com/index.php?app=downloads&module=display&section=screenshot&id=6628 Orange 1.0 Category: Light Skins Last Updated Aug 16 2013 05:11 AM Orange skin View the full article at IPS Resources
  25. Greek language pack for Invision Power Board 3.4.4. Work in progress. Based on www.greekmeds.gr This is only the System section of the translation, which is 60% complete for the PUBLIC section. Regular updates will be published here until the translation is 100% complete, including corrections. All updates will be free to purchasers. Please post comments/corrections on the Greekmeds topic. Ελληνική μετάφραση Invision Power Board 3.4.4. Χρησιμοποιείται στο www.greekmeds.gr Το παρόν αρχείο είναι μόνο το τμήμα "System" της μετάφρασης, 60% μεταφρασμένο για το μέρος που φαίνεται στους χρήστες. Θα ανεβάζουμε διορθώσεις εδώ ώσπου η μετάφραση να ολοκληρωθεί 100%, με σχετικές διορθώσεις. Οι ενημερώσεις θα είναι δωρεάν για όσους αγοράσουν το αρχείο. Παρακαλούμε σχόλια και διορθώσεις στο σχετικό θέμα στο Greekmeds. View the full article at IPS Resources
×
×
  • Create New...

Important Information

By using this site, you agree to our Guidelines, & Privacy Policy. We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.