bfarber
Clients
-
Joined
Everything posted by bfarber
-
Sending email is an important part of almost any web software available today. Social Suite applications have varying needs for sending email. Examples include allowing users to confirm their email address during registration, advising users when there are updates regarding content they are following, and bulk mailing your member base to alert them to something important regarding your site. While functionally the email handler has not significantly changed in 4.0, the process has been vastly simplified, allowing you to send more consistent emails with far less code than in the past. Building and sending emails When sending email in the Social Suite, there are two primary types of email you might need to send: an email based on a pre-existing template that you swap out variables in, and a completely custom email where you define the body specifically for the current email being sent. Both of these scenarios are accounted for. First, let's take a look at the simpler and more common scenario where you send an email based on a template. IPSEmail::buildFromTemplate( 'core', 'admin_spammer', array( $this ) )->send( IPSSettings::i()->email_in ); Here, we are building an email from a template ("admin_spammer" in the "core" application, more on that in a moment), passing the current object in for purposes of replacing out variables in the template, and then calling the send method to actually send the email, passing the recipient to it. The buildFromTemplate() method is a factory method that will create a new object of type IPSEmail. When calling the send() method, you can optionally pass a single email address to send the email too, an array of email addresses to send the email to, or a single instance of IPSMember or an array of IPSMember instances to send the email to. The library takes care of the rest. The other type of email you may need to send is a completely custom email where you define the entire body without using a template. Bulk mails are a good example of this type of email. You can easily send these types of emails as well. $email = IPSEmail::buildFromContent( $subject, $htmlBody, $plaintextBody ); $email->from = "john@doe.com"; $email->send( "jane@doe.com" ); Here we call the factory method buildFromContent(), passing in the email subject, the HTML email body, and the plain text email body. You can optionally omit the plain text email body and it will be generated for you automatically. We then specify the from address (which defaults to the suite's outgoing email address), and finally we call the send() method, passing in an email address. While it is not recommended, you can create an email object without specifying either email body parameter, and specify these later if you have a need. Further control and options Beyond what is outlined above, you have fine-grain control over the details of the email being sent. The following example outlines more of the possible values you can specify when necessary $email = IPSEmail::buildFromContent( "Hello world" ); $email->from = "john@doe.com"; $email->fromName = "John Doe"; $email->subject = "Changed my mind to hello planet"; $email->useWrapper = FALSE; $email->headers['X-Mailer'] = "My cool app"; $email->headers['Priority'] = 3; $email->setBody( array( 'html' => "<html><body><b>My email</b></body></html>", 'plain' => "My email" ) ); $email->send( array( "jane@doe.com", "janet@doe.com" ), array( "abc@abc.com" ), array( "test@test.com" ) ); Most of the above should be self-explanatory. Just a few quick notes: You can set the $useWrapper property to FALSE if you do not wish for the email to be wrapped in the standard default HTML and plaintext email wrappers. The wrappers primarily define the HTML structure (doctype, html tag, etc.) and also allow for automatic definition of the unsubscribe link. You can call the $unsubscribe property to manually define an unsubscribe link and the text to display. Alternatively, you can call the "buildUnsubscribe()" method (see below) to do this automatically and consistently. There is no point in doing this if you do not use the wrapper, however, which is why it is omitted in the example above (in this case you should manually include an unsubscribe link if appropriate). The first parameter passed to the send() method is the to addresses. The second is the CC addresses, and the third is the BCC addresses, if necessary. Automatically handling an unsubscribe link Links to handle unsubscribing from emails can be accommodated automatically with emails sent through the email handler. For bulk emails, the following method is called $email->buildUnsubscribe( 'bulk', IPSMember::loggedIn() ); The first parameter is the 'type', which is 'bulk' in this case. The second parameter when specifying an unsubscribe link for a bulk email should be the member who is being emailed, as their personal details are used to generate a unique key allowing one-click unsubscribing. When sending notification emails, you still call buildUnsubscribe() with the following parameters $email->buildUnsubscribe( 'notification', 'my_notification_key' ); Instead of a one-click unsubscribe link being included, a link pointing to the user's notification preferences area will be included instead, highlighting the notification preference that caused the email to be sent. Unsubscribe links are only automatically included in the outgoing email if you (1) call this method, and (2) use the default wrappers. Email templates While we will touch on this further in a future blog entry, email templates are now defined in a similar manner to HTML templates, and there is one template for the HTML version of the email and one template for the plaintext version of the email. This allows us to better tailor the email being sent dependent upon the content-type in order to provide the nicest experience for the user. The email subject is a language string based upon the email template name and is determined automatically by the email library when buildFromTemplate() is called. Wrapping Up While the email library still provides plenty of control to accomodate almost any scenario encountered within the Social Suite, for day to day needs the interface to send emails has been vastly simplified in order to provide a more consistent experience for both the user and the developers integrating applications within the Suite. We hope you find these small changes will make your jobs easier, without losing the control you have presently. -
Our proprietary Spam Service which was launched in 2009 has been a very popular feature for IP.Board license holders. This service (which is included at no additional cost for all active license holders) is queried during account registration on your IP.Board installation and will respond to the query with a flag to indicate the likelihood that the registration might be a spammer. You can control how your site should react to the various responses the service may return in the admin control panel, and combined with other anti-spam tools in IP.Board you can help prevent spam registrations from occurring on your site. While the system is constantly "learning" and blocking new spam signups, we have performed some updates to the service recently that we feel will help the system respond even quicker and more reliably to spam account registrations. First, Some Stats For those interested, we have some interesting statistics to share with you. To date, the spam service has responded to over 58 million requests! The service has responded to almost 163,000 requests in the last 24 hours alone, and the service continues to respond to between 5,000 and 10,000 more requests day over day. A total of over 23 million user registrations have been blocked (i.e. a status code of 3 or 4 was returned by the spam service) to date. That's 23 million spammers we've helped you prevent from disrupting your community. Quicker Responses With the recent updates we performed, the system will more quickly respond to new spammer accounts than it did previously. It is important that the system do not treat a single report of a spammer as a permanent block on that account of course, however we identified several areas where the algorithms used could be tweaked to more quickly identify potential spammers and have performed these changes. Additionally, by use of decaying flags (treating newer reports with a higher priority than older accounts), the system can more quickly respond to new spammer threats. Project Honeypot Integration We have integrated our spam service with the popular Project Honeypot service. This means that all account registrations are checked through Project Honeypot, and the threat score that is returned from this service is used to help determine the likelihood of the IP address being associated with a spammer. Stop Forum Spam Integration In addition to integration with Project Honeypot, we have integrated the IPS Spam Service with Stop Forum Spam. Our spam service will check the Stop Forum Spam email address and IP address databases and use any information found here to help weight and score the likelihood that the registration is coming from a spammer. It is important to note that we do not rely directly on the Stop Forum Spam data to determine a spammer status, but are instead using the data from this service to help weight the overall score based on all of the flags we have available. Enterprise Spam Mitigation If you are in a load balanced or cloud environment, you may wish to take advantage of this new offering which allows calls to the spam service from multiple origins using the same license key. Additionally, this service allows greater control over your spam mitigation service including weighting algorithm preferences and customized blacklists and whitelists. This addon service is available for $100/6 months. For more information, please contact our sales department. Collectively we feel the changes we have made to the service will benefit all IPS customers who are making use of our IPS Spam Service. We hope these changes help your community fight the threat of spam more rigorously and more reliably than ever before.
-
The following applications are available for beta testing: IP.Board 3.4.5 IP.Blog 2.6.3 IP.Content 2.3.6 IP.Chat 1.4.4 IP.Downloads 2.5.4 IP.Gallery 5.0.5 IP.Nexus 1.5.8 IP.Calendar 3.3.4 This round of maintenance updates represents updates to all of our applications. At this point in time, there are zero open bug reports in our tracker (that are not flagged to be resolved in a future major version). We would like to encourage all interested users to perform as much testing of these apps as possible. We will be upgrading our company forums early this coming week. Please report any bugs you find with the beta to our bug tracker. Please pay particular attention to the following areas:The editor, both within IP.Board (topics/posts) and in other areas (such as IP.Content articles, IP.Blog entries, etc.). Pay attention both to the editor itself (i.e. when typing out and formatting your post, and toggling the editor back and forth) and the final post that is submitted. Rebuilding posts, specifically upon upgrading from an older version of the software. Pay attention specifically to quotes to be sure they display correctly. Any IP.Nexus functionality that has to do with grouped renewals. Cancelling packages where renewals are grouped, reactivating those packages, changing those packages, etc. If you find a bug, please be certain to report it to the bug tracker. When doing so, be sure to include as much information as possible that will allow us to reproduce the issue, including what browser you are using, what version of PHP is running on your server, whether this was an upgrade or a fresh installation, and so on. Screenshots are often helpful. As with all beta releases from IPS, these releases are not supported by our technicians until the official final releases are publicly available in our client center. Please do not upgrade your live installation using these betas, as you may find no path between these builds and the final releases that we put out. We recommended, instead, to create a copy of your live board as a test installation, and upgrade your test installation instead. All customers with active licenses can download the betas at: http://community.inv...ower.com/qa.php Thanks in advance! We look forward to your feedback.
-
IP.Board 3.4.4 is now available for beta testing! We have been hard at work on IP.Board 3.4.4, and following a good week of testing here on our company forums, we have built a downloadable IP.Board 3.4.4 package for you to test on your own servers. We appreciate any testing you can perform. Please report any bugs you find with the beta to our bug tracker. Please pay particular attention to using the editor with IP.Board 3.4.4. A very large focus was placed on resolving some of the outstanding bugs and complaints with the editor, and we would appreciate any testing you can perform in this area. Create new posts, edit existing posts, toggle between the editor modes - if you find any bugs, let us know. As with all beta releases from IPS, IP.Board 3.4.4 is not supported by our technicians until it has been officially publicly released. Please do not upgrade your live installation using this beta, as you may find no path between this build and the final release that we put out. We recommended, instead, to create a copy of your live board as a test installation, and upgrade your test installation instead. All customers with an active IP.Board license can download the beta at: http://community.invisionpower.com/qa.php Thanks in advance! We look forward to your feedback.
-
One question I have seen surface in the past (and present), revolves around how we decide when to use a third party library or framework, and how we decide when to develop something in-house entirely. For instance, in the 4.0 Suite we will utilize jQuery (a third party javascript framework), however we will build our underlying PHP framework in-house. How did we decide to go that route? There are several PHP frameworks on the web, many of which having licenses compatible with our commercial license, so why didn't we choose one of those to kickstart 4.0 development? This is, admittedly, often a difficult question to answer. The truth is, we evaluate each scenario on a case-by-case basis and make decisions based on what is best for us and our clients. Sometimes these decisions may not be obvious, however you should know that much thought has gone on behind the scenes here at IPS to ensure we are making the choices that we feel are best for our products. Javascript frameworks are almost an essential tool with today's fast-paced browser development and web advances. Browser updates from some vendors are almost weekly. We went from HTML 4 to XHTML 1 to HTML 5 within but a few years. And while everything a javascript framework does can be replicated in-house, it would consume a lot of development time that we would have to spend in order to keep pace with all of these changes, purely for compatibility reasons (e.g. no new functionality added, just to keep things working and up to date). We have long-ago determined that using a well-maintained javascript framework to facilitate javascript development is virtually a necessity, otherwise you quickly get bogged down trying to maintain javascript code just to retain compatibility with current browsers and newly available functionality. What about PHP frameworks though? There are many out there (CodeIgniter, Zend Framework, etc.) and many are relatively robust, well tested and quite extensible. Why have we chosen to write our own underlying framework given this information? In researching whether to maintain our own framework or use an existing one, we had to weigh many pros and cons. For instance, one pro using third party PHP frameworks would be that we can skip all of the development of underlying classes (controllers, autoloaders, database connector and so forth) and jump into the higher level development. This is surely an important consideration to take into account. On the other hand, using third party PHP frameworks ties us into that framework, and we expect the underlying codebase in the 4.0 series to last several years once it is released. What if the framework we choose to utilize is no longer maintained 2 years from now? What if a security issue arises in the third party framework, but it is not rectified quickly? We certainly can't leave our clients vulnerable to known security vulnerabilities while we wait for a third party to patch it. What if the framework developers release an important update, but it renders APIs incompatible with our implementation of the framework? We could find ourselves in a situation where we either can't update the framework easily, or we would need to recode many of the underlying usages of the framework in order to update. Additionally, frameworks often have many, many capabilities, many which we may not need or use. This can make our release larger than it needs to be, and/or cause our software to consume more resources than it would otherwise, if those features which we aren't using were not present. Of course, licensing concerns are also present - we have to be certain that any third party code we use is released under a license that is compatible with our commercial license. Finally, if we utilized a third party PHP framework, we would either have to (1) rewrite ALL of our code (just think of every database query that may be run - these would need to be passed through the framework rather than through our own database driver), or (2) write an abstraction layer on top of the framework to translate the requests we currently send to low-level classes so that they are compatible with the framework. No easy task, either way. By writing our own framework we ultimately have better control of our software. We can tailor every class to our needs, ensuring that it is as efficient as possible within the confines of what we wish to accomplish, while still making these classes robust enough to handle everything we want to throw at it. We can ensure we do not have unnecessary classes and code, or features which aren't (and never will be) used. If a security issue is found, we have full control over the underlying code base and can address the issue quickly without waiting on a third party to release an update, or rewriting underlying API calls in our software if the framework changes how a class must be called. If we wish to implement new functionality, we can implement these changes directly in low-level classes efficiently. We do not have to work within the third party framework's design, artificially requiring us to utilize more resources (e.g. by extending a class vs implementing our changes into the base class to start with). By writing our own framework, we face the "con" of spending the time up front to develop all of these low level classes we will need, however we feel the "pros" that this affords us in the long run are worth the time and trouble. It is a decision every developer or development company has to make as they approach a product, and everyone has different view points. The take away here, however, should be that we have indeed looked into available options, weighed the pros and cons against our goals and needs, and have determined after careful evaluation that sometimes it is best to use an existing framework, and sometimes we just need to roll our own.
-
Development is much more than just opening a text editor and writing some code. This is how most developers start, of course, and may be what an individual developer's day to day duties entail at a large corporation, however when viewing the "big picture" there are many other decisions that must be made in the course of building a software package for release that clients often don't realize were even considered. We thought you might be interested in hearing about some of those decisions that were made regarding 4.0, prior to ever writing a single line of code. Minimum Supported Versions One decision that has to be made relatively early in the development process is what dependencies will the software require. For software developed in PHP, this typically means what version of PHP will be the minimum, and (often) what will be the minimum required version of MySQL. PHP 5.3.0 was released in June of 2009, and includes functionality that we intend to utilize within the 4.0 Suite. Subsequently, this was an easy decision to make. We were leaning towards requiring MySQL 5.5, which was also released in 2009. We feel that 3 years is long enough on the web to incorporate updated software within most hosting environments. Upon investigating the functionality we intend to utilize in MySQL, however, we have determined that MySQL 5.0.3 and above includes everything we need, so MySQL 5.0.3 will be our minimum required version. Profiling and Benchmarking If you are a PHP developer and have ever attempted to profile your code, you probably realize it can be challenging. Many IDEs support some level of profiling built in, however it is almost always manually invoked. xdebug is a powerful tool for profiling, but again it requires you to enable profiling, run a request, and then view the results. In a live environment this is nearly impossible as profiling adds a lot of overhead to page loads and creates hundreds of profiling files quickly. Our goal is to be able to profile changes as they are committed, right away. We have decided to install Zend Server to the server that will host our staging environment for 4.0, which supports automatic rule-based built in profiling. This will allow us to easily profile requests automatically, even those that we may not "know" how to trigger manually (e.g. a specific task in a specific circumstance takes a long time to execute). Improving automatic deployments While automatically building and deploying the software to our staging environment itself is not a challenge per-se, a lot of times changes occur that require some sort of manual intervention to enact. We may have exported updated skin templates, language files, or there may be SQL queries that need to be run. We are developing an automatic deployment routine that can handle all of this easily and programatically, ensuring our staging environment is truly always up to date with the latest changes. Website and forum organization Not directly related to 4.0, another area we had to consider was our organization on the website and on our community here. This extend to all areas of the community, from the organization of our feedback and support forums, to our marketplace categorization, to our bug tracker categorization. The approach with 4.0 will be that we have one suite with modular applications that can be enabled. We need to market the software this way, and we need to ensure that the logical work flow for our clients reflects how our suite is designed. You will be seeing changes to categorization throughout our sites based on 4.0 in due course as a result. Loose ends And beyond all of the stuff directly related to 4.0, we felt it prudent to tackle a lot of loose ends before we jumped into a major overhaul of our entire software line up. There were a lot of smaller tasks that have been pushed off for a while but which we've finally sorted through which we feel will afford us less distractions as we work on the next release. Most of these tasks were minor, but not unimportant. Examples include: Moving our documentation to the main website Improving minor areas of IP.Downloads and IP.Nexus to allow clients to better help themselves, or to allow a smoother work flow within the administration areas our employees utilize every day Scripts on our end that allow us to better manage certain services Cleaning up old content in our installation, such as removing unused IP.Content blocks and deleting left over files on our server None of this directly affects 4.0, however the less distracted we get with minor tasks during 4.0 development, the better we can focus and deliver the product in a timely manner and with less chance of distraction-related bugs. Of course hundreds of other decisions have gone into 4.0 as well, some of which we will talk about in future blog entries. We thought you might be interested in hearing about some of the smaller things us developers do here at IPS, however, besides developing great software products to power your communities!
-
We have built public beta releases of our entire product line up for testing. Please be aware that beta releases are not supported by IPS technical support. We do not recommend running them on a live site, you may be unable to upgrade from a beta release to the final version, and our only course of support is to recommend you restore a backup of your site if you face any issues. We appreciate clients who wish to participate in beta testing programs. We would recommend cloning your live site, or installing these betas to a new test environment, in order to test the bug fixes and functionality improvements. Please report bugs in the bug tracker. As of the time of this post, our company forums are running all of these latest versions. IP.Board 3.4.3 Bug fixes IP.Blog 2.6.2Bug fixes IP.Calendar 3.3.2Bug fixes IP.Chat 1.4.3Bug fixes IP.Content 2.3.5Bug fixes IP.Downloads 2.5.3Bug fixes Multiple featured files now supported Ability for clients to manage renewals for purchased files now supported IP.Gallery 5.0.4Bug fixes Ability to create Gallery IP.Content feeds filtering on "featured" status now supported IP.Nexus 1.5.7Bug fixes Integration with the bulk mailer supported Ability to leave a customer note when voiding account added You can download beta releases for which your license gives you access to at our QA page. Thanks in advance to all who decide to test!
-
This is just a quick update to let everyone know of a small enhancement you can expect to see in the next IP.Gallery release. We recently noticed that you could not create IP.Content feed blocks to pull featured images from IP.Gallery. We felt that this was a small and easily correctable oversight, so we added a filter option when creating IP.Gallery feed blocks in IP.Content to allow you to choose whether to pull only featured images or not. You can expect to see this new option beginning with the IP.Gallery 5.0.4 release. Adding filters to IP.Content feed blocks is a generally easy process, depending upon what you are trying to filter by. Naturally, some types of filters can make the block much more complex, but with the example above of filtering by retrieving featured images, we needed only 2 language strings and 10 distinct lines of code. What types of block filters have you always felt would be easy but useful additions?
-
While we introduced some of our basic plans for 4.0 many months ago, we wanted to touch base again on some of these plans and expand upon some of our motivations behind decisions we have or will make for our upcoming 4.0 software release. Before we get too far, let me just state now that there is no expected (or even estimated) release date for 4.0 yet. While we always have internal guidelines, timeframes and milestones, we do not communicate these publicly until we are absolutely sure they are as accurate as possible. The 4.0 Suite will be a major overhaul, effectively a rewrite of most areas from the ground up, and there are many factors that can affect delivering within expected due dates. You may also have noticed the title of this blog entry uses a term for the suite you may not have seen used previously. We have decided to name the 4.0 Suite (which we will often refer to as "4.0 Suite" or "Social Suite", informally), officially as the IPS Social Suite. We feel that as we expand our line up and remove community-related dependencies, it is important that our main product release reflect the fact that our software can power more than just traditional communities. Formalities out of the way now, here are a few of our driving motivations behind 4.0... Modernize the interface The skin delivered for 3.0 and again for 3.2 was great, but several years have since passed. It is time we modernize the user interface in our software lineup once again. Features have been added, trends on the web have shifted, and technologies have advanced. Some specific points you may be interested to know: All areas of the suite will support the mobile interface. We are heavily investigating using a "response design" for 4.0. We will be switching to jQuery We will be embracing HTML 5 fully Modernize the underlying codebase While 4.0 will not technically be a "complete rewrite", most of the underlying codebase will be rewritten in some manner, and all of the code will at least be updated to work within the new framework we are developing. There is a lot to go over for those of you who may be interested in the developer side of things, and I'll point you to the right place later in this entry, but as a general outline here are some things you can expect to see:PHP 5.3 will be the minimum supported version of PHP MySQL 5.0.3 will be the minimum supported version of MySQL IP.Board will fully utilize namespaces in PHP The entire directory structure, class naming structure and more will be completely overhauled Applications will truly be self-contained within their own folders (currently javascript, skin and language files, for instance, are scattered throughout miscellaneous directories) The entire code base will be modernized. More use of formal design patterns will be employed, where appropriate. Dumping ground classes (such as IPSLib) will be avoided at all costs. More consistency between how applications implement functionality will be seen. Naming conventions will be more consistent. The way hooks work will be completely rewritten, making things simpler for us and for developers, and making hook usage behind the scenes more reliable (no more loadLibrary calls - everything is handled automatically by the framework instead). Make things more consistent We are also working towards making all of our applications more consistent. The approach to this actually has much more to do with planning and how we approach new functionality than it does any specific technical aspect of software development. In a nutshell, we will have one "suite" release moving forward starting at 4.0. Every application will be on the same versioning system and share the same version number, and every release will include every application (although you will only have access to the applications you have purchased, of course). What we will do as we implement new features is implement new functionality suite-wide from the start. If we were to add a new feature to 4.0, we would not add the functionality to the forums and then roll this change out to other applications as they see updates. Instead, we will be implementing changes suite-wide from the start, which has several benefits:From a user standpoint, the software will be more consistent. You won't have situations where a feature is available in Application X but not in Application Y. From a technological standpoint, we will be forced to implement functionality in an optimal manner where it can be utilized by all areas of the suite. There will be less application-dependencies for features that are intended to be suite-wide. There will be much, much less duplicated code as features will be designed from the start to work in multiple areas. Point #2 above will also benefit modders - APIs will be much more robust, yet more generic and reusable, for features implemented suite-wide rather than features implemented for one application and then shared across others. Beyond changing our approach to functional changes in the software itself, we will also be focusing on consistency while redesigning the interface, and throughout every facet of development of 4.0. Want to hear more specifics? We have recently launched our new development blog where we will routinely be posting about the nitty-gritty of our day to day development duties here at IPS. While this blog is not at all intended to be specific to the development of 4.0, you will find us posting about upcoming changes and decisions made in 4.0 quite regularly. We welcome you to follow The Development Channel blog if you are interested in reading about these changes. If not, don't worry - any major announcements will be blogged about here in our company blog as well in due course. If you aren't sure, just to be clear....development of 4.0 is definitely underway. A lot of planning and discussion took place prior to ever writing a single line of code for 4.0, however we are definitely working on 4.0 now and you will likely see blog entries about upcoming changes before long. Stay tuned!
-
Through use of our own marketplace, we often identify small but useful changes to IP.Downloads that benefit sites that both use IP.Downloads to allow distribution of free files as well as those that sell files through a marketplace. While working to improve the user interface of the home page in IP.Downloads, we decided that allowing multiple featured files would be a small change but would help improve the interaction and discoverability of useful content in the marketplace. After all, every other marketplace has more than one file featured, right? IP.Downloads 2.5.3 will now allow you to feature more than one file. Up to 20 of the most recent files that are marked as featured will display on the homepage in a carousel-style panel. The act of featuring a file has not changed (the only thing that has changed here is that other files which are featured are no longer automatically unfeatured). Only the homepage interface has really changed. Here is a short video to show you what it looks like with two featured files. Note that if you only have one featured file, it will display as it does now in IP.Downloads 2.5.2. http://screencast.com/t/A0KX6uWs You will note that you can manually cycle through featured files, or they will cycle automatically. If you mouse over the featured file panel, the automatic cycling pauses. We hope you find this small change useful, and more consistent with other applications that allow featuring (such as IP.Blog, where you can feature more than one entry, and IP.Gallery, where you can feature more than one image). Let us know what you think in the comments below!
-
We identified a use case recently where we wanted to send a bulk mail to all clients who had purchased a particular package in IP.Nexus. This is not uncommon. Perhaps the package is being discontinued. Perhaps you erroneously over charged for this package. Perhaps there will be a special on additional purchases of this package. Regardless of the reason, it is logical and ordinary that you want to email all clients who have purchased a given package. Because the bulk mailer was improved in 3.4 and now supports per-application extensions, we have written one for IP.Nexus 1.5.7 that allows you to control with the bulk mailer certain ways to filter members based on packages they have purchased. The way this works is very simple. When you go to send a new bulk mail, there is now an IP.Nexus tab in the filters area allowing you to filter by IP.Nexus purchases. You can also control whether you send to only active purchases, expired purchases, cancelled purchases, or any combination there-of. Here is a screenshot to show you what it looks like on our site: I'm sure you can see just how valuable this small but useful change will be. This enhancement will be available with the release of IP.Nexus 1.5.7. What other types of filters have you wanted to bulk mail members utilizing, but can't presently?
-
Our marketplace is an area where developers can submit free and paid resources for other clients to download and use on their website. IPS processes many, many transactions through the marketplace, both one-off purchases and renewals for applications clients have previously purchased. When an application has renewals, however, it was pointed out that the client had no way to cancel those renewals. Perhaps the client is no longer using the resource they purchased, for instance, and does not wish to renew the purchase any longer. With our product releases in the client area you can easily opt not to renew purchases if you want, however there has been no way to do this in the marketplace...until now. With the release of IP.Downloads 2.5.3 (and available in the marketplace now), instead of a button that reads "Buy another", the button has been relabeled to "Manage Purchases". When you click this button on a file you have purchased, you will still have the option to purchase more licenses, however you will also have the ability to manage your existing purchases, includingCanceling a purchase that is active Reactivating a previously canceled purchase Renewing a purchase that has expired Additionally, we enhanced IP.Downloads so that when an author changes a paid file with renewals to free that it clears out the renewal terms for any clients who have purchased the file. If the file is no longer paid and no longer has renewals, existing purchases should not still renew, after all. And finally, if the file name is changed, previous purchases that are displayed in a user's client area will now reflect the updated file name, for clarity. These small enhancements will make clients better able to manage their purchases, save our customer service representatives time by not requiring them to cancel purchases for clients, and provide an all around more robust and complete experience for users. (Please be aware that this is an early screenshot of a feature to be included in the next release of IP.Downloads, and subsequently the interface and display is subject to change)
-
Hello everyone! Us developers are a strange bunch. We have a lot of crazy thoughts that just don't make sense to anyone else. Our brains are wired different. We get from point A to point B by going around point Z and bouncing off point M first. And very few of us (*cough*me exempted*cough*) are able to type up posts that make sense to more than just other developers. So what are we to do? Keep all of our great thoughts to ourselves? Nonsense. Nevertheless, we cannot flood everyone with the semi-(in)sane ramblings that go on in our heads every day, nor can we bore everyone with discussions of how great our new class structure will be, or how useful the new methods we've just added to x class will turn out. Introducing The Development Channel This blog will be a place us developers can write up our thoughts and discuss developer-specific topics. Anyone can follow this blog if they want to. We're not out to have a private exclusive group that only the elite development community can join. Quite the contrary - if you are interested in the sorts of things us developers do on a regular basis or are interested in the future and development of the software, please feel free to follow this blog. We will be talking about new features, minor tweaks and other changes to existing features, code-level improvements (such as class structure, class inheritance, and so on) and even things not related to the software (think: how we do x on our website, or why we chose to approach a problem in a specific way). If any of this is your cup of tea, we hope you enjoy the blog entries to follow. If this is all Greek to you (and you don't speak Greek), then by all means - ignore us. You are certainly free to continue following our official News forum and our official Company Blog, where all the important stuff will get posted. If you're still here, we hope you enjoy what we have in store. :)
-
We have added a minor enhancement to IP.Nexus 1.5.7 that we thought you might be interested to hear about. Our customer service representatives found that when they "voided" an account in IP.Nexus (by clicking the "Void Account" button when viewing the customer screen in the ACP) that they often wanted to leave a customer note at the same time, explaining why the account was voided. For years they simply added the customer note manually after they voided the account. This isn't a big deal, but we identified a way to improve their workflow in this instance. With the release of IP.Nexus, a textarea box has been added to the "Void Account" page (as long as you have permission to leave customer notes), allowing you to leave a customer note at the same time you void the account. This small change will save our customer service representatives time and effort while they perform their daily routines, and took us less than half an hour to do! Have you found any small changes like the one identified above that would save you time and effort? Sometimes moving a button around or adding an extra form field can make all the difference!
-
Updating Fixed In to: 5.0.4 Updating Status to: Fixed -
-
Updating Status to: Cannot Reproduce I can reproduce here, but not locally. It looks like it's already fixed locally, so let's just double check once this site is updated to 5.0.4.
-
Updating Fixed In to: 5.0.4 Updating Status to: Fixed -
-
Updating Fixed In to: 5.0.4 Updating Status to: Fixed Hmm, I can't reproduce any issues now. I have 200x200 thumbnails set and the thumbnail image is 200x200, but because of the parse tag in Gallery it forces the width/height to 100x100, so it doesn't expand. Working with Ryan to find the breakdown.
-
Updating Fixed In to: 5.0.4 Updating Status to: Fixed Updating Version to: 5.0.3 -
-
Updating Status to: Cannot Reproduce -
-
(Basically what is happening is the event SAVES correctly as you input, however because YOU are in GMT and not GMT-5, it is converting the event's time when you view it based on YOUR time. That way if I'm in GMT and save an event, and you are in GMT-5 and view it, the time is correct for both of us)
-
Updating Status to: Cannot Reproduce This is happening because your user profile time zone is set to GMT, so it is converting the time based on YOUR time (I'm assuming this is the case without logging in as you on your test board). I cannot reproduce locally, where my time is set to GMT-5 in my profile.
-
This is a relatively minor bug with an easy work around for now. We are currently focusing our attention on other products but will get to this report in due course. If there were not a work around, I would recommend submitting a ticket for assistance, however you've already sorted out the issue on your own install.
-
Updating Status to: Duplicate http://community.invisionpower.com/resources/bugs.html/_/ip-downloads/mobile-skin-r39480 I just updated it to fixed as I had actually updated the templates locally already.
-
Rimi - this was sorted at one point (we forced the size down using the same resize plugin used elsewhere throughout Gallery). Will have to double check on when/how it got lost or why it is not working now.
