bernhard

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/

It does not work in general or when using SSH FS? I guess it is not possible to work via SSH FS at all, because the extension indexes all LOCAL workspace files on startup and then creates the intellisense. Thats the same with things like the "find in folder" feature. That's why I prefer to develop locally and not remotely over FTP/SSH like I did some months ago. Combining it with all the great git support of VSCode it's a great environment ?

Very interesting talk and a great website! https://www.ted.com/talks/anna_rosling_ronnlund_see_how_the_rest_of_the_world_lives_organized_by_income The website: https://www.dollarstreet.org/ I'm in no way related to this project, just thought it could be interesting to some of you ?

Everything works great here so far. I'm doing authentication with ssh keyfiles generated via git bash: https://git-scm.com/book/en/v2/Git-on-the-Server-Generating-Your-SSH-Public-Key These are my settings: The extensions do different things (as far as I understood)! FFHFS includes the file system of the remote server into your workspace. This is great to edit remote files on the fly. I just open the connection to my remote server, browse the tree down from the initial start at /var/www/vhosts, edit the file and save it. Perfect! The other extension is nice to connect to the server in the terminal. That can be handy to do a htop or to watch logfiles (tail -f /your/file): Left = vscode connected to my server, right = tracy console on a remote website using the file log function l(). That is great for monitoring resource intensive tasks like huge imports.

Same here!! Awesome!! This makes vscode even more brilliant ??? Let's continue to discuss this in the vscode thread:

Yeah, I actually think that is probably cleanest - thanks! awesome! thx ? Also, your Tracy Debugger module is an all-in-one Swiss Army Knife module to support development in general, so this feature would also be welcome. While I agree that it would be welcome I have to say that I haven't had a need for this module yet and will probably not have in the near future. I agree that it makes sense to integrate some modules into tracy, but I don't think it's a good idea to leave adrian alone with that effort. Even though he seems to be similar to ryan from a productivity point of view (do those two ever sleep? ?? ). I've done a little contribution once (field code) and it was not that hard. But maybe @adrian you could write up a little tutorial to show us how we can contribute to tracy. How everything plays together, what helpers are there, what css classes you use in general (or how we can inspect all that). Something like a quickstart of tracy extension building. Maybe this could make tracy more of a teamwork than an (absolutely awesome) one-man-show? Maybe tracy could even be built a little differently to support 3rd party modules. Just like you did recently with the admin actions module (https://processwire.com/talk/topic/14921-admin-actions/?do=findComment&amp;comment=173496). I'm not requesting this, I'm just thinking out loud here. Maybe I should - I have on occasion, but maybe I should more often! It would then also make sense to streamline the way of collaboration and have a standard workflow centralized on git.

Sure! I think we just have to start with one. All the others will come up automatically while we are developing. At least it is like this for me while working with vscode ? Knowing about the snippets I just create one whenever I come over something that I need over and over again. --- Back to VSCode --- Thx to @elabx I installed https://marketplace.visualstudio.com/items?itemName=Kelvin.vscode-sshfs#overview and it's absolutely brilliant. Just configure your remote servers and login easily from the command panel: Or via the GUI: I also installed this extension to open the terminal of my remote servers directly in vscode: https://marketplace.visualstudio.com/items?itemName=seanchann.sshlogin All those little tweaks of the last days makes me a lot more productive. And it's a lot more fun. Thx to everybody for the fruitful discussion! ?

Not sure. Didn't know ACE even supports snippets! Crazy ? Personally I don't use the file editor at all (yet?). I use the console a lot, but would have never needed one of those snippets inside the console (for example the module snippet here https://processwire.com/talk/topic/17550-visual-studio-code-for-processwire-developers/?do=findComment&amp;comment=173964 is mainly because of the intellisense hint, but we don't have that in ace, do we?). What I do a lot in the console is looping over pagearrays, so that could be a nice first testsnippet ?

Yes, that's handy ? If you add the "HookEvent" type definition to the parameter you even get intellisense:

snippet mania continues ? "Add hook with separate method": { "prefix": "hook", "body": [ "\\$this->wire->addHook$1('$2', \\$this, '$3');$0", "/**", " * $4", " */", "public function $3(HookEvent \\$event) {", " $5", "}", ], "description": "Add hook with separate method" }, "Add hook with closure": { "prefix": "hook", "body": [ "\\$this->wire->addHook$1('$2', function(HookEvent \\$event) {", " $0", "});", ], "description": "Add hook with closure" },

Do you have the wire folder in your project?

I vote for striped rows, no red, no green, just set the X to invisible or light grey. Checkmark means access, empty cell means no access. No warning colour but still easy to distinguish (better than without any colouring). @adrian why don't you create a temporary branch for such updates? We could then play around and give feedback or prs. Why sending zip files around?

I recently tend to do this, don't know about any best practises, though: That's the only thing where I'm not 100% happy so far. The available plugins that I tried are all somewhat clumsy/bloated/complicated. When I need to edit files directly I browse my server with WinSCP and then I can just double-click the file and it opens in VSCode. I can then edit and save this file from inside VScode and it gets uploaded automatically. For all other edits I switched to a git-setup, so I don't need direct edit via FTP any more. Meanwhile we also have Tracy+File Editor Panel for quick on-demand server edits.

I think it's good to have some color. What about the colors of the console - active = white, inactive = light blue: Understand. Thx ?

snippets are awesome! thx @kongondo, 2 more ? "Input get Variable": { "prefix": "get", "body": "\\$this->wire->input->get->$0", "description": "Input get Variable" }, "Input post Variable": { "prefix": "post", "body": "\\$this->wire->input->post->$0", "description": "Input post Variable" },

I strongly vote against using the red color at all. IMHO having "no access" colored red is wrong, if you want the role not to have access! So it would be indicating a problem where everything is actually fine.

Better imho! I think it could even be grey instead of orange. I'll play around with it one day, but atm I'm busy with other stuff and don't need to care about permissions a lot ? Maybe @tpr comes up with a good suggestion... This isn't about permissions in the sense you are talking about. It's just for these page permissions: https://github.com/processwire/processwire/blob/341342dc5b1c58012ae7cb26cffe2c57cd915552/wire/core/Page.php#L88-L107 Maybe it needs to be reimagined, but that was my initial goal for this. What does everyone think? Oh. I also thought it would list all available permissions. Didn't know about that one. You are absolutely right. Anyhow, it was just an idea. Personally I don't have a need at all for such a panel, but I'm quite sure it can be very handy to have one day...