bernhard

I'd also place a bd('render was called') directly in the core's render function to see if it gets executed. Or a die('render') there, whatever you want. Just to make sure the method is actually called (similar to what BitPoet said).

Thank you all for this little lesson ?

Found this by coincidence today, because they also have a great (looking) calendar library and all MIT and well documented: https://ui.toast.com/tui-chart/ I created a new thread for discussion:

Hi everybody, just found this one today by coincidence and it looks quite great: https://ui.toast.com/tui-chart/ Has anybody of you ever tried it? Even with nice export features! ? AND: Convert HTML Tables to charts: https://github.com/nhnent/tui.chart/blob/master/docs/wiki/import-chart-data-from-existing-table-element.md

PS: Maybe you want to look at this example: ?

Hi Brian, I wrote a tutorial about this some time ago: It's not complete and building Fieldtypes is not that easy... One important note: "Fieldtype" = the field, including all logic to save the value to the database, store it, etc "Inputfield" = the inputfield that is shown to the user (the UI) Often it is easier to modify an existing Inputfield or extend/modify one via hooks. You can see my first module for an example: Don't have more time right now, but maybe this already helps a little ?

Thx, seems I missed that ?

Sounds like a good plan ? I guess you already read about https://processwire.com/store/pro-cache/ ? ?

Maybe an extension like this can also help: https://chrome.google.com/webstore/detail/redirect-path/aomidfkchockcldhbkggjokdkkebmdll

I don't think that implementing another framework would be the way to go. I think we already have a great framework for editing our content: ProcessWire (the backend, meaning ProcessPageEdit). We have a great ecosystem with our fieldtypes and inputfields. It would take huge effort to rebuild all this on another framework (like grapejs). My approach would be to keep all blocks as pages with all the benefits we get from it (setting templates, having access control, etc). Those blocks could easily be edited right away in the backend, as they are pages. Just append ?modal=1 and you have exactly what you need: A UI to edit your block. No extra work, no breaking updates etc. Repeater and Repeater Matrix already show that this is possible. It would just need a new inputfield where we can drag&drop, copy, remove, create those blocks. @joshuag and @elabx have already shown that this kind of magic can be done in the pw backend: https://processwire.com/talk/topic/19557-designme-visually-layout-your-edit-screens-preview/ @joshuag and @elabx which library are you using for this drag&drop magic and also for the side panel?

Thank you Ryan for this information! What about all the open PR's? There are at the moment 50 of them open, some going back to 2016... Could @netcarver maybe also have an eye on them? Or do you prefer that we report feature requests also via the issues repository? thx ? PS: @kongondo recently shared how vscode integrates with pull requests. Don't know how PHPStorm handles this, but maybe VSCode can help checking all those open PRs:

I think this should be ->templates . 'inc because all paths should already have a trailing slash whereas __DIR__ does not have one. But I guess your example should also work ?

Sure, it's this rule of my frontend template:

Hey Adrian, --- SOLVED --- I have this code that returns an unexpected result. I don't know if that's related to tracy, so I apologize if it is not... I'm developing a module. $rc->step is a shopping cart step object and it is possible to attach forms to it. $step->forms is a WireArray. I add the form "test" to this WireArray but when I dump it, it shows just the name of the Form, whereas when I dump the single item via $step->forms->first() I get what I expect (an InputfieldForm object). On the "Full Object" tab the output is also as I'd expect it to be: I guess that's totally normal but I'd like to understand what's going on and why the form shows up as string in the Debug Info Tab, thx! Edit: Ok sorry for this post, but it might also be interesting for somebody else. The debuginfo returns the id or classname of any WireData objects: https://github.com/processwire/processwire/blob/master/wire/core/WireArray.php#L2442-L2446

Hi Robin, thx ? I think it would be nice to also list this sanitizer in the testAll() result, so I created a PR for it: https://github.com/Toutouwai/SanitizerTransliterate/pull/2 . Unfortunately this needs a fix in the core, so I also added a PR for this: https://github.com/processwire/processwire/pull/137 .

You could also try https://laragon.org/ instead of the devilbox. It's super easy and you would then know if the problem is the dev setup or something else.

Hi happywire, You should not have to change anything for multi-language-support on your system. Did you follow the instructions here exactly? https://processwire.com/docs/multi-language-support/multi-language-urls/ Last but not least: Welcome to PW and the forum ?

Thx, I'll do so ? Links are still working for me and I'm using them a lot ?

Yes, they are ? @Autofahrn this might also be a hint for you ?

Hey @adrian, would it be possible to make those logs linked to the file + line just like it is in the debug bar? It would be great to not only see the log of the call stack but also just click on the line and jump there in your IDE. Or is this a feature request for the tracy core and should be addressed to nette? thx

Thx @kongondo! I was close, but didn't find it ?

Hi everybody! PW somehow bypasses calls to a property of an object to an existing method with the same name. I think I read that some time ago but can't find the place in the code where this magic happens. Thx for your help ?

Closed this issue. I think Robin you are right with your variable assignment explanation ? THX!

No ? I could, but I think this should be the case by default and wanted to hear your opinions about that.

Hm... I thought when showing only one field on the page edit screen ( /page/edit/?id=123&field=yourfield ) it should display only this field after pagesave as well?! What do you think? At the moment when I save the page I'm redirected to the page edit screen showing ALL fields, not only the one that I requested initially. Shouldn't the page edit screen remember which field was shown and then only show this field after the page save? If you confirm this issue I'll post it on github, thx.