Leaderboard

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 Guys, AdminCustomFiles received some well-deserved love. (an update to version 0.9.61) There were several bug fixes and some major changes. I did break compatibility on several aspects of this module but after this update everything should be fine. - You can upgrade from 0.8.7 and below. (we take care of all settings) - The JSON output is now fully customizable. Previously I hooked *ProcessController::execute* and inserted the files to the config->scripts and files but with ProcessWire 3.x these were not the last files. Now we use Page::render to insert the files that should fix it. For the config.AdminCustomFiles javascript object we now have a base class that can be extended easily. When you created the class, you can select the class and save the module configuration. More info in the module configuration and in the example class below. /** * AcfConfigCustom * * Create a file in your AdminCustomFiles folder and start the filename with * ‘AcfConfig’ then ‘a custom name’ and add ‘.php’. * * In this file create a class with the basename of the file without the * extension. This class should extend AcfConfig and implements Module. * * Properties of the subclass * * @var AdminCustomFiles $adminCustomFiles Instance of AdminCustomFiles may you need it. * @var Page|NullPage $editPage In processPageEdit it would be the page you are editting. * @var Template $editTemplate Template from the page above. */ class AcfConfigCustom extends AcfConfig implements Module { /** * Optional ready method * * - Use it or leave out. * - We call ready() before calling jsConfig(). */ public function ready() {} /** * Required jsConfig method * * Return a PHP array ready to be used for $config->js * * @return array */ public function jsConfig() { $process = $this->wire('process'); return array( "activeProcess" => $process->className(), "editPage" => $this->editPage->id, "editTemplate" => $this->editTemplate->name, ); } }

OK, just released a major new version: 4.12.0 1) New Title/View link in Dump tabs, so ID is edit link and title/name is view link 2) New PagePermissions section added to PW Info panel: 3) New PHP and custom PW autocomplete snippets added to the Console and File Editor panels. Here's one example, but there are others in the posts prior to this one showing general PHP snippets. Currently there are two custom PW snippets: pwforeach and pwfind - I'd love to hear what you guys want to see here. If you have new snippet ideas, please take a look at: https://github.com/adrianbj/TracyDebugger/blob/master/scripts/code-snippets.js and feel free to send PRs with new additions. 4) Ability to dynamically resize the font in the Console and File Editor panels with: Increase: CTRL + +/= Decrease: CTRL + -/_ Reset: CTRL + 0 5) Changes to the way the Console panel divs are structured and resized - please let me know if you see any issues with the results panel protruding beyond the bottom of the panel or any other issues. It's still not perfect, but it's breaking my brain ? 6) Some minor Tracy core updates and also general cleanup of many of the custom panels. Please let me know if you have any problems with this new version, or ideas for improvements!

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:

Ok, I have implemented the ability to link to your own custom snippets file: If you're using a Github Gist, make sure you use the https://rawgit.com/ service because the raw file from Github is served without the correct mime type and won't work. The format of the custom snippet file is like this. Note the getCustomCodeSnippets() compared with the core snippets file which uses getCodeSnippets() var getCustomCodeSnippets = function() { return [ { name: "pwfind", content: "d(\\$pages->find(\"template=\${1:basic-page}\")->each(\"\${2:title}\"));", tabTrigger: "pwfind" }, { name: "pwforeach", content: "foreach(\\$pages->find(\"template=\${1:basic-page}\") as \\$p) {\n\td(\\$p);\n}", tabTrigger: "pwforeach" } ] }; At the moment the custom snippets file is PHP only. I don't think we will ever need other languages for this. I have also added in the ACE core snippet files for other web related languages so if you use the File Editor panel for JS, CSS, etc, there will now be a bunch of useful snippets for those languages as well. If you want to peruse the available ACE core snippets, the best way is probably here: https://github.com/ajaxorg/ace/blob/master/lib/ace/snippets/php.snippets You can also check out the snippets for other languages in the parent folder of that file.

Spot on. You made me aware of it that, that was my motivation to write the post I did. So in the end, yes, politics. Sorry for that.

Hope you recover soon ?

@bernhard, you can actually remove a few more methods from such a fieldtype - FieldtypeFieldsetOpen is a good one to refer to for a fieldtype that doesn't store anything in the database. A while ago I made a simple runtime-only fieldtype that generates inputfield markup from PHP files in a subfolder within /site/templates/ - sort of like a stripped-back version of RuntimeMarkup without any config fields in admin. It was just intended for use in my own projects and I didn't think it was worth announcing publicly seeing as we already have kongondo's module, but I've moved it to a public repo in case it is interesting for you to take a look at: https://github.com/Toutouwai/FieldtypeRuntimeOnly

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')

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

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!

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 ?

I am sure it was not your intention and I understand why you posted this, however I am probably too strict in this matter. Also, I would be able to point out why I oppose the motivation behind this initiative but that would certainly be called politics.

OT again! just in case anyone is interested, I have started working on this: https://processwire.com/talk/topic/12208-tracy-debugger/?do=findComment&amp;comment=174121 Would appreciate any and all input of those of you who love autocompletion snippets ?

I would certainly welcome this functionality in Tracy, but I am not super excited on building this at the moment, but if you're feeling motivated, I am sure with the code from LK's module and the quick guide I just put together you should have a decent starting point. Of course it will need to be updated to support the new access functionality that Ryan added fairly recently.

He's just gone and done it again! Well done @bernhard??

Are you saying that I can just find a right ProcessWire and include its index.php to my web app, and I have full access to its pages and users? I can't but wonder and love the chances of this platform. Thanks! This is so awesome work.

Another hidden treasure in the PW Backend: PW 3.0.61 introduced the VEX library for dialogs: https://processwire.com/blog/posts/processwire-3.0.61-master/#admin-and-ui This is how you can use them in your custom admin pages: In your module's php load the vex library (eg in the ready() method of your module - init() might not work as it might load too early!) $this->wire('modules')->get('JqueryUI')->use('vex'); Then in your javascript: // show confirm dialog ProcessWire.confirm('Are you sure you want to delete this E-Mail?', function() { // on confirm $i.removeClass('fa-trash').addClass('fa-spin fa-spinner'); $.get('./trash/?mailid=' + $a.data('mailid'), function() { $a.closest('.RockGridWrapper').find('.rockgridbutton.refresh').click(); }); }, function() { // on abort grid.api().deselectAll(); }); Result: I opened a pull request with a little fix for handling clicks on the CANCEL button. If you want to support it, give it a thumb: https://github.com/processwire/processwire/pull/108

It would be great if an optional text field will be added to the inputfield integer to add additional text next to the integer field (fe. weeks, days,..). Multilanguage support would be nice .

Yes this one works great. Thank you very much. ? R

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.)

Would be nice to have a timer that shows the time to auto-log out. This would prevent losing work when the user tries to save input while the session was terminated in between.

This is not intuitive. What does a red header mean? It could be anything. A timer that reads "Time until logout: 10 sec." would be the best from a UX perspective.

View my post as an example. Open the dev tools of your browser, inspect the code block element so you see its children (the spans making up the highlighted code). Select the string convertedFieldPairings)) from the forum post. As the Quote selection tooltip appears, observe what happens in your dev tools view. An empty span element has appeared inside the span containing the )) part of the string. If you now copy and paste to the Find field of your text editor already containing a block of code with the string, it will not find a match. I did not have the energy to inspect the clipboard to find what sort of an invisible character lurks inside the string.

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]

Is the site online? This works as well? $blog->renderPosts("include=all,limit=$limit");

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

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.

Thanks fly out for it. Going to edit some of my pages with this and report back.

Thanks @szabesz! @bernhard should I hide / delete that thread?

ACE also comes with a bunch of predefined PHP snippets. This will all be available in the next release of Tracy.

Sorry, not sure I understand how this makes things cross editor compatible. Honestly I think that all these should probably be in the core. After-all we have the actual snippets panel for you to define and use your own custom ones that others may not find useful.

Hey @bernhard and anyone else who might be interested. Following up on my thoughts over here: Here's my first test: This comes from a new file which currently contains: var getCodeSnippets = function() { return [ { content: 'd(\\$pages->find("template=\${1:basic-page}")->each("\${2:title}"));', name: 'find-pages', tabTrigger: 'pwfind' } ] }; I feel like there needs to be some thought put into how these should work and what the tabTrigger text should be. As you can see this one is about directly d() 'ing, but I am not sure whether it would be more versatile without that wrapping d(). Perhaps we could have both versions? Maybe we also want something that simply returns: foreach($pages->find("template=basic-page") as $p) { d($p); } I am really not sure what approach to take here. Also, do you guys want to contribute snippets to the Tracy core, or would you prefer being able to define your own in a file or in the config settings? Any thoughts? Thanks!

Haha - no, errant keyboard shortcut saved the post ? It's been "completed" now, although it really needs some work and should be moved to the docs site as I mentioned.

I'd love some help ? If people have ideas for other panels that would be brilliant. It's really very simple to get a panel working and what you do with it is up to you. Maybe I'll add this to the docs site (https://adrianbj.github.io/TracyDebugger/#/) at some point, or maybe someone could do that for me, but here are the really quick basics. Create a new file under the panels subdirectory named to match the name of your new panel, eg: MyNewPanel.php In that file have a class MyNewPanel that extends BasePanel, eg: class MyNewPanel extends BasePanel { Add getTab() method optional isAdditionalBar() method to check if the current call to the panel is from an AJAX or Redirect debug bar. Some panels are not relevant for these bars, so you can check that and return if you wish. timer() method to check how long it takes to generate this panel. return a span with title tag (for mouseover of the panel icon in the debug bar) with the SVG for the icon and a label. It's up to you to assign the SVG to that $this->icon variable. public function getTab() { if(\TracyDebugger::isAdditionalBar()) { return; } \Tracy\Debugger::timer('myNew'); return ' <span title="My Panel"> ' . $this->icon . (\TracyDebugger::getDataValue('showPanelLabels') ? ' My Panel' : '') . ' </span>'; } Add getPanel() method if this panel does work with additional bars, then check for this and add the name of the bar in parentheses in the <h1> title output should all be contained in a tracy-inner div use generatePanelFooter to create the ms/kb values in the footer of the panel. The last parameter (optional) is for a hash link to the docs website return - parent::loadResources() actually currently returns nothing but it's in the BasePanel class and may be used again at some point, so should be included in the return. The minify() method is not mandatory but I use it in some panels with a lot of embedded JS / HTML. Note that it's very rudimentary and currently is broken by inline comments in $out so be careful. public function getPanel() { $isAdditionalBar = \TracyDebugger::isAdditionalBar(); $out = ' <h1> <a title="My New"> ' . $this->icon . ' My New </a>' . ($isAdditionalBar ? ' ('.$isAdditionalBar.')' : '') . ' </h1> $out = '<div class="tracy-inner">'; $out .= 'whatever you want output in the panel'; $out .= \TracyDebugger::generatePanelFooter('myNew', \Tracy\Debugger::timer('myNew'), strlen($out), 'myNew'); $out .= '</div>'; return parent::loadResources() . \TracyDebugger::minify($out); } You have access to these color constants from the main \TracyDebugger class: const COLOR_LIGHTGREY = '#999999'; const COLOR_GREEN = '#009900'; const COLOR_NORMAL = '#354B60'; const COLOR_WARN = '#ff8309'; const COLOR_ALERT = '#cd1818'; You can access module config settings with: \TracyDebugger::getDataValue('settingName'); Once the panel is built, you can add it to Tracy here: https://github.com/adrianbj/TracyDebugger/blob/dd617b8ca8f450b8891ecacaef2b3949698fc126/TracyDebugger.module#L139-L169 That's a very rough first draft of what needs to happen. I think the best place to start is probably the MethodsInfoPanel.php file because it's so simple. This process has reminded me of just how messy some things are ?

Can confirm we've run into this same issue with the latest Bootstrap, latest PW and latest jQuery. We're currently doing this to ensure latest jQuery for the public and the compatible older version for editors. <?php //Load older version of jQuery for front end editor if ($user->isLoggedin()) { echo '<script src="https://ajax.googleapis.com/ajax/libs/jquery/2.1.3/jquery.min.js"></script>'; } else { echo '<script src="https://ajax.googleapis.com/ajax/libs/jquery/3.1.1/jquery.min.js"></script>'; } ?>

@bernhard https://processwire.com/talk/topic/8234-community-rules-guidelines/ quote: "No discussion of politics or religion anywhere on these forums including the Off Topic boards - there are many other websites where you may discuss these topics."

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

Welcome to the forums @mjut You need to use $config->scripts->add() for JS and $config->styles->add() for CSS .These need to be added before the controller.php $config->scripts->add($config->urls->templates . "scripts/admin.js"); $config->styles->add($config->urls->templates . "styles/admin.css"); // this comes last require($config->paths->adminTemplates . 'controller.php');

The WordPress plugin directory moved from download counts to active installs instead, since downloading does not mean it is actually being used. The problem with "active installs" is that the system needs to report it, which is both data leak to a third party and unnecessary requests to "some servers". I still think some sort of indicator of the "willingness / ability" of continued support would be good. By ability I mean the plugin is not abandoned, actively maintained, etc...

@Jules Vau Yes, thats correct. The setting in site/config.php overwrites the one in the wire directory.

The problem with such a system is that it'll always be skewed towards "does not work" simply because when a module does work people are very likely to move on without any feedback while the ones where there's a problem with the module are likely to complain somewhere.

Generally speaking your proposal could be useful, however, I think it is questionable whether it would work or not in practice. Just because a module works for someone, it does not mean it will work in a different environment. Also, ProcessWire's active online community is just not enough for this. The WordPress plugin directory used to have this feature and even they removed it, even though the WP ecosystem has far more users to utilize it, the low number of feedbacks made them realize it was not useful, I guess. Their new "Issues resolved in last two months" feature is more useful, I think. If the maintainer of the plugin/module is willing to support the users, that is a great sign in the first place.