Ryan Ashbrook

If you are using Amazon S3, then we simply redirect to a signed URL and allow S3 to do what it needs to do. In other cases, however, we use HTTP ranges to serve the file in parts until it has finished downloading. We do this because if the download fails, it can then be restarted from the point of failure, rather than downloading the entire file again. Whether or not multiple connections are established to download multiple parts at the same time, would be something the browser / downloading client does, not our software.

The AdminCP upgrader can actually handle those. For instance, if you were going from 4.6.0 to 4.6.1, then it would not likely kick you to the full upgrader because the only changes between those versions were code changes, theme changes, and JavaScript changes.

Actually, there's quite a bit more to it than that. 🙂 There are some specific circumstances where even if you go from, for example, 1.2.3 to 1.2.4, then it can all be done within the AdminCP. If there are more significant changes, however, then it will send you to the full upgrader.

Does this mod perform the updates all at once, a multiple redirect, or does it use background tasks? Ideally, you should contact the author and ask if they can change the process - CiC has a hard limit on the number of requests per minute, as well as a hard timeout on the length of a request. Ideally, anything that performs a mass-update should use the background task system to avoid issues such as blocked requests or timeouts.

Yes, in this case, you (or anyone specified under the Purchase Notifications setting for the package) would receive an email for every purchase generated of that particular package. These emails are unique to the actual purchase itself, even if purchased alongside other purchases of the same package type. These emails, however, do not go out to the user - they would receive the standard invoice paid notifications, which will have grouped them all together (since those emails are unique to the invoice that was generated, not the purchases themselves).

$count = \IPS\Db::i()->select( 'count(*)', 'forums_posts' )->first(); print $count;

Yes, everything on our site is done using Pages.

This is indeed a bug - it has been fixed in the latest release, so I recommend upgrading and revert / re-apply any changes that have been made to the mobileNavigation template (if any changes have been made).

This line is likely the problem: RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /index\.(php|html) [NC] Try this instead (note I have not tested): RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /index\.(php|html)$ [NC]

Right now, this is actually working as designed - and it's a bit complicated. When a renewal invoice is generated, we go through all cards the customer has on file in order to attempt to take payment. When we do this we generate individual transactions for each attempt, until one succeeds, which handles everything from capturing the payment, checking fraud rules, calling the gateway, getting back information from the gateway, and then either marking the transaction as approved (and in this case the invoice as well), declined, or marked for manual review. This also includes sending out the individual notifications for when any of those events occur for the individual transaction. So then, the problem becomes determining what notifications to send, and when, since the system automatically determines the appropriate one to send, based on its status. Further, the notifications are centralized and are used for all transactions, including the customer checking out, renewing manually, the administrator manually charging the card, or automatic payment taken so we would need to rework all of those flows as well. So while it seems simple on the surface (and ideal - I agree, though one could argue that it could act as a reminder to the customer that they have an invalid card on file that they should probably update or remove), it's actually a larger change that we will likely have to make in a larger update rather than as a simple bug fix. In most cases, customers will only ever have one card on file, so typically it's a non-issue (either it works or it doesn't and only one resulting transaction is generated).

Unfortunately, not at this time. We are investigating a short term temporary fix, and a longer term more permanent fix, however I do not have anything to report at this time, I'm afraid.

The block is based on the download logs as configured for your categories. So, if you've recently changed these to retain downloads indefinitely, then this would not be applied retroactively. So, for instance, if all of your categories previously only retained 7 days worth of download logs, and then those were updated to keep download logs forever, then the previous logs would not be applied because they have already been removed. Looking on your site there, the Download Log for your most downloaded file only has 11 pages, totaling 103 downloads, though the file itself has seen itself been downloaded over 17,000 times. So what happened here, is those logs were likely pruned.

I took a look at the logs, and this was indeed a temporary issue while we are working on a few things. It should be fine now.

Logout URL's are not actually supported by the software, currently. Currently, the correct behavior is that logging out from the community will only log you out of the community, and not the provider. This would likely be something third party, so you would need to consult the developer of that add-on.

I can confirm on my own site, that if I set my locale to match yours, then the date is formatted correctly: The formatting of the date will always be controlled by the locales installed on the server, and not by the software itself. If you upload this test script and run it in your browser, does it show correctly, or the same as the community does? If it is incorrect, then that means the pl-PL locale on the server is configured incorrectly. datetime.php If it does show correctly, however, let us know and we can look on your community specifically. The format of the date in this script does not take any community settings into account.

I believe this issue is related to the amount of categories you have. I have identified where the problem is, and have submitted a fix for a future version.

Yes, the fix is included in this release but because the files are not present on your site yet, you will see the same issue going from Beta 2 to final.

I've fixed this issue for the next release - for now, you can proceed with the manual download (the download button will provide only the changed files - not the full suite download).

I'm looking into this.

I refreshed your license data - in your Admin CP, go to License Key and click "Refresh License Data" and that should update everything.

Click this button: Then on the next page most operating systems / browsers should allow you to export the page as a PDF. On Mac / Safari, you can just go to File > Export as PDF. Some others may have the option behind the Print dialog.

Commerce says it is currently offline (see the text under the application name). Click the Enabled badge, and toggle it's offline status to On.

ACP > Applications. Two things to check: Make sure the application itself is online and available. Click the arrow to expand the moldules list, and make sure the Support module is enabled and groups have permission to access.

It just means that you have a theme installed that has at least one customization made to it, which would be referring to the Bravo 6 theme that is listed there, from the Marketplace. If you remove that theme, that message will go away.

Do you have the appropriate htaccess files in both directories? You should make sure you download the .htaccess file from your ACP > System > Search Engine Optimization > Rewrite URL's - you can download the file from the description. Once you download that make sure place it in your forum directory, and not in the root of the site (that should still contain your .htaccess file from WordPress).