Leaderboard

Like what Bernhard mentioned — my IDE knows all about what I'm accessing when I type in $this->wire()->apivar or wire()->apivar, so it can suggest methods, arguments, and tell me when I've typed something wrong. Whereas less of this happens with $this->wire('apiVarName') or wire('apiVarName') — the IDE isn't nearly as helpful. So it's more of catering to the way the IDE works than anything else, and in exchange it makes coding easier, faster and less error prone. It's the same reason you'll sometimes see this in modules: /** @var Pages $pages */ $pages = $this->wire('pages'); That comment in the first line tells the IDE that $pages is referring to the Pages class. But this produces the same result with no /** comment */ necessary: $pages = $this->wire()->pages; In most Wire derived classes, $this->wire->pages (like Bernhard was using above) or $this->pages will also work and the IDE will still know what API var you are accessing. The reason I prefer to call it as a function $this->wire()->pages rather than a property $this->wire->pages (or $this->pages) is because it will work consistently everywhere in PW, even if a class has "fuel" turned off (see useFuel). Having fuel off is necessary in classes that can potentially have properties or field names that could overlap with API var names; an example is the Page class or your own custom Page classes in /site/classes/. The other reason is that $this->wire()->apivar (wire method) is the most efficient access to an API var because it has the fewest hops. Accessing $this->wire->apivar or $this->apivar first goes to $this->__get('apivar') and then $this->wire()->apivar. So $this->wire()->apivar is more direct (one less hop). In reality it probably doesn't matter much though. @Zeka

Hi there! It's been a long time since I've been here. I've not developed for a good few years. My son has asked if I can create him a website for his personal training service. I used to have a Linode to host sites but I've not had that for a while. Also, it was a bit problematic being responsible for the web server and general setup. I wondered what the best/easiest way is to quickly establish hosting without the hassle? Something where the setup and PW installation is automatically handled? Any ideas or suggestions would be very much appreciated! ? Cheers.

GET variables are automatically added to MarkupPagerNav links when they are set to $input->whitelist(). In this case you are dealing with an array value, so the input variables should probably be passed through $sanitizer->array() first before you do anything else with them. $y = $sanitizer->array($input->get('y')); // There are also other ways you can apply sanitizers to input variables If you do that then the sanitizer will give you an an array value from input in the format of "y[]=bar&y[]=baz" or "y=bar,baz" (these should be encoded when in a URL though). Then you would set: $input->whitelist('y', $y); By default MarkupPagerNav uses the comma separated form in its links, but if you prefer the square brackets then you can set: echo $results->renderPager(['arrayToCSV' => false]); But you won't get the exact format you showed because square brackets are typically encoded in URLs.

Thx @BillH I did that shortly after i sent my post. And there it was,- each of both related entries had a single whitespace before the string. Solved. Sorry for not posting this more in time.

Related: https://github.com/processwire/processwire-issues/issues/550

-> get, learned again

Try: $page->parent->get('menutext|title');

My first guess would be that there is actually something in the job_titel field for those two entries that is causing the sorting error. Have you looked directly into the database fields themselves – using something like phpMyAdmin or Adminer (hosting companies often provide a tool in Control Panel or the like)? You'll find it's quite easy to navigate the PW database once you take a look at it. You may see something that you're not seeing using other methods.

Yep, problem is gone. Thank you very much.

The reason is because ListerPro uses the saveField() when only field in the row is changed. If you edit two fields, then the rename will work because ListerPro then uses save() - you can see this starting on line 631 of the main ListerPro module file. It should be possible to make CUN work with this by adding a new hook to Pages::saveField. I have this working but I think I need to test more for other possible side effects. If you'd like to help test, you can place: $this->addHookBefore('Pages::saveField', $this, 'customRenameUploads'); after this line: https://github.com/adrianbj/CustomUploadNames/blob/67b1d42aef4c23be92684420f0d282c0c4a9a8d4/ProcessCustomUploadNames.module.php#L101 Let me know how it goes for you.

Thanks @PWaddict - that helped a lot. Should hopefully be fixed in the latest version.

hidden pages and unpublished pages are different things - just for clarification. unpublished pages shouldn't be accessible to anyone without an active ProcessWire session (admin, editors, ...) while hidden pages are accessible and visible to those with the full URL. Another thing... are we talking about real URL Segments or about parts in /the/path/to/a-page/? Can you outline more details about the setup and where the url segment appears, what it does etc?

Hi @adrian, Do you think that it would a good idea to add options for some automatic pruning and cleanup of the log files and exception HTML files that Tracy writes to /site/assets/logs/tracy/? It doesn't occur to me to look in this folder very often for remote sites, but I see that error.log in particular has the potential to grow quite large. For instance on one site I have around 50,000 lines in error.log, most of which relate to minor issues in an older version of Tracy itself... "Undefined offset: 0 on line: 11 in Tracy Console Panel" (this seems to be resolved in newer versions because I'm not seeing it recently) ...or possibly relate to issues in the PW core... "PHP Notice: Undefined index: path in .../wire/core/WireInput.php:985 @ https://mydomian.com//xmlrpc.php?rsd" (does this look like a core issue to you or is it related to Tracy error screens?) So far I haven't had any real problems with either the size of the Tracy logs or the number of exception HTML files but if these have the potential to grow indefinitely then perhaps it could become a problem in some cases if users don't remember to check the Tracy logs directory. If you decide it would be worthwhile to have options to automatically prune the Tracy logs then maybe it would make sense to have these logs conform to the file extension and delimiters used by the core PW logs, and that way you could make use of the prune methods in WireLog.

But it will not help others that may have the same problem in the future ?

bd() and d() - I've learned SO much about ProcessWire and PHP and OOP in general, can't thank you enough @adrian console - it's a dream to work with! request info panel - invaluable, especially when working with RockMigrations user switcher - handy refresh feature - modules refresh not moving away from current page That one is also great for working with RockMigrations: Usually I create a migrate() method that is triggerd on modules refresh. Then I can add a new field for example to a page and when I'm editing this page, I add the new field in code and just hit "modules refresh" via tracy and I end up on the same page edit screen just with a new field ready to be populated ? Oh and I've been using adminer for backup/restore lately quite often...