bernhard

I could maybe do that for RequestLogger over christmas...

Thx for sharing that @Beluga! Do you think the aggrid core team could be interested in your solution? Maybe they can implement it somehow?

We also have the language alternate fields. On mobile so you might want to use Google

Adrian please save your time and forget about the open in new window stuff. The new options are much better!

I've just created a frontendtheming module that does take the source files of uikit (in a separate module to be up-/downgradeable), injects custom LESS files as you want and parses it on the fly with a PHP less parser. That works really well. It's not something I can release soon, but maybe someone wants to take the same approach for the backend theme. Just had a look and this approach would also be possible for the backend as Ryan is also using LESS to compile the pw backend css: https://github.com/ryancramerdesign/AdminThemeUikit/blob/master/uikit/custom/pw.less https://github.com/ryancramerdesign/AdminThemeUikit#uikit-css-development-with-this-admin-theme

Thx arjen, I like tutorials that show things step by step, including possible warnings, how to read and how to fix them. Shortcuts are nice when you have some experience but they can be a pain in tutorials... Having said that, I also have to admit that I'm still just scratching the surface of GIT and I like to do things step-by-step myself ?

Would be interested in some examples ? Thx for the elaborate answer!

1) Setup the necessary GIT Repos Fork ProcessWire: https://github.com/processwire/processwire Clone your fork to your local dev environment (I named my folder processwire-fork): git clone git@github.com:BernhardBaumrock/processwire.git . To be able to keep the fork in sync with ProcessWire we need to set the upstream, because currently it only points to the fork: git remote -v // result: origin git@github.com:BernhardBaumrock/processwire.git (fetch) origin git@github.com:BernhardBaumrock/processwire.git (push) git remote add upstream https://github.com/processwire/processwire.git Now fetch the upstream: git fetch upstream As you can see we are still on the master branch (of the fork). We want to work on the dev branch. In VSCode you instantly see all the available branches and which branch you are on: But you can also use the console: git checkout origin/dev Ok, as we did not have a local dev branch yet, we get this warning: So we do what git tells us: git checkout -b dev We are almost ready to go and we can check if it is working by simply modifying the index.php file: Nice! Index.php shows up in the git panel on the left side under "changes" and clicking on it we get a nice diff (if you haven't tried VSCode yet, give it a go and see the corresponding forum thread here). 2) Setup a running ProcessWire instance Now that we have a fresh fork of ProcessWire we want to contribute something to the project. But how? We need to install ProcessWire first to test everything, right? But we don't want to copy over all edited files manually, do we? Symlinks to the rescue. We just install ProcessWire in another folder (in my case I use /www/processwire) and then we replace the /wire folder of the running instance by a symlink to the wire folder inside the fork. Let's try that via CMD: If you have your folders on the C:/ drive you might need to run CMD as admin. We are ready for our first contribution! ? This is how my ProcessWire installation looks like: Note these things: We are inside "processwire", not "processwire-fork" There is no .git folder, meaning this instance is not under version control The wire folder is symlinked. And this folder IS under version control, but in another folder (processwire-fork) If you want to contribute to something outside of the wire folder, just symlink these files as well (eg index.php or .htaccess)... 3) Example PR - Coding You might have seen this discussion about FieldtypeDecimal for ProcessWire: https://github.com/processwire/processwire-requests/issues/126 I thought it would make sense to have at least a comment in FieldtypeFloat that you can run into troubles when using FieldtypeFloat in some situations. I then wanted to make a PR and since I don't do that every day it's always a kind of hurdle. That's also a reason why I created this tutorial, as a side note ? Ok, we want to add some comments to FieldtypeFloat, so we open up the forked repository of ProcessWire in VSCode. This is important! We work on the forked folder "processwire-fork" but we TEST everything in the browser from the test-instance in the folder "processwire". This might be a little confusing at first, but we are not working on a local project, we are working on the core. We see that we are on the fork In the folder is a clone of ProcessWire that is NOT installed yet We are on the DEV branch and this branch is not yet uploaded to our git account (the cloud symbol shows this) Important: Before you start your changes you always need to make sure that you have the latest version of ProcessWire in your folder! This is done by pulling a branch from your upstream. If you want to work on different contributions it might make sense to create a separate branch for each modification. See this example: The commands are: git checkout -b FieldtypeFloat-comments git pull upstream dev Using VSCode it might be easier to create new branches or switch between existing ones: Just saying ? Now the changes: We open FieldtypeFloat.php and add our comments. We instantly see our changes in VSCode: Or if you prefer you can also open the diff: The Result: When we are happy with our changes we can commit them (either using the VSCode UI or the command line): git add . git commit -m "your commit message" 4) Submitting the PR First, we need to upload the new branch to our forked repo: git push -u origin FieldtypeFloat-comments See the first command and the comment what happens if you don't define the remote branch. Now head over to your github account and click to create the PR: Just make sure that you send your pull request to the dev branch! Check if everything is correct: And voilà: https://github.com/processwire/processwire/pull/130 That's how I do it. If you know better ways or have any suggestions for improvements please let me know ? -------------------- update ----------------------- 5) Updating the fork If you already have your setup and just want to grab the latest version of ProcessWire into your fork, this is what you have to do: git fetch --all As you can see it grabs the new dev version from the upstream repo. But if you go back to the running PW site's upgrades page you'll see that you are still on the old version. We need to merge the changes into our branch. But before we do that, we make sure we are on our local dev branch: git checkout dev git merge upstream/dev Now head over to your sites admin and you'll see that we merged the changes: You can now continue by creating a new branch and working on it as shown in section 3.

I strongly support @LostKobrakai 's approach. JSON looks nice at first sight, but we already have a powerful API and we MUST use it. JSON is basically only another syntax. It's some kind of an "API" but a lot less powerful. It's also not easier IMHO, because using the API we have intellisense in our IDE. You don't get that when using JSON. Updates are a pain using JSON. It might be easy to setup new fields and templates, but what if you want to set a new field width in template context? How would that look like in JSON? It's as easy as that with migrations: $this->editInTemplateContext('basic-page', 'headline', function(Field $f) { $f->columnWidth = '50'; }); The example is also in the screencast. Another one: How would you create pages in JSON? We know the problem because we already have this tool built into PW. You'll always end up with collision warnings needing some more user input (add this field after that, do you want to overwrite or rename etc etc). You can handle all that with migrations. It is also quite easy to find the correct property names now as we have Tracy (see end of screencast). And it's also easy with intellisense in your IDE. Where I see potential for the future is that migrations could be used in other modules as well. I think it would make sense to move the migrations feature into the core to have a solid base that is consistant, bullet-proof and maintained together with PW. I think it would make sense to have migrations inside modules, not only at one place. We could then build modules, ship some migrations with it (eg for creating pages and fields) and run / revert those migrations from within the module. I think that solution would be way better than the JSON config approach and I'd love to see this as a huge update to PW in 2019 @ryan ? PS: Also take a look at the great docs and examples here: https://lostkobrakai.github.io/Migrations/examples/

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.