bernhard

And a fourth: $this->wire->pages I prefer this version because you don't need to activate functionsapi (and the functions api should not be used in module development), it is multi instance proof and I get IntelliSense in my IDE Don't know which one is the best in terms of performance...

Hi eelkenet, nice find! Thx. Could you try adding this fieldtype here, then I could push an update: https://github.com/BernhardBaumrock/RockFinder/blob/master/RockFinder.module.php#L70 You can do a PR or just paste this line of code here in the forum. But I don't have a version to test here at the moment.

1 + 2 yes, but this one sounds strange. But it depends a lot on how you plan everything. I'd start with a simpler module first to get familiar with module development. This one would be a nice project to start with: You'd have some user input (teaser: image uploads can be tricky), some methods to generate markup, http requests via the API, but not all the complexity that you have in your full blown module. I'd always be available for help on the road ?

I've used Nette image functions for that once I needed it: https://doc.nette.org/en/2.4/images#toc-image-modification but your linked library looks more advanced ?

Sounds like a job for https://modules.processwire.com/modules/admin-restrict-branch/

Nice, was it easy to create the extension? Do you have any good links for tutorials for us?

Agree @Gadgetto what is your goal? What do you want to build? If we knew that it would be easier to help you. You have 3 main options to customize ProcessWire: Hooks in ready.php Very easy, but can get hard to maintain if you have lots of customizations https://processwire.com/blog/posts/processwire-2.6.7-core-updates-and-more/#new-core-files-for-site-hooks Regular modules You can include your own scripts, libraries, hooks etc. You can modify almost anything you want - for example inject custom scripts, modify rendering of fields in the admin, sending emails on special events in the frontend etc... https://github.com/ryancramerdesign/Helloworld Process modules They are used to build custom admin pages in the backend. See my forum + blog post to get a quick introduction. https://github.com/ryancramerdesign/ProcessHello

I don't think so, I think the best option would be a pull request ?

Maybe also there. The preview was also wrong on the client side, so there's something more to change in the js file.

Are you sure your hook gets triggered? Always proceed step by step. I usually start with a hook that only outputs "triggered" via tracy: bd("triggered!"); If you don't see the dump in the tracy bar, your hook does not fire and you have something else wrong (and that's the case here). Try this one and then update the inner code: $wire->addHookAfter('Pages::saveReady(template=product)', function($event) { $page = $event->arguments(0); // your logic here bd("hook fired!"); }); To update your field you don't need "setAndSave", just set your field's value like this: $page->yourfield = 'yourvalue'; That's it ?

I just looked at it and it not as easy as just changing that value. I've also found that annoying, but I guess the reason is not to get pixelated results...

I've added a section about how to grab the latest updates of processwire when you already have the setup shown in this tutorial.

Anybody of you ever came across this error? Seems to be a problem of PHP FPM: https://github.com/php/php-src/pull/3363 What is my alternative? @adrian we use this method in the tracy request logger, so this might need to be changed! Edit: if (!function_exists('getallheaders')) { function getallheaders() { $headers = []; foreach ($_SERVER as $name => $value) { if (substr($name, 0, 5) == 'HTTP_') { $headers[str_replace(' ', '-', ucwords(strtolower(str_replace('_', ' ', substr($name, 5)))))] = $value; } } return $headers; } } This seems to fix it. If anybody has a better solution please let me know.

Usually it's fine to put everything in BeforeInit. Sometimes AfterInit is needed (for example if you have dynamic columns calculated on runtime). Yes, that's fine. CSS should be loaded automatically: https://github.com/BernhardBaumrock/FieldtypeRockGrid/tree/master/plugins#creating-custom-plugins; I don't know why your css classes are overwritten, sorry. See the readme here https://github.com/BernhardBaumrock/FieldtypeRockGrid/tree/master/coldefs And a very simple example https://github.com/BernhardBaumrock/FieldtypeRockGrid/blob/master/coldefs/fixedWidth.js You can then just use col = RockGrid.colDefs.yourColdefName(col); in BeforeInit

I don't think there is one good practise. There was some discussion about different approaches for page builder like setups lately. Repeater matrix or using regular pages are for sure a good solution.

This stupid bootstrap div class="row" thing is really one of the main reasons why I love uikit's grid system so much. There it is as easy as this: <div class="uk-child-width-1-1 uk-child-width-1-2@s uk-child-width-1-3@m" uk-grid> <div>item</div> <div>item</div> <div>item</div> <div>item</div> <div>item</div> <div>item</div> <div>item</div> <div>item</div> <div>item</div> </div> And you instantly get a nice grid that is stacked on mobile (full with), 2-column on small devices upwards and 3-column on medium devices upwards. No html-row elements and lots of further options (divider, modifying grid item order responsively etc). But as you are limited to bootstrap I guess it might be worth taking a look at http://arnaudleray.github.io/pocketgrid/ to make your life easier.

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/