Jump to content


Jason P.

  • Content Count

  • Joined

  • Last visited

About Jason P.

  • Rank
    New Member

Recent Profile Visitors

2,005 profile views
  1. why would anyone just willynilly upgrade without running a test suite and allowing user feedback on it first? My users hate that we lost themes they loved (we're working on it), my staff hates that some of our addons ceased to function properly (we're working on it). These two issues ensured our main site is still 3.4.x (which is STILL supported) while we continue testing and resolving issues. This gave me 1) happy users 2) happy staff 3) the ability to actively show the community what is going on in the test/dev ipb4 environment we have. You really can't blame anyone but yourself for unhappy users. Always test major releases first (this is a life lesson, not only applicable to IPB) if you do run things in a test/dev environment provide feedback! perhaps some of the things you hate, love, or dont care about will be changed or modified based on your feedback. IPB4 is still getting updated fairly frequently (and for the better, IMO)
  2. I, too, liked the Feature Plan section. I referenced it for my community pretty regularly to show progress and why it's such a big deal to us. While I also look at the release notes section, will we see something calling out "landmarks" as features are completed at release points?
  3. Increased to 200M and still getting 32 exceeded. Do you think this is related to why the previously cached steam profiles are no longer showing on the forums? Or does it always clear the template cache on upgrade.
  4. That is disabled on my end. I lowered the users to fetch even more as well. The thing that is peculiar is that the error shows this: tried to allocate 32 bytes Which is clearly less than the maximum O_O.
  5. Updated from 1.0.4 to 1.1.0 by uploading files and installing hook. It seems all cached steam profile data for users has been removed. I went and tried to manually run the scheduler task and was redirected to just a blank page. Nothing in SQL error logs, but I found this error: 2014/02/12 15:46:01 [error] 22038#0: *2993093 FastCGI sent in stderr: "PHP message: PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 32 bytes) in /srv/joinsg/www/htdocs/ips_kernel/classDbMysqliClient.php on line 471" while reading response header from upstream, client: , server: www.joinsg.net, request: "GET /admin/index.php?adsess=7bd308c9ea92bb757ca50bae84e7fb85&app=core&module=system&section=taskmanager&do=task_run_now&task_id=55&tab=members HTTP/1.1", upstream: "fastcgi://", host: "www.joinsg.net", referrer: "http://www.joinsg.net/admin/index.php?adsess=7bd308c9ea92bb757ca50bae84e7fb85&app=core&module=system&section=taskmanager&do=task_unlock&task_id=55&tab=members" Any ideas? It worked fine on the previous version. I even tried lowering the number of users to update at once to 15 and still get the same thing.
  6. I've been getting this error after upgrading to 1.0.4. The fix about line 141 above didn't work (just gave me an error about no tables found m.). But what I think DID work was adding a space before AND as below (line 143): The space between " and AND seems to fix the MySQL syntax when running. The task works now when manually running, but I will have to wait and see if it does update steam profiles or not. Will report back. Edit: Yep, everything seems to be updating just fine now.
  7. Also, I hope you don't mind, but I just tweaked the MySQL query in the task file to only select for users that have visited the forums in the past 3 days. We have 400+ people with SteamIDs connected to their account and by doing this it limits the update to only ~50-60 a run. Takes around 10-15 minutes each, however. Increased the duration between tasks to 20 minutes.
  8. Ah ok I see! Darn Steam. Thank you for your response, I hope you get feeling better soon!
  9. Just installed the plugin for our community as well. Running into time-out issues. Luckily we host ourselves, so I can change some PHP vars around. Would be nice to be able to run the scheduler in batches though. Will probably have ~100 users with steam profiles at first. Running into 504 Gateway timeouts though. Tried to increase timeout variables, but no avail. Receive timeout error after 60 seconds. 2013/12/14 09:40:46 [error] 24107#0: *10777489 upstream timed out (110: Connection timed out) while reading response header from upstream, client: XX.XX.XX.XX, server: www.joinsg.net, request: "GET /admin/index.php?adsess=4fadf530686c710fb4634ac9b3c16b11&app=core&module=system&section=taskmanager&do=task_run_now&task_id=55&tab=members HTTP/1.1", upstream: "fastcgi://", host: "www.joinsg.net", referrer: "http://www.joinsg.net/admin/index.php?adsess=4fadf530686c710fb4634ac9b3c16b11&app=core&module=system&section=taskmanager&do=task_unlock&task_id=55&tab=members" Have set the following nginx variables too: fastcgi_send_timeout 300 fastcgi_read_timeout 300 client_header_timeout 300 client_body_timeout 300 send_timeout 300 My PHP.ini has max_execution_time set to 300 as well. Still times out after 60 seconds.. Would really love to get this hook working, it looks awesome! EDIT: Well stupid me forgot to put ';' characters at the end of the nginx vars. Doesn't time out at 60 seconds anymore. I believe it was the fastcgi_read_timeout var that was causing the issue. DOUBLE EDIT: This is taking way too long to run the scheduled task to be useful. It seems like it is running SQL queries for every single user on the forums rather than just pulling those that have a steamid from the Steam Login plugin. Could it just be set up to have a query that first selects members that actually have a steam id (meaning they used steam login to connect to the forums), then do the steam profile data parsing stuff? I would really love to use this feature on our forums, but in its current state it is cannot work.
  • Create New...