Leaderboard

DEPRECATED - see the new version here: Brand new module that I've built because I'm too lazy to always open the calculator when I have to do some calculations (like vat calculations etc): It adds some magic to FieldtypeDecimal, FieldtypeFloat and FieldtypeInteger fieldtypes. Of course you can define which fields you want to extend: https://github.com/BernhardBaumrock/MathParser Any ideas or contributions are welcome. What do you think about the name? What do you think about the styling?

This week we look at two new versions on the dev branch and a lot of updates. These include new page traversal methods, page list customization options, improved empty trash process, two factor authentication improvements, improvements to the profile editor, and more– https://processwire.com/blog/posts/processwire-3.0.115-and-3.0.116-core-updates/

@Robin S Thanks for your response - this has now been fixed: https://github.com/processwire/processwire-issues/issues/716#issuecomment-427372423

Thx @Robin S, I had a look to those fieldtypes and you where partially right. I removed sleepValue and deletePageField since they should never get called on a non-db fieldtype. But your runtimeonly field does actually have too few methods if you want to keep it completely out of the db. Your fieldtype creates an empty db table. Not sure if that is intended? I've invested some more time and really like this approach of building new Fieldtypes! Is really simple, see this example of a new Fieldtype called "FieldtypeNow": I renamed the base fieldtype to "BaseFieldtypeRuntime" and it really does not do anything other than providing the boilerplate. It does not even show up in the list when you create a new field in your pw installation (screenshot later). This is the current code: Actually it does only define the inputfield and add some hooks to replace the render and renderReady methods by our own implementations and define all the functions necessary to keep the db out of the game: Simple, right? ? This is how the installation screen looks like: The BaseFieldtype is set as dependency, so FieldtypeNow can only be installed when the Base Fieldtype is available. Once installed, you can easily create a new field of that type: Notice that there is no Fieldtype "BaseFieldtypeRuntime" in this list as I mentioned above. You can then add your field to a template and edit any page of that template: <?php namespace ProcessWire; /** * Demo Fieldtype Extending the Boilerplate Runtime Fieldtype * * @author Bernhard Baumrock, 03.10.2018 * @license Licensed under MIT * @link https://www.baumrock.com */ class FieldtypeNow extends BaseFieldtypeRuntime { public static function getModuleInfo() { return [ 'title' => 'FieldtypeNow', 'version' => '0.0.1', 'summary' => 'Fieldtype showing the current time', 'icon' => 'code', 'requires' => ['BaseFieldtypeRuntime'], ]; } public function render() { return time(); } } Another Fieldtype rendering the content of a php file named like the field (very similar to the existing modules by @kongondo RuntimeMarkup, @Robin S RuntimeOnly and @kixe FieldtypeMarkup). You actually only have to implement the render() method, and if you need you can load scripts in the renderReady() method... This fieldtype loads files that are named like this: site/templates/FieldtypeRenderFile/{fieldname}.{templatename}.[php/css/js] site/templates/FieldtypeRenderFile/{fieldname}.[php/css/js]

Nice one @bernhard, A couple of thoughts: Always safer to deal with IDs rather than names. If I have a float field called 'price' and tomorrow I decide to change its name to 'unit_price', MathParser code would not find it (unless of course one is using the autoload feature, in which case it might still throw the warning about field does not exist). The superuser would be forced to change the config. I've noticed assets (MathParser.js, MathParser.css and math.js) are loaded in all Page Edits, even in ones where it is not required or where there are no compatible fields. Maybe there's no way to get around this? We started on the premise that we are lazy ?. So why not take lazy to its logical conclusion? Below, I present lazy max! I've changed the module config textarea inputs to ASM Selects. The descriptions are just dummy text. Only compatible fields (float, integer, decimal [do we have a Fieldtype like this?]) are listed for selection. I don't have a Gitlab account, so I've attached a zip file with the php files to this post. Having said above. The module did not work for me (even before the changes I made). Shouldn't it be auto-triggering? Demo MathParser-kongondo-edits.zip

Fortunately no such transformation gonna happen like in the classic The Fly movie ?

...Or if you use _init.php, define $homepage there and it will be available in all your template files :-).

I believe this is because $page->next() is for traversing pages as they appear in the page tree. So when you use it on a repeater page it will refer to the next sibling page in the page tree, in the Repeaters section under the Admin branch. Those pages use a system repeater template that is accessed controlled. Non-superusers don't have access to those pages themselves, they only have access to repeater items via a repeater field value (a RepeaterPageArray). Whether this is a good thing or not has been under debate here: https://github.com/processwire/processwire-issues/issues/183 A better option might be to use WireArray::getNext() on the repeater field value, which will hopefully avoid the access issues for non-superusers. // $value is repeater field value if($value->getNext($item) && $value->getNext($item)->size->value != 'half')

Hhm, sorry, I was very busy and disabled all notifications for the last 7 hours, to get not distracted. On the topic: We can hide it, or we can keep it. It is not (only) my decision. (?) @kongondo has locked it, maybe that is enough in this case? (So everybody can read what happened, but we avoid further discussions into the wrong directions.)

Just for display in the repeater label? That can be done with a little hook in site/ready.php: wire()->addHookAfter('InputfieldRepeater::renderRepeaterLabel', function (HookEvent $e) { $label = $e->return; $page = $e->arguments('page'); $label = preg_replace_callback('/\\[([a-zA-Z0-9_]+)\\]/', function($match) use($page) { return number_format($page->{$match[1]}, 2, ',', '.'); }, $label); $e->return = $label; }); This looks for a field name between square brackets (something like "[price]" in "#n: {title} - {item} - [price]") in the label and replaces it with the formatted value of that field.

Hi all, This is more of a general question than a problem per say. Anyway I have been using the AssistedURL module for call to action links among other things, on the whole its a great module so shout out to the developers. That said I just noticed that if you update a linked PW page's name/url any link field on other pages using AssistedURL don't update automatically. If this is a limitation then thats fine just thought I would ask incase there is a setting either at module or sitewide level that I am missing that enables this to happen.

https://trix-editor.org/

Lucky us! It has become PW 3.0.116 "Spacy ads" instead

That's a limitation. The URL field type (which AssistedURL adds JS sugar to) doesn't store a page id for underlying URLs, so it has no way of knowing that the link is an internal one and that the URL has changed. I solved that problem by using a radio button that switches between the URL field (for non-PW links) and a regular page field. That's not perfect, but it works so far (quite a few years by now, actually) and I haven't had any user complaints.

To be honest, I would not care too much about it (I guess). I'll have to think of it during further usage of the console. If you implement them, then I'd suggest you implement them in a way that they pull the current api and are always up to date (no idea how hard that would be). Otherwise you'd get plenty of requests to keep everything up to date, I'm afraid. But maybe others think differently... What annoys me, though, are suggestions like this: Would it be somehow possible to prevent those suggestions of php functions when I actually want to access an object property/method? Thx

Not really. Since you have to store the value, you also need to load the page it is attached whenever you want to read it. PHP provides no built-in persistent storage that reaches across sessions and is shared between individual threads/processes. If you want to avoid the overhead of loading $homepage and the counter for every page view, you could however use a memory cache like memcached or APC, update that when the counter is incremented and read from it when viewing other pages (or fall back to $homepage if its not yet set, e.g. after a server restart).

Moderators Note Just a quick update. We've consulted and agreed that the topic remain locked as per the reasons expressed by @horst above. Thanks.

To me it's not so much about what chat or community software you're using. Open source or not, It's about focusing on stuff and the community itself. Having people that care and spend a lot of free time to contribute. There's seemed to be a real interest in the discord server I opened (which takes 2 clicks). There's easy way to add channels and voice chat. Lot's of people joined for a couple days and we had some discussion going on. But it seems pretty dead now. ? Something related: I was thinking the other day, how about making a stream on twitch.tv for web devs? I don't know how that would work out, but I've seen there's some doing it already.

I've been using this one (PHP DocBlocker? https://marketplace.visualstudio.com/items?itemName=neilbrayfield.php-docblocker

another one: "Module Boilerplate": { "prefix": "module", "body": [ "${0:// info snippet}", "class ${1:Classname} extends WireData implements Module {", "", " public static function getModuleInfo() {", " return [", " 'title' => '${2:Hello World}',", " 'version' => '0.0.1',", " 'summary' => '${3:Your module description}',", " 'singular' => true,", " 'autoload' => true,", " 'icon' => '${4:smile-o}',", " 'requires' => [],", " 'installs' => [],", " ];", " }", "", " public function init() {", " }", "}", ], "description": "Module Boilerplate" },

Interesting. It's based on FieldtypeFieldsetOpen, which likewise creates a database table (as does FieldtypeFieldsetClose). Not sure why these fieldtypes do that considering they don't store data, but it doesn't do any harm that I can see.

$today = date('Ymd'); $start = date('Ymd', $single->getUnformatted('Start_date')); $end = date('Ymd', $single->getUnformatted('End_date')); if($today == $start AND $today == $end) echo "<div class='Dates-text'>TODAY!</div>"; elseif($today >= $start AND $today <= $end) echo "<div class='Dates-text'>ONGOING!</div>";

Hope you recover soon ?

Ryan. Sorry to hear that. I hope you heal up quick. Drop a line to let us know you are OK.

Inputfield::renderReady was made hookable as Inputfield::renderReadyHook in PW 3.0.44. So the module could be updated to hook after InputfieldPage::renderReadyHook instead of before InputfieldPage::render - then it will work with repeater fields. That would add a requirement of PW >= 3.0.44, or else the module could check the PW version and hook different methods depending on the version.

Personally I have the impression it's growing at a slow but steady pace. And though slow and steady is much better than fast and sloppy, it's a bit frustrating to see other platforms seeming to get more attention while being notoriously inferior. I like following CMS Critic's Awards. PW has got a bunch of exposure there, but this year it's only nominated for "Best for SMEs" alongside Craft and ModX, both paid platforms. I'm guessing Craft will get that one because it looks polished and very DIY, and PW is too "pro" for that category. Then there's "Best free CMS". PW is not there. You see the usual Joomla and Wordpress there, along with CMS Made Simple. That one just trying out the demo makes me cringe. It's so 2001 that I can't take it seriously. Now I've never used Joomla, but I constantly compare PW with Wordpress and can't comprehend how Wordpress still holds on to such a large chunk of the market. "Best Open Source CMS". CMS Made Simple, ModX, Silverstripe. So I went to see what Silverstripe is all about. Now SS looks to use a somewhat similar approach to PW, and though it looks relatively polished, it doesn't feel as mature to me. So we've got PW in one category this year, and the wrong one. To me that feels like a loss, which will reflect another dip in that Google Trends chart over the next year. The next version will be an important step. Updating the default theme of the CMS is a must. I'm guessing most people now immediately install Reno's theme the second they enter the CMS after installing. So a new version with a new look will attract attention and that will hopefully pull it up a bit more. If we want it to grow faster (an argument can be made whether that would be good or not), it's mostly a matter of getting more people to try it out. After getting the first project running, it's hard not to be hooked. On an end note, I think it's time we start considering a refresh on the website. Just saying.

I would go with the "icon name = selector" route, in a simple textarea, one rule per row. Icon name would be the fontawesome name.

If you want to keep the original Pageimages WireArray but use an index you can create your own index counter: $index = 0; foreach($data->img_gallery as $image) { // do whatever with $index and $image here $index++; }

After doing some testing it turns out that when a user doesn't have access to edit a field the classed were not added since there is no Inputfield to render. Better solution: wire()->addHookBefore('InputfieldWrapper::render', function($event) { $wrapper = $event->object; foreach ($wrapper->getChildren() as $f) { // Only fieldtypes can have tags && make sure the fieldtype has tags if ($f->hasFieldtype && !empty(wire('fields')->get($f->name)->tags)) { $f->set('wrapClass', "tag-" . wire('fields')->get($f->name)->tags); } } });

Hey Horst, Thanks for your post. We figured it out. My assumption that the Inputfield stores the tags wasn't correct. You have to get the field itself and you can access the tags from there. You can find the code that actually works: wire()->addHookBefore('Inputfield::render', function($event) { $inputfield = $event->object; if ($inputfield->hasFieldtype && !empty(wire('fields')->get($inputfield->name)->tags) { $inputfield->set('wrapClass', "tag-" . wire('fields')->get($inputfield->name)->tags); } });