IPS Management
  • Content count

  • Joined

  • Last visited

About Charles

  • Rank
    Frequent Contributor

Contact Methods

IPS Marketplace

  • Resources Contributor
    Total file submissions: 1

Profile Information

  • Gender
  • Location
    Lynchburg, Virginia

Recent Profile Visitors

176,710 profile views
  1. I'm the nice one.
  2. The warning system can be set so the user cannot post until they acknowledge the note from the moderator. If you view the guide I linked to you can learn about all the features of the warning system.
  3. If you feel something is broken you should submit a bug report or a ticket In this case we have already submitted a fix for polls in 4.1.14 as a client submitted a ticket about polls a couple weeks ago.
  4. Was it a generic "could not connect" error or did it say request blocked?
  5. There's no way to pause it but the queue task has built in logic to handle such a situation. When it executes it may only do 100 posts per cycle but it keeps looping those cycles doing as many as it can for a set period of time. If your server is not too busy and powerful then it will do many loops before it stops that cycle. If your server is busy then it may only do a few loops before it runs out of time. Either way, after a period it will always stop, exit, and then re-execute on the next batch run. We do it this way so the queue does not take over your entire server in a mad rush to process tasks
  6. The majority of replies indicated people were not interested.
  7. As always, we only support live sites. We cannot support test installs.
  8. If anyone is having issues feel free to submit a support ticket. We are happy to assist. As far as I know, @Prank is the only person in this topic who has submitted a ticket recently and we were able to resolve the issue. If you had submitted a ticket in the past and are still experiencing an issue you can always start a new ticket as a follow up.
  9. Someone here finally submitted a ticket on their issue and as I posted we sorted out the problem. It turned out there was nothing wrong other than the client trying to do two things at once which caused the whole process to slow to a crawl. So I might suggest that you simply ask for our assistance in looking at what is going on. Posting long posts here do not solve problems but short support tickets do

    This is a maintenance release that only contains the following changes: Database checker can sometimes cause database issues with incorrect index length Performance update for Activity Streams Performance update for sidebar widgets/blocks This release also contains a security update specifically for those using IPS Connect that is regarding password hash comparison. If you use the IPS Connect system please update without delay.
  11. In order of speed. Cron -> Run Manually -> Site Traffic When I upgrade a large site from 3 to 4 I usually put the cron up for a day or two until it's all done with queues then switch back to site traffic. I do that because I don't want to keep up with hundreds of cron running If you are curious, the "Run Manually in Browser" mode is slower because it has to refresh to go to next loop whereas cron just does it internally and it has to deal with memory limits that the cron, being at command line, doesn’t have to worry as much about. Of course day to day operations do not have the huge volume that a 3 -> 4 upgrade has to contend with so switching to Site Traffic is just fine after it's all done.
  12. I replied in your ticket but for everyone's info: Do not run the queue tasks both in the browser (using the manually run now link) and via the cron at the same time. The queue task locks when it is running (so only one thing has control at a time) and, when you do both the cron and the browser, only the browser task will execute and it is much slower than the cron task. When you do both of them the cron is useless and does nothing because the browser keeps the queue task always locked. The cron will execute, see the browser has the queue locked, and instantly exit therefore doing nothing. Looping via the browser is much, much slower than letting the cron take care of it. I think trying to do both at the same time is the root of your slow rebuilds. The cron system has logic in it where it will run at least 45 seconds per execution. There is no need to edit anything in the system, write fancy looping scripts, change the number of posts it does per loop, and so on because it will just keep looping as long as it can with in that 45 second limit. It will then continue on the next execution. I personally upgrade large sites quite often and I know from experience the cron can process well over a million posts per day without any special interaction. Just set the cron and forget it if anything goes wrong you will see a notice at the top of the AdminCP dashboard saying there is something wrong with the queue. If that is the case let us know and we will of course help you.

    This is a maintenance update and includes only the following changes: Uninstalling an application can create errors Commerce custom fields may not work Calendar repeating events can loop indefinitely Query performance improvement on fetching topics
  14. Posting a comment on a news article is not the best way to get help feel free to submit a support ticket and we would be happy to assist you.