Leaderboard

... well, not really. But I just saw these and thought I'd share ? Happy Holidays! ???☃️

Pinging the grid heads: @bernhard @jmartsch @mel47 @dragan @szabesz In short, I have modified RockGrid to work with Tabulator instead of ag-Grid. I left out ajax and plugins for now. I fully understand, if Bernhard is not interested in switching the "engine" of RockGrid, but at least it is food for thought and a proven alternate solution ? The "HackGrid" can be found here: https://github.com/mestaritonttu/FieldtypeRockGrid/tree/tabulator Longer story: During the last week of November I ran into Tabulator by accident. It occurred to me "someone in the early days of RockGrid suggested some other solution". I searched the PW forums and found out that someone was szabesz and the solution was Tabulator! Now, the important thing here is that since the PW forum discussion (April 2018), Tabulator has seen significant changes. It got rid of jQuery & jQuery UI dependencies and added a ton of features. Why have I decided to switch to Tabulator? Lately ag-Grid has left a bad taste in my mouth - the performance of its row autoheight sucks, so I had to work around it - inside the autoheight workaround I had to add another workaround to avoid an infinite event triggering/listening loop - the closed nature is showing its bad sides more and more, like not being able to see the content in their enterprise bug tracker So what do we get with Tabulator? - row autoheight that just works - dropdown filter out of the box, so I don't need my awkward external filter - features matching the enterprise version of ag-Grid, such as http://tabulator.info/docs/4.1/select#setup-range http://tabulator.info/docs/4.1/group http://tabulator.info/docs/4.1/download#xlsx http://tabulator.info/docs/4.1/tree http://tabulator.info/examples/4.1#nested-tables http://tabulator.info/docs/4.1/clipboard What are the philosophical differences? In the words of the Tabulator main dev, ag-Grid focuses on being a fully functional spreadsheet while Tabulator goes more down the route of interactive table. I would have announced this already nearly 3 weeks ago, but caught pneumonia ? Use on the RockGrid side is really not much different. Mostly just using col.title instead of col.headerName. For some reason the grid.js stuff is lost (to get the field titles), but I did not have time to investigate.

@PWaddict could you please modify $basename = strtolower($basename); to $basename = mb_strtolower($basename); in cleanBasename method in /wire/core/Pagefiles.php (line 568).

Hi. I got this error when trying to access Parent properties in Custom find (Selector field) white configure page reference field I'm on a clean installation of PW 3.0.122 and PHP 7.2.4 Please confirm.

Happy Holidays! This latest master version of ProcessWire contains hundreds of new additions, fixes, optimizations and more. This post covers all the highlights— https://processwire.com/blog/posts/pw-3.0.123-master/

Nice catch! It's interesting because many of the $sanitizer methods make use of the internal nameFilter() method which uses mb_strtolower. If you actually follow the cleanBasename method it goes through $sanitizer filename(), which uses name(), which uses nameFilter() which leads me to believe that it might actually be possible to just remove that that: $basename = strtolower($basename); line from the cleanBasename() method completely. I just tested this and it's actually pretty close - there are a couple of problems - one is the regex on #578 needs A-Z added to it. The other is that beautify doesn't get passed through to nameFilter() which is a condition for mb_strtolower() being called. Anyway, that was just an interesting excursion into what is actually going on and where ?

Thanks for the feedback. I posted suggested solution on the github. That's because $sanitizer->(file)name() checks for multibyte support and uses mb_strtolower().

It's working PERFECT. Thank you. Please post the solution on the GitHub issue.

Hi! tell me, pls, how to execute this equality (from ready.php) $wire->addHookAfter('InputfieldPage::getSelectablePages', function($event) { if($event->object->hasField == 'FIELDNAME') { ..... } } - $hasField The Field object associated with this Inputfield (from definition parent class for InputfieldPage) the left side equation is the object entity, and the right side - the string How it is?

I'm still not satisfied as I can't replicate this. I would like to perform some more tests, but don't want to pollute this thread, so if you are interested in narrowing down this issue, please PM me, @PWaddict

Sorry and thanks. Fixed the semantic ui blunder (feel free to use any of the themes offered by Tabulator and hack the .module.php accordingly). Added example to readme. The example references variables and functions that you do not have access to (codesObj, afterFilter). It is not meant to be used as-is, but as a reference. I can clarify this later in the example comments. https://github.com/mestaritonttu/FieldtypeRockGrid/tree/tabulator As said, this is a hack-in-progress and the start of a discussion, so I am ignoring the plugin errors right now. Regarding your questions on server-side validation and buttons, I do not have answers. I can only point you to http://tabulator.info/docs/4.1/validate http://tabulator.info/docs/4.1/update Perhaps you can build a custom validator that does what you want. See the last entry "Delete Row" in the Update section.

Hi, I don't know if this question is ironically made for your self or if is a real one. Anyway just incase, the answer is easy: Simply add a single character. Always use === instead of == (or !== instead of !=) when comparing so if the types differs PHP will not attempt conversions and will return FALSE. Do not use the == until is really required, knowing what you are doing. Charts: https://github.com/sentientmachine/php_equality_charts

Thankyou, Robin, for your detailed response! How i could forget about php type juggling?

Hi @tarkvsg, welcome to the PW forums. It works because the comparison uses the == "equal to" and not the === "identical to" operator. The PHP manual explains that == means "TRUE if $a is equal to $b after type juggling". In the case of the comparison... $event->object->hasField == 'FIELDNAME' ...'FIELDNAME' is a string so a comparison is made to the string value of $event->object->hasField. And the string value of a Field object is the field's name. See the __toString() method of the Field class here: https://github.com/processwire/processwire/blob/649d2569abc10bac43e98ca98db474dd3d6603ca/wire/core/Field.php#L1097-L1103

I like Tabulator ?. I had a bit of a play with it some months ago, for some pet module I was working on.

I've been out of the loop for a while (my day job doesn't involve a lot of development) but I'm starting to use Processwire again for a couple of projects. Dating back to when I used it originally I noticed that not only were new features added very quickly, they were usually added for people (like me) requesting things that other CMS platforms might have said "no, you can't do that". Here we have Ryan saying "I noticed you trying to do X so I added feature Y to the core which should save a lot of work". Glad to see this pace is still continued and makes me feel like I'm in some cool "elite" group that has access to some secret magic that users of other platforms miss out on.

$pages->find("template.name=songs, title=Last Christmas, band=Wham")->play(); // sorry for trolling ;-)

Happy Holidays to All! $log->save("??");

Fieldgroups currently are just an additional layer of "glue" between templates and fields, and for most they are just a few additional lines to write when assembling templates through the API. There are a few points where that additional layer can add some really nice magic to PW, but even most PW module developers never come across these. For everyone not deeply into obscure PW vodoo magic, creating a template with fields is always: Create a template Create a fieldgroup with the same name as the template Create your fields, save them and add them to the fieldgroup Save the fieldgroup Set the fieldgroup in the template Save the template Of course, you can reorder the steps as long as the objects are created before being used and saved after being changed. Yes, they are. As written above, they are just a necessary glue.

Hi and welcome to the forum. Your question is pretty vague. But yes, it will allow it if you write the code for it. The API will help you interacting with the backend easily. Also if the given external service has an API to fetch content from, then the process is more than easy (following their documentation). There is an idea for interacting with another ProcessWire site with the API :

You can also switch PW versions instantly with Tracy. By default it works with versions which are archived by Ryan's PW Upgrades module, but there should be nothing stopping you from recreating those archived version manually by creating .wire-x.x.x folders with the contents of that version's wire folder.

The notion of core in MODX might be different from the one in ProcessWire (maybe?). Btw, I don't know if you've seen this post on MODX to ProcessWire welcome brief? It might be of interest ?. One of the philosophies of ProcessWire, one that makes it very extensible is the fact that everything, all its building blocks is a module. Yes, even the admin (backend) is a collection of modules. Modules are just PHP classes. You have your classes (i.e. modules, or the site's custom classes) and these live here: /site/modules/. ProcessWire has its own core classes: the ones designated as modules live here: /wire/modules/. The are other classes, in fact, the main classes of ProcessWire, aka the core, and these live here: /wire/core/. In order for ProcessWire to know about and register your classes, they have to live where ProcessWire expects them to, i.e. /site/modules/. Now, this does not mean that all your classes have to be modules. No; you can have custom classes (i.e. my_class.php) living in /site/modules/my_module/my_class.php or /site/templates/includes/my_class.php (@note: includes here is just arbitrary) which you access from within your registered classes (modules) or from within your template files. Any attempt to access such classes directly will be blocked by ProcessWire for security reasons. This just means you can have helper classes or other libraries you need for your modules which ProcessWire does not need to be aware about (in respect to registering them). The foregoing means that... ..is not necessary in ProcessWire. your /site/ is already outside the core. It survives upgrades and ProcessWire never touches it. It just communicates with it (bidirectional communication). All ProcessWire core variables (e.g. $wire, $config, $fields, $page, $pages, etc) are available everywhere for your use, both in the backend and the frontend. I hasten to add that ProcessWire will not automatically install your modules for you. If it finds a new module, it will just let you know that it has found a new module. If it finds duplicates of the module, i.e. either duplicated under /site/modules/ or under both /site/modules/ and /wire/modules/ , it will alert you to the fact and will ask you to choose which one you are going to use. This means that you can duplicate a core module found in /wire/modules/ under /site/modules/, edit it to suit your requirements and ProcessWire will happily continue serving the copy under /site/modules/ and yes, it will survive upgrades. This is not always a good idea though, as the mother module could get some upgrades which you would be missing on and/or require. So, in ProcessWire, we develop our modules under /site/modules/. Most people who develop modules use a versioning system, invariably git, and host their modules on GitHub, BitBucket, GitLab, etc. Secondly, many people make use of git's branches and work in the dev branch. All development and testing is done under that branch. When ready for production, they merge into master branch. For modules submitted to the ProcessWire modules directory, if the project (code) is hosted in GitHub, ProcessWire (the site) reads the master branch of the project to access the README and the download link. In the past, I have used symlinks to link my module to different ProcessWire versions. For a quick and dirty check, I have occasionally had two wires, e.g. wire and wire27 which I rename to suit my needs RE ProcessWire version. Many of us here develop using the latest ProcessWire dev. I cant' speak for everyone, but I think many then use (if they need to) a ProcessWire 2.7 just for final tests. I doubt many of go back and forth between versions (i.e. between 2.7 and 3). No ?. As long as you name your module classes as per ProcessWire requirements work with what suits your needs. The above is just the basics. We have people here who work in teams and have slightly different approaches, but the basics are the same.

@joshuag Are there any updates on this awesome module already? Can't wait to try it.

A generous use of WireCache can help with generating overviews for a large number trees. <?php namespace ProcessWire; /** @var $cache WireCache */ foreach ($trees as $tree) { $overview = $cache->getFor($tree, "tree-overview"); if (!$overview) { $overview = wireRenderFile('parts/tree-overview'); $cache->saveFor($tree, 'tree-overview', WireCache::expireWeekly); } echo $overview; }