celfred

Members
  • Content count

    108
  • Joined

  • Last visited

Community Reputation

51 Excellent

About celfred

  • Rank
    Sr. Member

Profile Information

  • Gender
    Male
  • Location
    France

Recent Profile Visitors

3,420 profile views
  1. Another nice 'lesson' from this community. Thank you very much @Robin S.
  2. Hello, Still in my 'teaching game'. Here's my problem : I 'find' all players with a request like $allPlayers = $pages->find("template=player"); [/code Then, I limit to players belonging to the team of the logged in player with [code] $teamPlayers = $allPlayers->find("team=$loggedPlayer->team"); No problem so far. But my scoreboards rely on either : $allPlayers->getItemKey($loggedPlayer); or $teamPlayers->getItemKey($loggedPlayer); to find the logged player's position in the charts. On the 'global' newboard with scoreboards based upon $allPlayers, everything works as expected. BUT on my 'team' newsboard, even though I'm using $teamPlayers, the returned indexes are based upon $allPlayers. Am I clear ? In other words, I have a total of 125 players, and my logged player is 61 out of 125 regarding the number of places he freed. But in his particular team of 25 players, he sould be 15 whereas he's still 61 I'd like to reset my indexes (and start back from 0), but I can't find my way out of this... If someone has a hint to help, I'd appreciate. I have a second part in my worry : I had a way around it by simply making another 'raw' request : $teamPlayers = $pages->find("team=$loggedPlayer->team"); Then my team indexes were right, but I faced another issue : Reordering my wirearray according to the scoreboard I want usually worked fine (simple sort() based upon an integer field, for example, player's coins, player's karma...) and indexes were updated BUT resorting with places.count ('places' field is a pageArray) doesn't update the indexes returned by getItemKey and my logged player is always at the position he was when I first did my initial $pages->find() query So my way around found its limit and that's why I'm posting here, after struggling with this for a couple of hours... Thanks in advance for the help.
  3. It is an integer and I've checked the setting and intentionally set it to 'Yes' because my freeActs field had no value in some pages and I wanted those pages to be returned. In short, a player being level 1 with no previous activity should have access to items having level 1 set, enough Gold Coins (GC) and 0 previous 'free' actions... I guess I'm not clearly understanding this yet. I'll go ahead and try to check 'No' and see what's going on, but later during the day. Thanks for your help @Robin S
  4. Hello to all, This time, I'm stuck on an issue with a 'find' request. I have found a turnaround, but I have no idea what's going on, really, and I wish I could understand. My code is the following : $nbEl = $player->places->count(); $items = $pages->find("template=place|item|equipment, GC<=$player->GC, level<=$player->level, freeActs<=$nbEl")->sort("template, name"); If I explain briefly : the $items should contain the possible elements for a player according to his level and GC (gold coins), and freeActs, i.e. the number of already 'bought' places. If the 1st line $nbEl returns a number higher than 0, it 'works', I get some items. BUT if the player has not bought any place yet and then $nbEl = 0, $items is... empty whereas it should contain all elements being accessible with a 0 'freeAct' field (and there are many). I have tried to hard-code 'freeActs<=0', I get no items. 'freeActs<=1', I get some nice results' AND THEN, 'freeActs=0' and it works as expected So here's my 'workaround' : $nbEl = $player->places->count()+1; $items = $pages->find("template=place|item|equipment, GC<=$player->GC, level<=$player->level, freeActs<$nbEl")->sort("template, name"); Note the 'freeActs<$nbEl' instead of 'freeActs<=$nbEl' and the '+1' for $nbEl so not to start at 0... Then, it works as expected !?!? Does someone have an explanation for this ? Thanks in advance if you do. And don't hesitate asking me for more details/explanations if you need.
  5. @kongondo Sorry for being late on that... Thanks for your reply. Somehow, your answer is comforting since things should work the way I was understanding them. Now I'll try and find out what's going on in my code. Good point about my wrong variable name. I wasn't even aware of that... Shame on me...
  6. Thanks. But is that new in some way ? Or was it always like that but I didn't notice ? Just making sure I'm being understood : the equipment is added to the player's page, BUT it stays in the equipment list even though I reload the page and empty the cache. I thought it wouldn't stay since I didn't save the page.
  7. Hello, Just a simple (I think) question which is in the title of my post. Roughly speaking : here's my code (made-up because my real function is so long... I don't want to post it all here ) function updateScore($player, $task, $real = true) { [...] $player->score = $player->score+$task->score; if ($task->name == 'new-equipment') { $new-eq = $pages->get("name=sword"); $player->equipment->add($new-eq); } if ($real == true) { $player->save(); } } Everything works fine when I call updateScore($player, $task, true), but if I call updateScore($player, $task, false), scores are untouched, but the equipment gets added ! It used to work fine on PW2.7 but my update to PW 3.0.62 seems to have broken this... Is there a simple explanation ? I keep reading my code over and over and this is driving me crazy... Thanks !
  8. Here's what I think : I had an 'old' processwire directory which I downloaded through Git and which I thought was up-to-date with master (not dev branch) so I really imagined I was with 3.0.62. (I'm sure I did a git pull but I guess not...) And today I added PW version in my footer and saw 3.0.36 and imagined I forgot about the version number _ must have been 3.0.32 and they've already made some changes and now it's 3.0.36... Anyway, you see how good I am with Git and some stuff So I'm really sorry about all these issues which shouldn't have happened if I had done things correctly. I'll update for real (!) and see how it goes. Thanks again for your help and time. I appreciated a lot ! And about my Tracy 'theme' : I just use my computer 'negative' mode because I have eyesight problems and I feel better this way. So no leaking, don't worry EDIT : 3.0.62 installed : I can confirm, there is no more a bug with the 2 forms of 'find' statements.
  9. I PMed you the files so as not to 'pollute' this post with unnecessary lines. Edit : I added my Tracy console.
  10. It returns 'NULL'. How does that sound ?
  11. Well, I've checked my localhost version and it gives 5.7.19. Anyway, I've changed my line taking the 'sort' out of my 'find' string and it works (actually, I believe my 'sort' command is not really useful on my page any longer so it's not really an issue for me any longer). I've taken care of most of my errors (I think) and it seems to work fine. I went ahead and made the changes on my live site. It looks ok. I'll test tomorrow when actually saving data 'for real', but on my localhost it works, so that's cool ! I'm running on PW 3.0.36 now Thanks a lot for your help ! If anything still matters to you and you suspect a weird behavior on PW side and you want to dig this a little, don't hesitate asking me for further testing or information.
  12. Hello, I'm back to it and it's not easy 203 PDO queries in my Tracydebugger ! That sounds like a lot to me... I have tried to isolate the 'responsible' one and here it is (I think) : SELECT pages.id,pages.parent_id,pages.templates_id FROM `pages` JOIN field_team AS field_team ON field_team.pages_id=pages.id AND ((((field_team.data='85366') ) )) LEFT JOIN field_group AS _sort_group ON _sort_group.pages_id=pages.id LEFT JOIN pages AS _sort_page_group_name ON _sort_group.data=_sort_page_group_name.id WHERE (pages.templates_id=43) AND (pages.status<1024) GROUP BY pages.id ORDER BY _sort_page_group_name.name This corresponds to the following statement : $allPlayers = $pages->find("template=player, team=$team, sort=group"); Answering your question : the 'group' field is indeed a 'Page' type. It used to be a 'Text' type so I tried and changed my find query replacing 'sort=group' by 'sort=group.name' and the error is still there. Here's the resulting PDO query in Tracydebugger : SELECT pages.id,pages.parent_id,pages.templates_id FROM `pages` JOIN field_team AS field_team ON field_team.pages_id=pages.id AND ((((field_team.data='85366') ) )) LEFT JOIN field_group AS _sort_group_name ON _sort_group_name.pages_id=pages.id LEFT JOIN pages AS _sort_page_group_name ON _sort_group_name.data=_sort_page_group_name.id WHERE (pages.templates_id=43) AND (pages.status<1024) GROUP BY pages.id ORDER BY _sort_page_group_name.name As I said earlier, if I change the syntax to : $allPlayers = $pages->find("template=player, team=$team")->sort("group.name"); The PDO query shows : SELECT pages.id,pages.parent_id,pages.templates_id FROM `pages` JOIN field_team AS field_team ON field_team.pages_id=pages.id AND ((((field_team.data='85366') ) )) WHERE (pages.templates_id=43) AND (pages.status<1024) GROUP BY pages.id and everything works as expected. I've tried my best to be helpful. I hope I've managed to isolate the correct lines and that you can understand something out of it. (and that I'm not responsible for taking this time from you... by responsible, I mean that I did something wrong that caused the problem, which can be a possibility) Sidenote : Trying to isolate the query, I took almost everything out of my page (no more find/get statement except that one, no more head.inc, foot.inc....) and I still have either 41 or 38 (depending on reload) PDO queries on my page). I would imagine that's PW 'doing his job'. Is that so ?
  13. I have the TracyDebugger installed and I'll try to do what you're asking me with pleasure, but I have to stop right now (time to eat at home, daughters hungry... ) I'll do that tomorrow and keep you updated about my progress. And I agree with your advice about installing modules directly from within ProcessWire. It is indeed quite simple
  14. Last thing for the moment while trying to update to PW 3.x : in backend, my modulemanager page tries to read a modulemanager.cache file in files/assets/cache which doesn't exist hence error messages : Warning: fread(): Length parameter must be greater than 0 in /home/celfred/PlanetAlert/site/modules/ModulesManager/ModulesManager.module on line 812 ProcessWire: ModulesManager: cannot read cache file /home/celfred/PlanetAlert/site/assets/cache/ModuleManager.cache (with debug true)
  15. Here's what I did : Restarted mysql to be back with the initial fatal error. Found out that commenting out the line : $allPlayers = $pages->find("template=player, team=$team, sort=group"); got rid of the error Replaced the line with : $allPlayers = $pages->find("template=player, team=$team")->sort("group"); and... It works That's indeed a cleaner solution better than changing my mysql settings. I guess the 'bug' was on my side with the 'sort' command included in my 'find' query. I have to revise the PW doc to see where I saw that syntax or if I made it up without noticing that it never worked (which is possible !). So thanks for pointing this out to me !