Leaderboard

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.

You can use this to resize via mouse (using jQuery UI Resizable which seems to be present in the PW admin). I haven't checked fieldsets, I've updated the code, it's working fine with fieldsets too.

@teppo <aside>Dude, you threw me off with that new avatar ?. I was like who's this replying to Teppo's post; I haven't 'seen' them before...</aside>

v0.1.6 has a new config option to choose Name or Label as the primary identifier for fields. Whichever isn't chosen becomes the title attribute shown on hover. Thanks @tpr - in v0.1.6 I added your drag resizing code mostly unchanged. It's not something I think I'll use myself but very cool nonetheless.

What @LostKobrakai said. The short answer to "what can Laravel and Symfony do that PW cannot" is "nothing", but in my opinion that's not really the question you should be asking – rather you should ask what it is that they are better suited for than ProcessWire ? In my experience (based on other web application frameworks, not Laravel or Symfony specifically) the biggest day-to-day difference is exactly the general purpose nature of web application frameworks: ProcessWire is specialised to content management, hence it's a "content management framework" (CMF) rather than a "web application framework" (WAF). In some regards ProcessWire has more built-in stuff than WAF's, and in some regards it has less – just like LostKobrakai pointed out above ? Some examples of the differences include routing and project structure / application architecture: Although this might be changing, not too long ago it seemed that every PHP framework enforced MVC pattern, or at least recommended it. ProcessWire, on the other hand, doesn't (natively) include anything like that. The default, out-of-the-box approach ("output strategy") is a straightforward solution where single template file contains (or rather can contain – of course you can also split it into multiple include files) all the code required by said template. Similarly in ProcessWire URLs are by default routed to pages, and although custom routing is technically possible using URL segments, there's no real, robust routing library included, other than what Pages / PagesFiles / Process modules require to function properly. While it's true that you can build pretty much anything on top of ProcessWire (or WordPress, or Drupal, or any remotely flexible CMS/CMF for that matter), whether that's a good idea depends on a number of factors. For an example, if there's no content to manage – or the content you have requires a very specific type of structure or storage mechanism or something – a general purpose WAF may provide you with more suitable tools than most CMS/CMF platforms ? Just for the record, https://madewithlaravel.com/ has quite a few examples of stuff built with Laravel. Some could've made at least as much sense as ProcessWire projects, while others are clearly better suited for a WAF.

Well it took several hours of discussions with @bernhard and lots of back and forwards on the best way to do things, but we've finally committed the "WebHooks" panel he posted about above. It's now called the Request Logger panel because in reality it is logging requests to a page on your site - who knows whether it's really a "webhook" request or something else. Instructions 1) In the PW admin, edit the page you want to log incoming requests for. 2) Open the Request Logger panel. 3) Click the "Enable logging on this page" button. 4) Send a request to that page. This may be something like a confirmation of payment webhook call from Paypal etc. 5) Reload the edit page in the PW admin to see the logged request. The reason we say to edit the page, rather than visit it on the frontend is because visiting the page would result in a logged request. Note that you can easily test incoming requests using the Postman app (https://www.getpostman.com/). You can choose POST or GET and under "Body" you'll want to specify Raw / JSON You'll notice the json supplied in the Postman Body is what shows up in the Request Logger panel under "input" and "inputParsed". This is all well and good, but here's where the magic really comes in ? There is a new getRequestData() method added to $page so you can get the logged data in your code. You can get logged requests by: ID (shown in the title of the logged entry in the Request Logger panel) ALL requests (an array of all logged requests for the page) The last logged request by passing "true" The current live request This allows you to have access to the data sent by the webhook without constantly having to trigger it each time - ie no need to continually make test payments over and over as you refine and debug the your scripts that consume/parse this data! You can even make use of $page->getRequestData() in your final live code if you want - this does not rely on Tracy being enabled - it just has to be installed. So you could potentially execute one request and then use the "true" option while testing, and then when you're ready to go live, you can remove the "true" so it returns the live request. There is a config setting to determine whether this method returns an array or an object. Please take it for a test drive and let us know what you think! @bernhard - did I miss anything worth mentioning?

Thanks bernard, great writeup! In case it helps someone else, here's the guides I use(which are very similar) https://akrabat.com/the-beginners-guide-to-contributing-to-a-github-project/ https://akrabat.com/the-beginners-guide-to-rebasing-your-pr/ - the followup

Browse to madewithlaravel.com and check out pretty much anything that doesn't manage data, and/or doesn't produce output. From the front page: Clockwork, Fractal, Vessel, etc. Also anything that is more "component", intended to be used within other applications, rather than a "full-blown application" itself ? Perhaps a more familiar example would be wireshell.pw. While it's not built using a WAF, it does make use of Symfony components. Could it be built using ProcessWire? In theory yes. Would it benefit from being powered by ProcessWire? Not really.

In my opinion you can build amazing backend web applications with ProcessWire, as I already built some with it. A big difference is, that most frameworks like Laravel do not come with a backend. So you have to use Laravel Nova or Voyager to create a nice looking backend. ProcessWire on the other hand comes with a nice customizable backend. Depending of the type of backend/application you build, you have to "bend" the PW backend to your likings, this includes removing features, or writing modules to get the behaviour you would like (for example restricting users to a branch). In other frameworks you start with "nothing" or a boilerplate and develop the features you like, which might be more work, but you get a very tailored application. You could do this with ProcessWire also, if you like, because you don't have to use the included backend. What I was missing for example in Laravel Voyager were field dependencies, which hides or shows fields depending on the state of another field. One big drawback of ProcessWire is the sync between a live server and your dev server. Because ProcessWire does not distinguish between structural and content pages (or I am not aware of it), updating a live server with changes you made on dev is very cumbersome. There is some discussion about this going on here on the forums: or here

Thanks for the fix. Actually the block level field identifier was what made me think that the tooltip was intended to be triggered on the whole block. As it is now on the far right side there is no indication where the tooltip will be triggered when you move the mouse. Perhaps it would be better to restrict it to the identifer text only, or prepending an info icon. Anyway, no biggie. I created a PR to disallow less then 10% field widths, because PW doesn't allow that: TFWs allowed setting lower percentages and those values were kept. However, such fields were defaulting to 100%, just like the field's width sliders on the edit field page.

This seems like a pretty good approach to both inline and CSS images: https://css-tricks.com/using-webp-images/ For inline images in a textarea a textformatter module could prepare the picture/srcset.

I experienced the same issue using the PW Upgrades module. I think it is Windows-specific and relates to a bug introduced by Ryan trying to resolve this issue: https://github.com/processwire/processwire-issues/issues/704 In recent dev versions PW is not able to delete files on Windows. See also:

I can confirm the same issue on Windows with recent dev versions. I think the problem relates to commits made in an attempt to fix this issue: https://github.com/processwire/processwire-issues/issues/704

Awesome work @bernhard and @adrian. Hopefully one day I'll get to test all these wonderful stuff being added. That might be a while, given that it's only today that I discovered the Tracy console can be opened in a new window! ?

Ah, a quick test showed that I can use this already with my local dev environment: $cai3 = $page->croppable_images->first()->getCrop('thumb100'); // WebP with GD-lib bundled with PHP 7 $im = imagecreatefromjpeg($cai3->filename); imagewebp($im, str_replace('.jpg', '.webp', $cai3->filename)); imagedestroy($im); ?

Some thoughts / infos in no special order: it has to be a module because all our image engines are modules. As long as the GD library does not support webp, it cannot be a core fileformat. I haven't tested anything in regard of webp til now. If imagick supports it as outputformat, I can start testing it as a image engine module that extends the core imagick module to provide something like a options variable to return the final variation image as webp. Earliest start can be around christmas time 2018.

Nice one @bernhard! If you have a single remote you can also ... git fetch ... first afterwards you can safely git checkout dev If you have multiple remotes you can ... git checkout -b dev origin/dev ... in one command. No creepy warning about being in detached HEAD mode.

... Kongondo too ?

As @adrian said – that's why AdminThemeBoss is built just as a CSS Layer on replacing the AdminThemeUikit CSS… But the way to go there is pretty difficult – with the current AdminThemeUikit it's hard to find the relevant LESS variables and use these or override stuff... Also hooking into AdminThemeUikit and replacing or extending stuff is not strait forward. Would love to see more in this regard, a Theme that is built with extensibility in mind.

Laravel or Symfony are first and foremost general purpose frameworks, while ProcessWire is first and foremost a CMS with the benefit of having a small general purpose framework beneath. The difference lies mostly in what you get out of the box and less so in what you can build with it. E.g. laravel/symfony have components for using queues, processwire doesn't, laravel/symfony have a templating system, ProcessWire doesn't (it's php), …. On the other hand ProcessWire comes with a flexible backend to hook into, laravel/symfony don't have that (laravel nova would be similar, but costs money).

+1

One of PW 3.010's major novelty was the introduction of Horst's new image resizing engine that uses ImageMagick. Now I understand that ImageMagick can convert images to Webp, the image format that Google says can reduce image size up to 34% compared to JPEG. Mozilla is apparently adding support to Firefox, and even the Safari team is playing with it, so it looks like Webp is soon going to be available in most major browsers. If Horst's module can be extended to add Webp conversion, that would be a great addition to PW's already very powerful image manipulation arsenal. I'm currently using the free ImageEngine Lite to serve Webp images to supporting browsers, and the results are impressive. I routinely get images that are between 25 and 60% smaller compared to JPEG, with the same visual quality. I would love to eliminate the need to rely on a third-party service though.

Did any one tried to integrate "WordPress New Editor" into ProcessWire ?? I did some searches and I found this Repo on Github: https://github.com/front/drupal-gutenberg Which allows Drupal Users to use Gutenberg. Any Thoughts ?

I think I'll leave it for now unless I hear from others who are finding it confusing. I didn't know PW had that restriction. Thanks, have merged in v0.1.8.

Probably not news to anyone familiar with webp, but I just tried it and the reduction in file size is impressive indeed. WEBP image on the left generated from variation with 100% quality, JPG on the right with default PW quality setting. Interesting that there is a slight but perceptible difference in colour though.

No. It means I'm using different versions of Tracy on different sites (multisite) on the same machine ?. Edit: Maybe this old version is why Tracy is not appearing in modal windows or that has always been the case?

Maybe SessionHandlerDB will behave differently and therefore be an alternative.

New version of Tracy includes 4.7.0

I'm using the icon; it's not hidden for me. On this machine I'm running 4.8.24 The new window came handy today. I needed to see different windows at the same time and docked, the console was in the way, plus I just couldn't make it bigger. I've done it before, but can't remember how :-).

Perhaps a minor bug: if I select "Label" as the primary identifier then no text is shown for the field. Imho the module should display the primary identifier, and if not available, the name (as that's always available). Plus it would be better to put the "title" tag on the main div (.tfw-item) so it would be always available. This introduces another issue: hovering on an input the tooltip still shows but you can disable it by adding an empty title tag to the input (at least it works for Chrome).

@horst Niiiice! I've just tried on a live server with PHP 7.2 installed. Your code works great. The Webp image is successfully generated from the original JPEG. Here's how I've echoed it: $main_image = $page->image->first->getCrop('grande'); // (using Horst's Croppable Image module in this example) $image = imagecreatefromjpeg($main_image->filename); imagewebp($image, str_replace('.jpg', '.webp', $main_image->filename)); imagedestroy($image); $webp_image = str_replace('.jpg', '.webp', $main_image->url); echo "<img class='responsive-image' src='$webp_image' alt=''>"; Note: for those using the Plesk control panel, webp support for GD seems to be disabled by default.

Hey @Tom. - I am not sure your exact goal here - not sure if the session storage is for production use, or just while developing/testing, but @bernhard and I just put this together: https://processwire.com/talk/topic/12208-tracy-debugger/?do=findComment&amp;comment=176842 - which came about while he was working with foxycart and since you are as well, I just thought it might be worth mentioning ?

GD supports webp: http://php.net/manual/en/image.installation.php

Wow! s'all am sayin ??

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

Yes, imagemagick supports it: https://imagemagick.org/script/webp.php Thanks @horst!!

Carbon Copy Cloner 20% off (November 28-30): https://bombich.com/

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

This module is currently broken. I think it was made with version 1 of the Mollie API in mind. If you use it together with the current version of the Mollie API (v2), it does not work at all. Here's a discription of the API changes from v1 to v2 that I think the developer of this module may want to take a look at.

You can achieve this using the "Custom PHP code" option for the Page Reference fields, but your site editors will need to save the page after making a selection in each Page Reference field in order for the selected items to be removed from the options of the other fields. Example hook in /site/ready.php: $wire->addHookAfter('InputfieldPage::getSelectablePages', function(Hookevent $event) { $page = $event->arguments(0); // The page being edited if($event->object->hasField == 'colours') { // Exclude options selected in field colours_2 $event->return = $event->pages->find("template=colour, id!={$page->colours_2}"); } if($event->object->hasField == 'colours_2') { // Exclude options selected in field colours $event->return = $event->pages->find("template=colour, id!={$page->colours}"); } }); Result in Page Edit:

The problem I have with static json or yaml setup files is that it's not migration. It's just a static set of fields/templates/… without knowledge of what came before or after. I have almost always user generated data associated to a certain setup. So when changing the setup there's often the need for something to happen with said data as well, like when adding a new intro field for blog posts one might want to put the first paragraph of existing posts from the body into the intro. Craft seems to see their addition just as replacement of sharing db dumps and it's essentially that. If environments never concurrently change in terms of content, but just structure then some version controlled file for the structure is better than a db dump, which contains both structure and content. But as soon as the content is also affected by changes it's no longer a solution.

I'm new to PW and just learning hooks myself but this is how I got the loginSuccess hook to work in site/_init.php. Note this only sets a session variable but it is proof that the hook is there and working. wire()->addHook('LoginRegister::loginSuccess', function($event) { // outside a class $session = wire('session'); $session->set('Login_Register_hook', 'success'); }); output: [Login_Register_hook] => success wire()->addHook('LoginRegister::loginFail', function($event) { $session = wire('session'); $session->set('Login_Register_hook', 'failure'); }); output: [Login_Register_hook] => failure

Just found nolt.io by coincidence and tried it out... It's really simple to setup a Roadmap with voting functionality: https://53261ae5.nolt.io/ What do you think? Could that be useful?

When reading all the facts and ideas in the posts above, I think it would be a good idea to let the forum software as is with only following additions: 1) add one or more voting or tagging categories to the posts 2) provide a link to every thread that opens a popup with a hirarchical list or lists for the voting / tagging categories (number of votes followed by the link to the post) (This link should be reachable from every thread page) 3) a button to prefix the topic's title with either [open], [solved], [closed], etc... @Pete what do you think? Handling those votes with an own script and own db / db-table(s), reduces the changes to the forums software to only inject the new voting / tagging buttons with ajax action to the external script, plus injecting a link to popup the rendered hirarchical jump list. This way, the additional functionality would be save on changes of the forums software.

@Pete I created an online test version of the actual forum, and the user can choose if he wants to sort by date or by votes. So the upvoted answer is not pulled out of context. I did not try to mark one answer as correct yet, will do later. If you want, I can give you the admin account and URL so you can test for yourself. There is an option in the admin to set the default sort order, but as I logged in as a normal user, it seemed to not respect this order and I had to choose "Sort by date" by myself. Maybe I did something wrong. Have to take a look at it.

I agree - I am not saying that something like it shouldn't be implemented - just wanted to expand on @kongondo's answer and explain what we found about it that didn't work well, and the way it was, it really wasn't helpful. Maybe Ryan could reconsider it (or another similar approach) with the website revamp.

I really like translations in ProcessWire but agree, a way to provide centralised community translations for the system and modules would be great. If I remember the software correctly, it should not be too complicated to set something up using Weblate. Would this be something there's interest in?

Hi all, I've had a request from a client (that I built a multi language PW site for) to change the text colours in the language tabs when they are not completed. Essentially they were having difficulty detecting which languages had content and which didn't when scanning the page in admin. Now I know this means changing Admin template files which I hate doing but the client was insistent. Looking through I found this in the module CSS and changed the colour for empty content to red thus: wire/modules/LanguageSupport/LanguageTabs.css - line 61 .langTabEmpty a { opacity: 0.7; font-weight: normal !important; color: #ff0000 !important; /* I changed the colour here */ } Now we get this when editing, the red indicating no translated text has been added: I think is a better UX. However, when adding alt text to images in an image field the same CSS colour change doesn't apply. Looking at the CSS the .langTabEmpty class isn't added to these tabs on the image field. Could this be considered as an improvement at next module upgrade time please? Thanks as always!

An update was made to the module to fix this; Please proceed cautiously and if you experience any errors or unexpected behavior let me know and revert to the previous version. bunch of things got moved around in the module; testing was done and all seems to work fine, but due to the large number of changes in this update, caution is advised;

There are usually 2 menu types on most sites. Let me generalise here a bit. You've got the top navigation which tends to be global. It's on every page and usually accompanies the company logo. Then you've got the side navigation which is contextual or based on the section the user is currently within. I'm assuming you're asking how you your client can pick which links / pages are used on the top navigation? Create a field called top_navigation or something meaningful to you and your clients Set it to Type=Page type (Basics Tab) Make it Multiple Pages (Details Tab) Assign it PageListMultipleSelect+ win the Input field type (Input tab) Finally, associate this naviagtion field with a template. You can just assign it to the homepage or you could create a new page called Site Settings or Navigation. Just tell your client this is the place to manage their top menu. Here's a screengrab of how it should look.