bernhard

As adrian already told you. Or like this:

v0.0.4 fixes the bug mentioned by @kongondo, thank you! v0.0.5 adds a check to load assets only once

Thx, also added a showIf for the exclude config field. https://github.com/BernhardBaumrock/MathParser/commit/e0f0c27ae07a6d19efb5ba768ae9313babcc873e I'm using renderReady - so I'm not sure why fields are loaded?! Any hints? Any experience with this? Working on it ?

Hi @kongondo thx for your improvements! Thx, I've moved the module to github. I'll do that for all my public modules. The workflow is now the same for me (it somehow didn't work before so I stayed with GitLab) and the pw modules directory does also only auto-update versions from github, not gitlab. I've merged your changes. You forgot to change one occurance of id/name change. Not sure if/why it really didn't work before the changes. Can't really believe that ? Please try version 0.0.2 https://github.com/BernhardBaumrock/MathParser/commit/3b09d501b86df06f4502f8415db9a74d13ac5d23#diff-c4d3faaaa59bb6d7e0d306c2c1312e13L125

I guess it would be the easiest to setup a function that loops over all fields of the edit form, creates a simple HTML table (or floating divs could also be an option) and populates all the values with outputformatting turned on. Rendering the original admin HTML into pdf will bring you a lot of bloat and I guess it will be hard to make that look pretty (actually I think it will be hard to even make it work at all, at least with RockPDF (mpdf), because it does not support all kinds of css and you also have some JS magic in the pw admin...).

What exactly are you trying to do? I guess you want to create some sort of reports? https://parall.ax/products/jspdf could also be an option. But generating a PDF from the markup of the adminpage will definitely need some additional work. I'm curious what you come up with. Could also need a good solution ?

Crud will not be that easy. It's easier to open pages in a panel via the regular PW page editor. Linking the page title is very easy using cell renderers. See the aggrid docs.

I don't understand your code $total is never used and $thumb is not defined if you don't have an iconimage... Maybe something like this? <div class="projects"> <?php foreach($projects as $project): $imgOrCount = ''; if($project->iconimage) { $imgOrCount = '<img src="'. $project->iconimage->size(800,800,['upscaling'=>false, 'cropping'=>false]). '">'; } else { $imgOrCount = count($pages->get('/missingimages')->missingimages); } ?> <div class="project"> <?= $imgOrCount ?> </div> <?php endforeach;?> </div>

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

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?

ah, thx - I have been using it some weeks ago but had no intellisense at that time so it was not that helpful. thx, this extension looks better on first sight than the one I linked

no, but i can of course share my php.json file ? but I want to wait until it does not change on an hourly rate ? Just found another nice extension that is especially handy if you are using intelephense: https://marketplace.visualstudio.com/items?itemName=vincentkos.php-docblock-generator It creates docblocks for your methods or properties, which will tell intellisense the type of the variable. I've also created one new snippet that let's you add those typehints inline: "Add variable declaration comment": { "prefix": "var", "body": [ "/** @var $1 $$2 */", ], "description": "Add variable declaration comment" }, Both in action: PS: I created a keyboard shortcut CTRL+ALT+D for the docs extension. Just go to your keyboard shortcut settings and look for the command "generate a documentation block". PPS: you can even combine snippets:

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" },

You can easily hook the field and prepend and append any markup you want. I wouldn't need such a feature I guess. But maybe you tell me some examples and I change my mind..

$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>";

Unfortunately the forum is full of bugs (and errors in the console). See also this one: No idea if that is anyhow related...

if( date('Ymd') >= date('Ymd', $single->getUnformatted('Start_date')) AND date('Ymd') <= date('Ymd', $single->getUnformatted('End_date')) ) { echo "<div class='Dates-text'>ONGOING!</div>"; } ...if it is enough to compare the date (ignoring current time).

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]

I think we should be careful with those snippets. One might find a snippet helpful, another one might find it annoying. If we bloat tracy with snippets it might be counterproductive. I'll see when I find time to dig into that!

Great additions as always! Thanks for the tutorial on building panels, I'll try that when I have an idea for something ? IMHO the best would be to have one shared file in the core and one file specific to each user, because habits are different so I think not all snippets will be helpful to everybody. On the other side it would be great (not to say necessary) to be able to define those snippets somewhere shared across multiple installs of tracy, so that we always have all our snippets available. I think the best option would be to define a web-url (eg github snippet url to a raw file) and pull this file into the pw cache regularly. Everybody could then just push a new snippet to his git account (or on his webserver) and all tracy installations referencing this file would always be up to date with this file. If you are happy with that idea I can try to implement that feature and do a PR

As i already said, I also disagree with that interpretation and connecting it to my video. But I don't think we need to take any corrective actions on the forum rules. It's a great community as it is, so let's make things easy and just hide/delete this thread ? True. @horst we need your magic ?

Sorry, that thread went in a wrong direction and that was not my intention! ? First, I have to say that I disagree with you @szabesz that this was a posting containing political/regligious content. IMHO the video just shows a project that uses web-technology to show how people around the world are similar to each other, independently from their religion, political opinion, skin colour etc.; I agree with that. I didn't understand his posting. That's why I reacted "confused", but I didn't comment it. IMHO your quote was out of context. I can't see any of those definitions match to the video content I posted. Feel free to do that. Even if I disagree I'm of course fine with deleting it. The thread went in a wrong direction and I understand that it is good to focus on what everything here is about: ProcessWire. I also edited my post, I removed the links to the donations and support section of the project. The descriptions of those links where copy-pasted from the ted website, so their wording might have been wrong for the context here in this forum. I apologize for that.

Cat bite? ???

Building your very own custom Fieldtypes in ProcessWire seems to be hard, but it actually is not, once you get the concept. In this post I'll share a simple and as minimalistic module as it can get that everybody can use as a boilerplate for his own Fieldtypes. A Fieldtype that does not store any information in the database A Fieldtype that stores information in the database (to be done) Make your Fieldtype configurable 1. A Fieldtype that does not store any information in the database Some of you might know the excellent RuntimeMarkup module by @kongondo. I've used it a lot in the past, but I get more and more into developing custom fieldtypes rather than hacking the runtime module to my needs. That has several advantages, but it has also one major drawback: It is always a pain to setup a new Fieldtype, because there are lots of methods (see the base class /wire/core/Fieldtype.php) and you have to know which methods you need, which ones you have to remove and adopt etc.; Not any more! Ryan has developed a showcase module (the Events Fieldtype) to learn from, but when I first peaked into it, it felt quite complex and I thought it would be a lot of effort to learn Fieldtype development). There are also some easy and small Fieldtypes to learn from, like the FieldtypeCheckbox. But all of them require a good understanding of what is going on, you need to modify existing config inputfields that might have been added to that fieldtype and afterall it's not as easy as it could be. With my new approach I plan to use a boilerplate fieldtype to start from (in OOP terms to "extend" from) and only change the parts i need... More on that later. Here is the boilerplate module with some debugging info to illustrate the internal flow on the tracy console: See the module in action in the tracy console ( @adrian has done such an amazing job with that module!!!): The code should be self-explaining. What is interesting, though, is that after the ### getUnformatted ### dump there is only one call to "___formatValue". All the other calls (loadPageField, wakeupValue and sanitizeValue) are not executed because the value is already stored in memory. Only the formatting part was not done at that point. With that concept it is very easy to create your very own custom Fieldtypes: <?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 FieldtypeDemo extends FieldtypeMarkup { public static function getModuleInfo() { return [ 'title' => 'Demo', 'version' => '0.0.1', 'summary' => 'Demo Fieldtype', 'icon' => 'code', ]; } /** * convert the wakeupValue to the given format * eg: convert a page object to a string */ public function ___formatValue(Page $page, Field $field, $value) { $value = parent::___formatValue($page, $field, $value) . " - but even better!"; d($value, '___formatValue --> convert to whatever format you need'); return $value; } } Notice the change "but even better" in the last two dumps. I think it can't get any easier, can it?! ? I'll continue testing and improving this module, so any comments are welcome! 2. A Fieldtype that stores information in the database See this module for an easy example of how to extend FieldtypeText:

I'm sure you'll get more elaborate answers, just a short question: Do you know about bootstrapping pw? https://processwire.com/api/include/