Jump to content

bfarber

Clients
  • Posts

    163,911
  • Joined

  • Days Won

    346

 Content Type 

Downloads

Release Notes

IPS4 Guides

IPS4 Developer Documentation

Invision Community Blog

Development Blog

Deprecation Tracker

Providers Directory

Projects

Release Notes v5

Invision Community 5 Bug Tracker

Forums

Events

Store

Gallery

Everything posted by bfarber

  1. I'm surprised another topic has been opened about this tbh. :unsure: The reason people don't bother upgrade most of the time is become nothing forces them to. It was the same way with PHP5 - had tons of nice features and functionality we've been wanting to put to use, but because hosts didn't want to upgrade because nothing forced them to, nobody releasing an application available to a customer base could really make use of the new features for a very long time. IE8 is almost out. IE6 will be EOL very soon. At some point you have to move on. There are potential alternatives for IE6 users, but we can't concentrate on supporting 10 year old technology. It's just unrealistic. The bulk of the big issues will be fixes as Charles has stated. But it's about time to move on, and the longer people (including us) cater to the outdated browsers, the longer people will cling to them, since there's no reason not to.
  2. This is a setting in IPB3. It's already added. You can opt to turn it on or off at your own will.
  3. It's a hook. Users can create and edit hooks at will. I think recent topics is more valuable to most busy sites (replies would simply mean the list wouldn't sit still long enough to view much of interest usually), but that's of course an opinion and I'm sure it's one that differs from many. That's the beauty in the hooks system. Your quote content doesn't seem to really be a bug - you have incomplete url tags (so they didn't parse), though I don't know how you submitted the content originally to compare.
  4. There are a plethora of ban options in IPB3... From the warn panel you can "ban" indefinitely, or for a specific time period. This does not change their group - it works identical to IPB2. From the ACP you can access the ban panel for a user where you can "ban" the account (this sets a flag on the account, banning them from the site, without changing their group or anything else), and add their data to the ban filters (IP address, username and email address). You can also, of course, still move a user to a banned user group should you wish, however it is not necessary (if for instance you didn't want anyone to know the user was banned). There is a blog entry from middle of last year in our blog on this if you are interested in reading about it more.
  5. It's timing out, simply. Are you running php from command line? If not, on a medium or larger database it's going to be very hard to try to run this script through your browser.
  6. Firstly, you should run the script from command line. If you do, your .htaccess changes will have no impact because you're not using apache. Additionally, you'll need to get rid of memory limit and max execution times to give it enough power to finish. Secondly, I do agree, processing in batches might prove more reliable. What will happen if someone has 1M posts?
  7. Yes, I think he's just saying not to use this on your live site as of yet. ;) Could/probably will break something until more testing is done. Impressive Valtasar. :) This isn't the easiest thing to deal with by any means.
  8. Yes, it is effectively the same function. We do not use any enum, set, or longtext fields, to my knowledge, but you can look and convert them if there are any. The list is fine otherwise. This is most likely from AJAX functionality. html_entity_decode won't generally be able to convert these character entities, however mb_convert_encoding might be able to using the special HTML-ENTITIES "character set". Indeed this is a big problem, and I'm afraid there's no easy solution. They are not solely latin characters (e.g. polls and poll data is serialized), so they cannot just be left as is, unless that's a compromise in creating the script from the start ("your polls will not convert") that the user is ok with. The proper solution would be to select the serialized data, unserialize it, iterate recursively through the array, convert each value and store the converted value back into the array over itself, reserialized, then the db value updated.
  9. We do not presently have any tools that allow you to convert your database character sets. I posted a sample of how such a library could be written for ipb3 earlier but there is no final script, no.
  10. The charset conversion libraries from IPB2 are the same ones that will be used for IPB3. With IPB3 we are going to provide them as a separate download - practically none of our users have a need for them, and they consume something like 10MB of space, so we'll just offer them as a separate download for those who do need them. In the mean time, you can just use the folder from IPB2.
  11. I would rather add a copy topic feature. You would lose the ability to have replies to one of those topics show in the other one, of course, but you would be able to place a topic in more than one forum. Alternatively, you can move a topic from one forum to the other, which would show the redirect link (if you allowed).
  12. Oh, and to further what Josh said, lofi links that are indexed in Google *will* be 301 redirected to their proper location in 3.x. You won't simply start getting 404 errors from them.
  13. IP.Board will now support a basic implementation of Facebook Connect as an option for logging into IP.Board and associating their account with the same login as their Facebook account. This feature will be off by default and can be optionally enabled by the administrator. We will have a technical specifications draft available in our knowledgebase upon release for those who care, but the basics are as follows: You must first register an "application" on Facebook's website pointing to the integration file included with IP.Board 3. You then must enter some basic keys that Facebook provides in your ACP.Users will have the ability to use Facebook Connect to login to your site. They will also have the ability to either associate their Facebook account with an existing IP.Board account, or create a new IP.Board account.Basic profile data such as avatar, profile picture, "About Me", and status will be synced to IP.Board from Facebook We have purposely kept the complexity of the various syncing options available through Facebook Connect to a minimum. We have many ideas on how we would like to expand the capabilities in the future, but we wanted to keep this integration basic for the time being. Facebook Connect support will be available with the second beta release of IP.Board, and will be available on the preview site to test with beginning Monday. We hope you enjoy!
  14. I'm just going to state for the record that on a personal level, I'd love to get more integration with third party software. That includes additional login methods and integration with larger software packages like Drupal and Wordpress. I'm considering looking into them (independently/not here at work) later this coming year.
  15. As announced in our last blog entry, we are working diligently to clean up any problem areas in IP.Board 3.0 and to finish up the admin control panel so that we can deliver a beta release of our software to all of our users before the end of this month. Things are taking shape nicely. Rikki has the admin control panel nearly finished and we've cleared out hundreds of bug reports since the preview site was first launched. We are very hopeful that by the time everyone has their hands on a beta version of IP.Board 3.0, you'll find all of the biggest potential issues have already been dealt with. Additionally, the Blog, Gallery and Download Manager applications are coming along nicely as well. All of the application code has been converted, and we're working on skinning these modules so that we can put up previews for you to start testing. Look for the first of these modules to be launched very soon on the preview site so you can begin testing it. In preparation for the upcoming beta release of IP.Board 3.0, we have put together this script which you can upload to your server in order to test for support of our latest version. Please note the following requirements: PHP v5.1.0 or higher (5.2.0 or higher preferred)MySQL 4.1 or higher (5.0 or higher preferred)SPL, GD2 and libxml2 PHP modules installedThis script will test for everything IP.Board 3.0 requires, except for MySQL. Please consult with your host if you are not sure if you are running MySQL 4.1 or higher. check_requirements.php To use this script: Upload the file to your server somewhere that is web accessible. For example, you can upload the file to your forum root directory where "conf_global.php" is located.Visit the file in your webserver. For instance, visit http://yoursite.com/forums/check_requirements.php (replacing yoursite.com/forums/ with the appropriate domain and path to the script you just uploaded).Verify there are no "FAIL" marks reported. If there are any items that fail the check, you will need to consult with your host about updating your server, moving you to another server that supports all of the requirements for IP.Board 3, or contacting another host that does.We do not rely on any proprietary modules for PHP, so the majority of our users shouldn't have any problems. :) We look forward to getting the first beta out so everyone can continue testing the software and the new admin control panel. More information to follow!
  16. We support AddonChat and ParaChat. We have a shoutbox as a community project as well.
  17. Oh that's irrelevant. We should be able to add any feature someone dreams up and it should run on that Pentium 2 shared server user xyz is using that has 1 GB of RAM and 5 GB hard drive space, with 50 accounts on the box. /end sarcasm People don't consider these sorts of things you know. ;)
  18. Perhaps. There are a lot of features I don't personally see the point of that I/we add. ;) I was just saying it's not in 3.0.
  19. See, there are times when AJAX can be very useful. It's an interesting, and often useful technology. But as with any technology, a lot of people go overboard and want this feature and that feature to use AJAX, just because it's "cool". Submitting a form, in general, does not normally require AJAX. There are cases where it is useful and can be done, but replying to a topic, in my mind, is simply not one of them. I'm sure there were will be addons for this, due to the demand/requests for such a feature. But at this time it is not a 3.0 feature.
  20. What I've had to do is modify a kernel library (ips_kernel/class_file_management.php) and print out the ACTUAL response from feedburner, which includes the Location header. I've "fixed" this for 3.0 by adding support for curl, and verified it follows the url properly.
  21. We've been blogging for a while about some of the bigger changes you will see when IP.Board 3 is released. Things like enhanced bbcode management, hooks and plugins, and personal conversations, for example, tend to be a bit more interesting to read than smaller features. However, we wanted to take a moment to discuss some of the other smaller features being added to IP.Board that we haven't talked about yet. Minimum posts to view forum You can now configure forums to only allow access if you have reached a minimum post count. Minimum posts to post in forum Similar to the previous setting, you can require members to have a certain post count before they can post in individual forums. Only allow posters to see their own topics A very commonly requested feature, you can now configure forums so that posters can only see their own topics. Of course moderators and admins can view all topics in the forum. This allows you to create "help-desk" style forums without the need for additional software. HTTPS login form You can now force your login page urls to utilize https via a simple ACP setting. You are still responsible for obtaining an SSL certificate and installing it to your server properly. "Performance Mode" We have several larger customers who have a relatively stationary amount of traffic, but have huge spikes at times (e.g. sports teams have huge spikes in traffic on game nights, typically). During these spikes it is often desirable to disable unnecessary features to maintain site stability, rather than purchase hardware to handle temporary spikes in traffic. The performance mode setting allows you to easily disable many features that can save resources with the click of a button. The system remembers the previous setting values so that when the spike dies down you can disable performance mode and return your site to it's previous configuration. Registration "question and answer" In IP.Board 3 you will be able to configure questions and associated answers which will be randomly added to the registration form to help combat automated registrations (spam bots). Loading javascript files from Google Google offers a service that allows you to load the prototype and scriptaculous files from their servers rather than your own. This offloads 2 http requests to Google's servers from your own, while allowing them to manage the proper cache and expiration headers for the files. Guest selectable skins and languages Guests can now change their skin and language selections if you offer multiple skins or languages. Note that skins can be configured to only be available to certain groups, so you can fine-tune which skins guests can select from. Better topic/forum subscription controls You can now unsubscribe individual members from all forums and topics from the edit member page of the ACP, and you can unsubscribe all members from individual forums from the forum management page. More control over "friends" You can now disable the friends feature globally via a setting, and individually on a per-group basis (e.g. to prevent validating members from using the friends feature). Hide last post info for a forum If you have a forum where different users have different configurations as to which topics they can view, you can hide the forum's last post info on the board index via a setting. This information is cached to improve performance, so it does not utilize permission-based lookups, thus the ability to hide it helps prevent topic information from being leaked. Contact fields as custom profile fields All of the contact fields (yahoo, aim, msn, etc.) are now custom profile fields, allowing you to more easily configure them to your liking (or remove them alltogether). Additionally, by default Jabber and Skype will be available for configuration. Force an entire group to be anonymous If you would like to force an entire group (administrators or banned members, for instance) to be anonymous upon login, you can do so easily now. Moderate posts of an entire group globally You can now configure a group to be moderated across the entire site via a group setting. This will force all of the group's posts and topics to be placed into a moderation queue before they are visible, regardless of individual forum settings. Per-group signature restrictions You can now control the maximum number of images, lines of text, and image dimensions for signatures on a per-group basis. Here's a taste of some of the new features we haven't previously discussed (at least in any detail) which we hope you'll like. Let us know what you think!
  22. Feedburner redirects the request for some reason behind the scenes. If you get the url it redirects to you can use that url. Might take a look at having the RSS importer support CURL, which can handle redirects.
  23. With the upcoming release of IP.Board 3, we will of course be updating our first-party components to be compatible with the new architecture. Releases of IP.Blog, IP.Gallery and IP.Downloads will be available alongside IP.Board 3.0 so that you can update everything at the same time and not have to worry about when your components will be ready. We are working with the community project teams to help them get releases of Tracker and Shoutbox ready for 3.0 as well. They should be available at, or shortly after, the release of 3.0 to help ensure a more seamless move forward to our latest platform. We've determined that initially for the big release, we will only be working for application compatibility between our components. We wanted to spend all of our time focusing on IP.Board itself to ensure maximum stability, especially given the fact that we are working on an entirely new platform. This means that you won't really notice any new features to speak of with the Blog, Gallery and Downloads updates. You will, however, notice much better integration between the applications and the board itself, and an updated look and feel for all applications. Some examples of this include Integrated searching - one search form will search everythingAll application caches managed from cache management screen.All skin data managed from template editor screen.Ability to edit all group settings from group management page.All application permissions handled from one location.Ability to show gallery or blog data on board index through hooks Shortly after the dust settles following the big releases, and everything is calmer and stable, we will be working on "big" updates for our first-party application addons. At this point, we are still discussing what new features would best serve our customers for Blog, Gallery and Downloads. Below is a list we've discussed that we think you'll like. What do you think of it so far? IP.Blog Site/group blog - a blog that can be created belonging to no individual member, but rather to the site as a whole (i.e. a company blog) or a group (i.e. a developer blog)Proper user-customizable headersRSS blogs - allow members to import their remote blog into your board"Blog this post" support IP.Gallery Ability to crop, rotate, dynamically resize images. Use Javascript for front end, then re-generate image using GD on backend when user saves.Fancy slideshow feature. Something like Flickr, but done completely in Javascript (no flash needed), little simpler probably.Better album control based on friendships - only allow friends to view album, allow friends to submit to your album, etc.Sub-albumsImage taggingCorrect category/album markers (ala IPB)Allow users to choose album covers from images in an album IP.Downloads Better and more abstracted support for file records. Ultimately the goal would be to allow you to submit multiple files to a single file record. Uses would include "contributed files", breaking single files into "parts" (i.e. for large movies), and multiple screenshots per record, for instance.Support for mirrorsAbility to shut off "resume breakpoints"Better category control - template type system perhaps with ability to selectively override without ditching entire templateMore reliable upload progress meterCorrect category markers (ala IPB)File taggingDynamic and session-based download urls (when you start a download, create a new "url" for it that is only accessible for that session and is destroyed afterwards to further prevent hotlinking) These are just some ideas we're floating around. Final feature lists will be determined after the release of IP.Board 3.0. We know many of you have been wondering how component updates will be handled with this release, and we've stayed quiet mainly because we weren't certain what we'd be able to accomplish. Hopefully this information will help you plan your site updates accordingly.
  24. Introduction Administration is an important part of running your site. You need to be able to control your site the way you want to, and you need to be able to do it as quickly as possible. Not everyone has an hour or two to hunt down a setting, after all. Once you start to factor in the fact that other applications (such as IP.Blog, IP.Gallery and IP.Downloads) can integrate into this same administration control panel there are new challenges to take into account as well. With IP.Board 3 we've made improvements to the ACP in an attempt to help streamline common administrator actions and make the overall work flow clearer and easier. Navigation Navigation is a tricky thing to manage once a project becomes as large as IP.Board has. We've broken navigation down into multiple areas to help you drill down and find what you are looking for. Firstly, each application is listed at the top of the page - that way you can jump to whatever application you need to edit right away (no more navigating to the "Components" tab to edit IP.Gallery categories, for example). Then, along the left hand column you will find an expandable menu which provides access to the main pages of the application, similar to IP.Board 2. For applications requiring it, context links and tabbing are then utilized within the main area of the page to facilitate your work flow. We realize without screenshots it may be hard to visualize the new ACP, but a primary goal throughout the whole process was to retain a level of familiarity so that existing admins will find navigating very natural, while improving the process where-ever possible. Searching One complaint we've heard over the years is that new administrators frequently have trouble finding where they need to go in the ACP. Searching is a natural inclusion to help people find what they need, and can even be helpful for seasoned administrators as a shortcut to get where you need to go quicker. We have added a live-search facility to the admin control panel to help you find what you need much much easier (and before anyone asks - yes, "live search" is like the search on apple.com :rolleyes: ). The settings page already had search functionality in IP.Board 2, but we felt that wasn't good enough. Many times the "setting" you are looking for is found when editing a group, not actually in the main site settings area. To that end, the live search searches "settings", "pages" and "acp help" files. We have also included a method of adding keywords to these sections so that if we find many users are looking for an area through a specific keyword, we can easily add that keyword into the system so that searching for it will return the results people are looking for. We will need your help once IP.Board 3 goes into beta testing with identifying areas that need keywords added for new administrators. What a wonderful way for all of you who are so eager to help out to give back to the community! And you don't even need to know PHP or HTML for this. :D Better Integration While we have mostly already gone into detail on this front in other blog entries, just to recap on the subject within the context of this blog entry, improvements have been made to areas of the ACP that people frequently need to plugin to in order to help improve usability overall. For instance, an application can now show per-group settings on the actual group edit form, instead of having to provide a separate disconnected page in the application itself (for instance, the "Group Settings" page of IP.Gallery - these settings are now directly include on the edit group form instead). Similarly, applications can plugin to the edit member pages of the ACP, all with no file editing required. Settings for an application can, as they could in IP.Board 2, still be included within the settings area of the ACP. This means you can edit a group and control all of it's settings, without having to go to each application separately to update settings for the group. Permission Editing Many applications have a permission matrix - a grid of checkboxes that control what each permission mask can do within that application. This system works so well that we centralized the functionality in IP.Board 3 to make it easier to reuse and control. In doing so, we've also created an easy method of updating settings for every application on a per-permission set level. That is to say, if you want to update the permissions for users in the "Validating" group, you can do so globally from one page - for all applications at once. Remove calendar permissions, forum permissions, and gallery access all at once, without having to visit each application individually. Going along with this, many users have been confused with how permission sets and groups relate to each other. We hear often from administrators that they created a new group - now how do they set the permissions for that group? To make this easier to understand and manage, when adding a new group there is a field that will allow you to fill in a new permission mask name (if you want to set permissions for the new group differently from other groups). After you save the new group, you will be redirected to the page that allows you to edit that group's permissions globally. You no longer have to create the mask first, set all the permissions (in each application separately, as well) and then add the group afterwards, selecting the new mask. Now it can all be done in one simple, easy to understand work flow. Template Editing I can't give out too many details on the template editor interface *just* yet I'm afraid, but let's just say that template editing has been entirely overhauled. We have put a lot of thought into ways of making it easier to edit templates, CSS and macros to hopefully help administrators work through their skins in a much much easier fashion. Some improvements that you may find interesting: HTML Syntax highlighting of skins when editing the templates in the ACPCondensed HTML templates make it much easier to edit an entire "page" without having to edit 8 separate templates that will be compiled into one pageNo more separate "Global board header and footer wrapper" area. We have, instead, made a wrapper template which includes the content of this area as well as the global_board_header, global_board_footer, member_bar, navigation, and a few other common areas shown on every pageAJAX CSS editing. This was actually a specific request from Rikki - apparently it's rather inconvenient to scroll 3 pages down in the CSS file, edit a color, save it, and end up at the top of the file/textarea and have to find where you were at again. Go figure. Anyways - when you save a CSS file now, it uses AJAX to save the contents, and the page remains stationary so you don't lose your place. Reordering content Remember all those lovely reordering dropdown menus (e.g. in the forum management screen)? Or those wonderful up/down arrow combinations (e.g. in the component management screen)? While they certainly served their purpose, they were identified for IP.Board 3 as being both inconsistent and, well, old. All areas utilizing reordering functionality for all of our applications will use drag-n-drop + AJAX javascript functionality in IP.Board 3. Want to move a forum up one spot, just drag it up there and you're done. In Closing We think you will find that all in all the ACP area will be much easier to navigate and utilize in IP.Board 3. Once we get into the public beta testing stages and you get a chance to review our changes we'll be eager to hear your opinions and suggestions on the new and improved administration area.
  25. I'll say right now, while "proper database design theory" calls for no comma-separated strings, in reality it's not always easy or the most efficient way. While we recognize that some areas of the database design can *always* be improved, I'll state right now that it's not likely IPB3 will have no comma-separated strings in the database.
×
×
  • Create New...