bernhard

Thx @matjazp , good spot! But I could not manage to make it work. What about the other Windows users? Am I the only one experiencing this problem?

Hi Mikie, the need is definitely there but I think Migrations is the best option already. See the blog post here: https://processwire.com/blog/posts/introduction-migrations-module/ There's also some discussion about that here: See especially my comment regarding automating PW's internal import/export featurs and the problems you might get: And also see the comments by Benjamin at the very end of his blog post.

Agree. Same here. But using a JSON-like approach can have severe disadvantages. You see that instantly when you try to export/import a set of templates and fields using PW's built in features. You'll likely end up with lots of warnings because PW does not know the correct order of adding all this stuff. Then it can easily happen that it tries to add a field to a template that is not yet created. You don't have this problem using migrations and actually it's not that hard, see the great blog post here: https://processwire.com/blog/posts/introduction-migrations-module/ @LostKobrakai what do you think of integrating migrations into tracy? I've created a field code section that takes the options of a field and turns it into code. I think it should be possible to take a similar approach and create migration files on the fly. So we could create a field, click "create field migration" and have a migration file with all the settings of the created field. This could especially be helpful to new users that are not familiar with all the options they get via the API. https://processwire.com/talk/topic/15959-image-field-creation-via-api-requiring-field-to-be-saved-before-use/?do=findComment&comment=173706

In my head this (and also the hints regarding the flags) was positive ? Not necessarily, especially if you throw in a disclaimer in there. Many times it is about the journey, not the destination. Whereas you set out to write a tutorial, from where I stand, that in itself is only part of the story. The other part of the story is what you are unconsciously telling newbies. That story says, hey, look guys, I found this new toy and look at what I can already do with it ?. Agree. That's what I like so much about the community. Throw in an idea and get valuable feedback instantly. There will also be times where you share something and get the hint that what you've done is already available in some way. At least that happened to me several times. Nothing about that is negative. It's just holding up the quality of the forum and clarifying why your approach might be different and better for special situations. I'd highly encourage you to continue writing tutorials. It will help you a lot and likely it will also help others. And nobody (here) knows everything. Except Ryan, of course ??

Has anybody of you also observed this error when installing a new dev version of PW? First, I thought the reason was my PW kickstart module. Then I thought it might be my upgrade of laragon. Then I thought it might have been a recent Win10 update. But now I found that the master version installs without any problems! Does anybody of you guys have the same setup and the same problem? Or maybe also on different setups? I want to collect more data and then file an issue on Github (if not already done)...

you might contact @Pete for that

Thx for the tutorial! You might re-think the approach of using flags for your language switcher. See http://www.flagsarenotlanguages.com/blog/ and http://www.flagsarenotlanguages.com/blog/why-flags-do-not-represent-language/ for example. Or this one: https://wplang.org/never-use-flags-language-selection/ Actually this comment proves the problem with flags... for me the comment sounded weird at first sight (because reading "my" flag as "wrong" felt strange ? ), but actually that's exactly the problem with flags and it might be better to have a text-only version. IMHO adding a language switcher is still too much hazzle... Maybe I'll build a small module for that as I'm building a multilang site right now anyhow. Or are there already solutions?

Glad you like it ? Good idea! I was also thinking of an AJAX version that grabs the latest requests every x seconds and updates the dumps. But that was too much effort for me for too little benefit. You might be faster as you know tracy a lot better than me. Yeah, I prefer array syntax. You can adjust as needed.

seems that google stole my idea: https://github.com/GoogleChromeLabs/ProjectVisBug thx for sharing @szabesz and @Robin S

Hi @adrian I just created a PR with two new panels. 1) A hello world panel to make it easier for others to create panels and contribute to your great module: 2) A WebHook panel that should make it easier to debug and develop webhook based functionality (like GIT webhooks or webhooks from foxycart or any other 3rd party service): Settings are simple: The panel shows the latest requests to templates you selected (in this screenshot the basic-page template was also enabled): You can also retrieve the data of logged requests, so it is easier to develop scripts without having to fire webhooks over and over again: Open to feedback, as always ? https://github.com/adrianbj/TracyDebugger/pull/30

Why? It is possible using url segments, but I think it would be better to create pages. You have all the benefits that pages bring with them, like security (see RobinS post below!!), proper url handling, maybe page path history if enabled etc...

Another option is using this in your template: <?php echo "my ajax response"; $this->halt(); That's similar to robin's suggestion but you can also use it without creating a separate file/template only for the ajax requests. For example you can send the ajax request to the page itself (the current url) and check if it is an ajax request or not. If it is an ajax request, you echo only the response, if not, you render the page (with the automatic appended main markup file). <?php if($config->ajax) { echo "my response"; $this->halt(); } ?> <region id="main"> <h1>my page markup</h1> <p>blablabla</p> </region> $this->halt() is better than die() because it will fire after render hooks for example and just stop rendering the template output while die() will stop all further executions.

AOS has this feature:

Thx Ivan, I was actually more interested in his/her/its response to my statement than in yours ? But yours is a very good one and shows the high quality of this community. Thx - I'm happy to be here and improve! Let's see what he/she/it found out about ecommerce with processwire so far - maybe he/she/it has some valuable information for us... ?

I'm not going to waste my time here...

Shouldn't, but my experience was different ? You cannot have different htaccess files for example. So using ProCache is all-or-nothing. Things like that bugged me. That's why I switched. Laragon makes it so easy to setup new projects... just create a new folder in C:/laragon/www and click reload. You'll have a new vhost, https support and you can even share that site via ngrok temporarily and publicly. That's great when you want to show something to a client or to try webhooks of a third party service.

It's really just adding the field to the finder:

Of course it works. If you don't like the wording "staging" you can also google for "migration live" https://www.google.com/search?q=site:processwire.com+migration+live

long time no see, great to have you back and thanks for sharing ?

Hello Bastien and welcome to the forum, there's no one single one-click solution for that, but we have several options. Did you already do some research? https://www.google.com/search?q=site:processwire.com+live+staging

Do you know RockFinder?

I always have a dev-section in my config where this would perfectly fit into:

I've also been struggling with this: Thats because the $page you want to check is the first argument of the HookEvent, so you need to apply it there, not at the first part, which is the class (or object). You can also do this:

You can define access per template, per field, per module, per code block (then, yes, you have to write that one if() else() manually). The pw backend is just a pw application itself. Whatever you can do there is also possible in your own applications.

https://processwire.com/api/ref/files/temp-dir/ So it should keep itself clean by default...