Jump to content

ErikMH

Members
  • Posts

    51
  • Joined

  • Last visited

Everything posted by ErikMH

  1. @teppo, it looks like this is precisely the module I was going to begin searching for on Monday. I’m wildly excited that you’re doing this, though I understand your warnings and cautions. My fingers are crossed!
  2. Fantastic little module, and I especially like the “magic” that happens when certain interpolated punctuation marks (“,”, “|”) are used between concatenated strings and one of the concatenated strings is blank: they’re left out! 🙂 Would it be simple to add an ellipsis (“…”) to the list of characters so treated? My use case involves long paragraphs where I keep track of opening- and closing-words separately (in text fields), but I’d like to be able to represent the whole paragraph with Starting words … concluding words. Occasionally, there’s a very short paragraph, and I don’t want to imply that something has been left out (which an ellipsis, of course, does) — and in those unusual cases I include all of the text in the “starting words” field, leaving the “ending words” field empty. But (unlike with , and with |) the ellipsis shows up regardless.
  3. You just saved my bacon, @Robin S — thanks for this! For those searching, this is the secret sauce for presenting a subset of entries to select from, based on a previous selection. In my case: parent=page.refSection where refSection is a grosser-level selection in a hierarchy. I believe this also answers this question:
  4. Well, but that can’t be right. You posted this, with findMany() working just fine yesterday: So it looks like there’s something about getPage() (implicit or explicit), first(), and presumably last(), in combination with findMany(). I think.
  5. Excellent thought. I haven’t done this before, so hopefully I’ve got the details right: findMany() combined with getPage() gives pages whose parents are (incorrectly) NullPage
  6. OK, guys, it seems there was one more piece to the puzzle. Like @adrian, when I recreated the situation in a simple test environment running 3.0.192, I couldn’t recreate the problem. I should have tested this yesterday, but where I’d discovered that changing findMany() to find() in my code worked around the problem, I figured I’d found it. So, the following conditions are necessary but insufficient: PW 3.0.192 or greater (including the current version) page classes findMany() instead of find() I believe I’ve found the final ingredient. I have tested this in a simplified environment and recreated the problem: 4. getPage() In real life, I’ve rolled my own pagination (since I’d wanted to provide users with logarithmic-like controls for moving backwards and forwards through the site, and provide them with sign-post dates); this paginating has worked well. But it means that rather than a foreach loop I cycle through results in a for loop, and then assign the item with a getPage(). So, Adrian’s code looked like: foreach($pages->findMany('template-basic-page') as $p) { d($p->id . ' : ' . $p->returnParentId()); } but mine looks more like: $items = $pages->findMany('template=Test'); for ($idx = 0; $idx < 1; $idx++): $p = $items->getPage($idx); echo ($p->identify()); endfor; (Yes, that’s my test system, where I’ve hard-coded it to “loop” through just one test record; it’s sufficient to show the problem though: ProcessWire\TestPage #279 id: 1025 name: 'test-record-a' parent: '' template: 'Test' title: 'Test record A' data: array (1) 'title' => 'Test record A' parent there should = '1'. I see that I can do the same thing by removing getPage() altogether: $p = $items($idx); In the grand scheme of things, I don’t know which is better; however, this assignation — whether implicit or via getPage(), seems to be the final piece: add this, and $this->parent() becomes a NullPage. So, to sum up: all of this works fine in 3.0.150-or-so (where I developed it) on up through 3.0.191. As of .192, it breaks. Switching from findMany() to find() works around the problem. Sticking with findMany() and using the customary foreach() code pattern also works around the problem. Phew! @kongondo, I agree that the commit you link to looks relevant. Do you think the (implicit or explicit) getPage() may call any of that code?
  7. This is good to know about, @adrian — thanks for drawing my attention to it! No, though, 3.0.195 behaves just like everything else for me beginning with 3.0.192. If I use findMany(), I have the problem as outlined above; if I use find(), everything’s fine.
  8. Thank you, @adrian, for that pointer. I’d had no idea that JS hadn’t been running. I’ll look into your example soon! But the big news is that I’ve solved the problem! @ryan, @bernhard, & @kongondo — thanks to each of you, too, for your encouragement and good ideas! Essentially, there is a bug, but it only presents itself when using findMany() instead of find(). As of 3.0.192, if you assemble a batch of pages with findMany() , and then call a function defined in a page-class definition on one of those pages, the $this variable in that function will have an empty parent property. By contrast, in 3.0.191, the $this variable in that function will have the proper value in its parent property. And also by contrast, in both 3.0.191 and in 3.0.192, if you use find() instead of findMany(), the function will have the proper value in its parent property. So, the bug shows up only in 3.0.192 or later and you’re using findMany() and you’re trying to find any parent-based information from the perspective of $this within a function of a page-class definition. For my own use today, I’m perfectly OK using find() instead of findMany(), though there may come a time when I’m dealing with too many records for that to work gracefully. So I can upgrade beyond 3.0.184! Thanks again to everyone for your help; I’ve learned a lot through this process. If an admin would like to break all this out (it has nothing to do with Ryan’s original post — I meant to reply initially to his announcement of 3.0.192!), I’d be grateful
  9. Oh, bingo — you called it! sam.example.org/:1 Refused to load the script 'https://sam.example.org/cdn-cgi/scripts/7d0fa10a/cloudflare-static/rocket-loader.min.js' because it violates the following Content Security Policy directive: "script-src 'self' 'unsafe-inline' 'nonce-MzlhOGMzOWY0OTdkMDIxMmZkZDRiNTE0ZDBiYTg3YzI=' 'strict-dynamic'". Note that 'strict-dynamic' is present, so host-based allowlisting is disabled. Note that 'script-src-elem' was not explicitly set, so 'script-src' is used as a fallback. I’m out of my ken here, @adrian. I see that something is set to be more secure than optimal, but I’ve no idea where to make a change. Cloudflare is mentioned — do you think that’s because it’s really where rocket-loader is served from, or because I have Cloudflare guarding my cloud-based development machine too well? Or is that not a fruitful line of inquiry? This of course isn’t the serious problem that I need to resolve, but I’m glad to get these little points of friction worked out too. Thank you!
  10. Well now that’s very strange. I see exactly what I posted here, both in a WebKit browser and also in a Chromium-based browser — both of which have Javascript turned on. I thought perhaps there might be an invisible checkbox, but the pointer doesn’t change when I hover in that area, and clicking does nothing. But it doesn’t really matter for the problem at hand; I won’t worry about this for now. Thanks!
  11. Wow, I don’t see anything like this at all. Here’s the top of my screen: and here’s the bottom: [I’m also unsure as to why my posted images keep being magnified so much larger than everyone else’s. I apologize!]
  12. I’m not sure what you’re suggesting? I’ve backed up, made changes, tested, restored from backups countless times over the past eight weeks on my development installation. Whenever I need to update data in the live site, I’ve restored the development site to the last master release, added my new data, and then cloned everything over to the live site.
  13. No effect. 😞 BTW, I saw no way to “select all” the tables, so I clicked on each (there are 95) manually to select them all. Is there a better way? My future self thanks you!
  14. I’ve never run across that before! It looked likely, but has no effect.
  15. Ah. Well, my workaround doesn’t work around everything. It turns out that not only is $this->parent() a NullPage, but in fact $this->url and $this->httpURL don’t include the parent’s node of the URL. So, for example, if page “Parent” has a child page “Child”, the child’s URL ought to be https://example.tld/parent/child/, but as of 3.0.192 it’s instead giving me https://example.tld/child/. I could probably work around this too (finding the parent via the workaround I posted this morning, getting its URL, and appending the child’s URL node to it), but I suspect that I’d then just find something else that doesn’t work because my page’s parent isn’t identified. So I’m back to analyzing the problem....
  16. @adrian, thanks for trying. It really seems to be something unique to my development/production setup. Even when I try to re-create my own setup, I can’t re-create the problem! Most vexing....
  17. Well, I’ve revisited all the modules and made sure that even the core modules’ settings are all identical. And I’ve made the config.php file essentially the same. But I cannot reproduce the problem in the purpose-built “Nori” test environment. So to reiterate briefly in one place: on my development server, in page-class files in /classes/ in 3.0.191, $this->parent() properly points to $this’s parent page, and the parent property of $this also properly points to its parent page; upgrading to 3.0.192 causes no problems, except that in page-class files in /classes/, $this->parent() is a NullPage, and the parent property of $this is empty. I have found an inefficient but effective workaround, however — and given that no one else is seeing this problem and that I’ve easily spent 40 hours trying fruitlessly to track it down, I think I’ll just need to say “good enough” and move on: Awkward work-around Rather than refer to $this->parent(), I’ll instead use $this->wire('pages')->findOne("child=$this"). This works just fine, and @ryan’s code is so efficient that I see no appreciable difference in speed. Sometimes you just have to move on....
  18. Thanks for your interest, @kongondo! In fact, I was able right from the get-go to pin it down to the difference between 3.0.191 and 3.0.192; I mentioned 3.0.184 recently, though, because that’s the last master release before things break for me. Here are the 3.0.192 commits on GitHub, which I linked to above. @bernhard, I decided to go all in on your suggestion of a new project: I created a new server (“Ori”) running 3.0.191. There, I created two templates (“Parent” and “Child”), and set them up in their family tabs so that only “Child” could be the child of “Parent” and only “Parent” could be the parent of “Child.” I turned on page classes, and created ParentPage.php and ChildPage.php files in the site/classes/ directory, setting each up as a subclass of Page. I created a public function in each (identify()) which returns a small definition list that includes the template and the ID of $this. I then created a page of template type Parent, and gave it a child of template type Child; in each case, the template calls the page’s identify() function and echoes it into the HTML, and it checks whether its parent record has an identify() function and echoes its results out, too. As expected, when I load the parent page on the front-end, I see that its template is Parent and its ID is 43 — and no information is provided about its parent (which would be the home page, which doesn’t have an identify() function). Also as expected, when I load the child page on the front-end, I see that its template is Child and its ID is 44, and that its parent template is Parent with an ID of 43. So much for the “control” — it worked as expected. So then I cloned that entire “Ori” set-up as “Nori,” which I then upgraded (3.0.191 → 3.0.192), and loaded the same two pages. I had expected to see the same result for the Parent page, but only the Child information for the Child. Unfortunately for me (but probably fortunately for @ryan!), nothing broke in 3.0.192 on Nori: the Child page also (properly!) showed its parent’s information. So then I began installing each of the modules that I’m using one by one on Nori, and testing the results (still in 3.0.192). I have more modules than I thought! But none of them caused my 3.0.192 test to break the way it does to my system IRL. I guess my next step at this point would be to gradually change the config.php file to match my system, with tests after each change. And then, gosh, I guess gradually re-create the whole system until something breaks. I think I‘ll take this evening off before embarking on that tomorrow. I have no idea how I could create a gist to show this, but I‘d be very happy to give any of you access to a copy of my development system where everything works perfectly in 3.0.191 but not in 3.0.192. Please PM me if you‘d be willing; I‘ll treat you to a couple of beers if you can help me make headway on this!
  19. Thank you for replying, @bernhard! I do always run Tracy Debugger [on my development server], though tbh I really haven’t figured out how to use it other than to be aware of the helpful execution time figure which helps me keep my code comparatively lean. This is not called from a hook; rather, it’s a function in a class definition in the /classes/ directory. $this itself as a variable is working fine — referring to the instance of the subclass, which is of course a page. I added the bd commands you listed into one of the class functions attempting to find $parent, and discovered the little orange shopping-cart icon. (This is how Tracy denotes dumps? Interesting.) When loading my site’s home page in 3.0.184 I see 16 dumps, which makes perfect sense: I had added those bd commands to the “Post” page class, and currently eight posts are among the items listed on the home page. So each post dump is followed immediately by a dump of its parent. Though I’ve never seen this layout or used this portion of the tool, it all makes perfect sense and is exactly what I’d expect to see. Now, if I upgrade to 3.0.196 and reload the same page, I again see 16 dumps. Eight of these are the same eight posts — and they look exactly the same. Their parents, however, all look like this: ProcessWire\NullPage #??? id: 0 name: '' parent: '' template: '' where ??? is different in all eight parent records. This number is not the record’s ID — I really don’t know what it represents. It is not the same number that Tracy Debugger reports along with the good-looking parent data in 3.0.184. If I click on the disclosure triangle, there is lots more data — but almost everything is blank or 0 or null. I’m thrilled that I now know a little more about running Tracy Debugger — thank you for that! But I don’t think it’s telling me anything new: $this->parent() is null (or empty or something) instead of $this’s parent. Is there more sleuthing I can do?
  20. I’ve adjusted my code, hoping to find that $person = $this->wire('page')->parent(); would work better than $person = $this->parent(); — but the result is (unsurprisingly) identical: both of these work perfectly in all cases in 3.0.191, but consistently return an empty page whose id = 0 in 3.0.192 and later, no matter what $this’s page class is and no matter what $this->parent()’s page class is.
  21. OK, I’ve returned from business trips and have finally had some time to pursue this further. I made a slight error in my last post here. As of 3.0.192 (and all subsequent versions through 3.0.196, at least), $this->parent() (in the context of page-class PHP files in the “Classes” directory) isn’t actually null; rather, it’s always empty, with an ID of 0. It doesn’t matter what the class of $this is, and it doesn’t matter what class its parent really is within the system. $this->parent() always gives me an empty page with no template and an ID of zero. Somehow, getting $this->parent() was broken with 3.0.192. I can build lots of checks into my code so that I can render a page without errors (and I am, in fact, doing that) — but I still need the original functionality restored. Is there some alternative way I should be referring to the instance’s parent? Or is there some way we can restore the functionality that we had up through 3.0.191? I’d be very happy to help, but I’m utterly unable to pursue this any further alone.
  22. Well, I have some answers, @ryan, though I do not understand them. home.php In my home.php file, I create a selector that looks for the most recent pages of any of a half-dozen different templates. It sorts first by date, and then by template. I then, of course, cycle through the resulting pages and create HTML for each. I have now added checks for null (via the ID shortcut — thank you!) for each of the returned pages: no errors were reported. In each case, I refer to the item’s parent. I have now also added checks for null for each of these parents: no errors were reported. IssuePage.php custom class It happens that the first item’s template is “issue,” so I began with IssuePage.php. I added a check to make sure that $this itself was not null, just to be thorough: no errors were reported. Again, one of the first things I do then is find the page’s parent and set it to $parent. I’d already changed this logic a couple of days ago to do it properly as a method call: $parent = $this->parent(); I then added a check to $parent to make sure it’s not null. First, I loaded the home page in 3.0.184. $parent was not null, and the relevant information from the parent record was generated and displayed properly in the HTML. Then, I loaded the home page in 3.0.192. $parent was null. $parent should definitely not be null. Here is an image from the back side, showing the “February, 2022” issue whose parent is Beyond Bree. And here is another image, showing the issue as one of Beyond Bree’s children from the editing panel: There is nothing unusual about these records. If I delete them, I get the same null-parent-result on a PostPage class page whose parent is a BlogPage. So, in short — there’s something about 3.0.192 that causes $this->parent() consistently to return NullPage instead of $this’s parent. Thank you so much for walking me through the proper way to debug this! Is there anything else you’d like me to do?
  23. Thank you so much, @ryan! I’ll methodically add these today and see if I can’t pin this down....
  24. Thank you for pursing this with me, @ryan! I was swept away by various events today and wasn’t able to to add more details until now. All of my custom classes are subclasses of a class I call vsPage, which itself extends Page. I make sure to add stub methods to vsPage such that, if I inadvertently call an undefined method, it’s dealt with gracefully. In the case of getTitle(), I’m actually intentionally using the method inherited from vsPage: getTitle() gets the page’s title, falls back to its name if title is empty, and adds some punctuation and a subtitle field, too, if it exists and is populated. The page’s parent uses a different template (not home!), which is also a subclass of vsPage. I’ve double-checked home.php, and getTitle() is never called on anything there. I’ve double-checked every custom class PHP file, and everything is either directly or indirectly inherited from vsPage, where getTitle() is defined. I’ve changed the line so that it calls getTitle() only on the page itself, rather than on its parent, but I still get the same error. I then reversed course and changed the line so that it calls getTitle() only on its parent, and not on the page itself, but I still get the same error. I’ve commented out the line altogether in IssuePage, but the equivalent line in PostPage (see below) causes the same problems. And once I’ve commented out all calls everywhere to getTitle(), I begin hitting the equivalent error with another method, markupALikeness().... Essentially, I seem to be unable to call custom class methods at all. getTitle() works exactly as I mean it to (through 3.0.191) for every template class that I throw at it. No errors are reported in 3.0.191, AFAICT, even with debug mode and Tracy Debugger on. You can see the live site (running 3.0.184) at https://tolkienists.org/. The title of each entry is formed via getTitle(). For the next twelve hours or so, the first three entries will be: Beyond Bree, February, 2022 — a journal issue (IssuePage extending vsJournal extending vsPage extending Page) № 196: Chad Bornholdt — a blog post (PostPage extending EntryPage extending vsPage extending Page) The Great Books № 214: The Hobbit by J.R.R. Tolkien — another blog post; this one shows the subtitle that gets added to the title via getTitle(), in fact. This same page running 3.0.191 on my test machine looks exactly the same. Since I use this method in constructing entries on basically every page on the site, I haven’t yet seen a single page generated in 3.0.192 or 3.0.193. Instead, I get this: Call Stack # Time Memory Function Location 1 0.0001 377648 {main}( ) .../index.php:0 2 0.1780 7369472 trigger_error( $message = 'Exception: Method NullPage::getTitle does not exist or is not callable in this context (in /home/716930.cloudwaysapps.com/aqewnfhddd/public_html/tolkienists-org/public/wire/core/Wire.php line 564)\n\n#0 /home/716930.cloudwaysapps.com/aqewnfhddd/public_html/tolkienists-org/public/wire/core/Page.php(1809): ProcessWire\\Wire->___callUnknown()\n#1 /home/716930.cloudwaysapps.com/aqewnfhddd/public_html/tolkienists-org/public/wire/core/Wire.php(420): ProcessWire\\Page->___callUnknown()\n#2 /home/716930.cloudwaysap', $error_level = 256 ) .../index.php:64 Well well… Error: Exception: Method NullPage::getTitle does not exist or is not callable in this context (in wire/core/Wire.php line 564) #0 wire/core/Page.php (1809): Wire->___callUnknown()#1 wire/core/Wire.php (420): Page->___callUnknown()#2 wire/core/WireHooks.php (951): Wire->_callMethod()#3 wire/core/Wire.php (485): WireHooks->runHooks()#4 wire/core/Wire.php (488): Wire->__call()#5 site/classes/IssuePage.php (43): Wire->__call()#6 site/templates/home.php (95): IssuePage->getEntry()#7 wire/core/TemplateFile.php (327): require('/home/716930.cl...')#8 wire/core/Wire.php (414): TemplateFile->___render()#9 wire/core/WireHooks.php (951): Wire->_callMethod()#10 wire/core/Wire.php (485): WireHooks->runHooks()#11 wire/modules/PageRender.module (571): Wire->__call()#12 wire/core/Wire.php (417): PageRender->___renderPage()#13 wire/core/WireHooks.php (951): Wire->_callMethod()#14 wire/core/Wire.php (485): WireHooks->runHooks()#15 wire/core/WireHooks.php (1059): Wire->__call()#16 wire/core/Wire.php (485): WireHooks->runHooks()#17 wire/modules/Process/ProcessPageView.module (183): Wire->__call()#18 wire/modules/Process/ProcessPageView.module (114): ProcessPageView->renderPage()#19 wire/core/Wire.php (417): ProcessPageView->___execute()#20 wire/core/WireHooks.php (951): Wire->_callMethod()#21 wire/core/Wire.php (485): WireHooks->runHooks()#22 index.php (55): Wire->__call()#23 {main} I do understand that we’re not paying you big bucks to troubleshoot our code — but I’m at a complete loss as to why the changes included in 3.0.192 are causing these problems for (apparently!) only my site. Of course, there probably aren’t a lot of us using custom classes, but still.... Please let me know if there’s any further information I can provide or if you have any more ideas. I’d hate to be stuck forever at 3.0.191! Many thanks!
×
×
  • Create New...