Leaderboard

Also worth noting that there is a 7 page book related to the rejection craze of jQuery and other libraries: https://www.oreilly.com/programming/free/native-javascript-apis.csp Quotes: "If you’re using native APIs in your application logic, you can’t help but know what browser is being used because you need to account for browser differences. That means your application logic will always need to be updated as new browsers and new browser versions are released. That’s a recipe for disaster. ... You should absolutely be using a JavaScript library to abstract away browser differences for you. ... Libraries like jQuery, YUI, and Dojo abstract away browser differences behind facades, which allow you to focus on building your application logic in a browser-agnostic way. ... So, keep using your favorite JavaScript library. Don’t be tempted by the draw of native APIs simply because you can avoid downloading an external library. Using native APIs comes with a high cost of maintainability down the road." People write spaghetti code because they do not know JavaScript well enough and/or do not use appropriate design patterns, which is not jQuery's or other libraries' fault. One can just as well produce unmaintainable code by using any framework out there. Here is the case of UIkit 3 which relies on its own 132k JS library which is only partially documented: https://github.com/uikit/uikit-site/blob/feature/js-utils/docs/pages/javascript-utilities.md They say: "...allow you to write simplified Vanilla JavaScript and replace the most common functions of jQuery" So they got rid of jQuery by partially re-implementing its features. Good to know... Now if I add jQuery I have overlapping feature sets and the visitor of the site has to download more assets ? Is it an improvement? At the same time the current full version of jQuery (3.3.1) is 87k and one can use versions leaving out features not needed (say AJAX or effects if not used on a site), so it can further be trimmed if the projects allows. Introducing a mature and maintained JS library called JsViews: Currently, I have started to build upon a library which can either be used along with jQuery or without it: https://www.jsviews.com/ It is from one of the jQuery authors. Worth checking out the examples, eg.: https://www.jsviews.com/#samples/computed/team-manager JsViews can be used without precompiled JS templating – so it is easy to get started – and it is still very performant that way. One can also use a builder to precompile the templates if needed (think of the needs of overly complex JS apps and NOT websites). By using JsViews one can rely on declarative programming and build upon design patterns built in. By adding jQuery to it, code becomes shorter, easier to read and maintain.

Most of my clients already have some sort of webhosting and only in very few cases it needs an update in terms of more features like SSL and similar things. If they don't have webhosting I recommend a middle-sized shared hosting from trusted providers. An all-in-one package works in almost every situation. Domain + Hosting + E-Mail management = ~15 EUR/month that's it and all they need. In the past I have had root servers and VPS to host client projects. It was a nice option, additional money, and a good way to keep clients close. But as regulations and laws changed over the past years I decided to stop offering hosting services. Hosting isn't that expensive anymore and you find really good options out there. Hosting providers are there for a reason. They take the hassle away from me. If your client already has a website, take a look at their web analytics to see how much traffic there is. You can then decide which way to go and what package might be a good deal if there are performance issues. As far as I can say... a good ProcessWire site doesn't need that much of a high performance hosting. Unless you can't use ProCache even a super cheap $3 shared hosting might work well enough. ProcessWire sites with ProCache, almost no real-time-database interactions, and only a few forms have a nice small footprint.

This is the thread for the old version of RockMigrations wich is deprecated now and has been renamed to RockMigrations1 Here is the latest version of RockMigrations: -- Old post from 2019 -- https://github.com/baumrock/RockMigrations1 Quickstart First make sure you have backups of your database!! Install RockMigrations Create this ready.php <?php /** @var RockMigrations1 $rm */ $rm = $this->wire('modules')->get('RockMigrations1'); $rm->migrate([ 'fields' => [ 'myfield' => ['type' => 'text'], ], 'templates' => [ 'mytemplate' => [], ], ]); Open your PW Backend and you'll see the new field and new template! Now add the new field to the template: <?php /** @var RockMigrations1 $rm */ $rm = $this->wire('modules')->get('RockMigrations1'); $rm->migrate([ 'fields' => [ 'myfield' => ['type' => 'text'], ], 'templates' => [ 'mytemplate' => [ 'fields' => [ 'title', 'myfield', ], ], ], ]); Reload your backend and inspect the template: Now let's add a label for our new field and make title+myfield 50% width: <?php /** @var RockMigrations1 $rm */ $rm = $this->wire('modules')->get('RockMigrations1'); $rm->migrate([ 'fields' => [ 'myfield' => [ 'type' => 'text', 'label' => 'My Field Label', ], ], 'templates' => [ 'mytemplate' => [ 'fields' => [ 'title' => ['columnWidth' => 50], 'myfield' => ['columnWidth' => 50], ], ], ], ]); That's all the magic! You can easily lookup all necessary properties in Tracy Debugger: Let us add a Textformatter as an example! Add the textformatter via the PW backend (not via RM), save the field and inspect via Tracy: Now add this data to your migration: <?php /** @var RockMigrations1 $rm */ $rm = $this->wire('modules')->get('RockMigrations1'); $rm->migrate([ 'fields' => [ 'myfield' => [ 'type' => 'text', 'label' => 'My Field Label', 'textformatters' => [ 'TextformatterEntities', ], ], ], 'templates' => [ 'mytemplate' => [ 'fields' => [ 'title' => ['columnWidth' => 50], 'myfield' => ['columnWidth' => 50], ], ], ], ]); Ok maybe you noticed that migrations are now running on every request which may slow down your site a lot! RM2 will have a feature to automatically detect changes and fire migrations automatically. RM1 does not have this feature, but I've used a technique in all my projects that fires migrations on every modules refresh. Simply wrap the migration in a fireOnRefresh method call: <?php /** @var RockMigrations1 $rm */ $rm = $this->wire('modules')->get('RockMigrations1'); $rm->fireOnRefresh(function() use($rm) { $rm->migrate([ 'fields' => [ 'myfield' => [ 'type' => 'text', 'label' => 'My Field Label', 'textformatters' => [ 'TextformatterEntities', ], ], ], 'templates' => [ 'mytemplate' => [ 'fields' => [ 'title' => ['columnWidth' => 50], 'myfield' => ['columnWidth' => 50], ], ], ], ]); }); How to remove things you created before you may ask? Use the declarative syntax: <?php /** @var RockMigrations1 $rm */ $rm = $this->wire('modules')->get('RockMigrations1'); $rm->fireOnRefresh(function() use($rm) { $rm->deleteField('myfield'); $rm->deleteTemplate('mytemplate'); }); Refresh your backend and everything is as it was before! PS: Make sure you have proper Intellisense support in your IDE to get instant help:

A) there are no negative implications using CURL instead of WireHttp, if you handle your sent and received files / data correct. B) WireHttp itself makes use of CURL. Besides "CURL" It also uses "fopen" and "socket". The default usage is set to "auto", but you can explicitly tell it which one you prefer, by passing an options array as fourth param to its send() method. For example, this setting want to use "fopen" with a fallback to "socket": $response = $http->send($url, $data, 'POST', ['use' => 'fopen', 'fallback' => 'socket']); This one only would use CURL: $response = $http->send($url, $data, 'POST', ['use' => 'curl']);

I'm so lazy ? That's why I created RockModuleCreator some time ago... I didn't want to copy files, rename them, rename the class, lookup icon names etc... Not a lot to say... Simply upload your skeleton to github or similar, add placeholder tags like `#author#` or `#date#` and create modules quickly and easily. I'm happy to accept PRs if anyone wants to take this further... https://github.com/BernhardBaumrock/RockModuleCreator Available skeletons: https://github.com/BernhardBaumrock/RockMigrationsDemo https://github.com/BernhardBaumrock/RockProcessHello

Thanks for sharing! It is also worth noting the existence of something similar: http://modules.pw/

Like in recent weeks past, the primary focus this week in core development was working through the queue of older issue reports. Relative to 3.0.128, ProcessWire 3.0.129 contains 17 commits over 1 week, most of which are focused on resolving and closing out older issue reports. However, there have also been a few very useful additions too, and I’m going to cover them in a blog post next week. In terms of our issues repository, we are now down to 65 open issues and 777 closed (the closed number is a total over the life of this repo). If we subtract issues that are tagged as being fixed, not a bug or ready to close, we’re around 55 open issue reports (give or take a couple depending on when we check). Which is to say, there’s a lot of great progress here. And many of the remaining issues are minor things that might only affect one person, though still important nonetheless. Thanks to everyone that’s helping figure things out (such as Toutouwai, Matjazpotocnik, Netcarver and others), your help is greatly appreciated. Just now I also released a new version of ProMailer (v7) which accommodates many of the recent feature requests and fixes a few minor issues as well. There has been a lot of enthusiasm for ProMailer, pleasantly more than expected—thanks for your interest and support. Here’s the changelog for the latest version (v7) below. There is also more good stuff in the works for v8 as well. Changed subscribers list interface to use tabs. Added ability to remove all subscribers from a list. Added ability to remove filtered subscribers from a list (matching find query). Added ability to import subscribers from another list (creating a merged list). Added support for single, multi-select and checkbox custom fields. Added support for PW 3.0.129+ core WireMail blacklist (more details in next week’s blog post). Added several new options for custom fields (see new custom fields reference). Added documentation for conditional placeholders. Split the rather large ProcessProMailer.module into separate files/classes. Fix some display issues in AdminThemeDefault and AdminThemeReno. Various minor bug fixes and other minor tweaks, additions and improvements. Thanks for reading this quick update and hope that you have a great weekend.

When I inspect your page, no JS is being loaded at all. This doesn't have to do with PW per se. You're responsible for handling all the frontend assets correctly. (when I say "you", I mean the site-developer. The CMS just delivers what you tell it to.) Go back to the drawing board and make sure your HTML, CSS + JS setup is correct. Perhaps there's a missing include() or you've disabled a prepend or append .php file?

The imagesizer engines act as follows: If "something" requires a variation of an image, it checks if this variation already exist in filesystem and, if yes: deliveres the cached version, and if no: creates it before delivering. So, it doesn't matter if you install or uninstall modules or do api calls or what else. It is the simple rule: is it already there, serve it. Is it not there, create it and then serve it. If you need to overwrite already existing images, you can pass the param "forceNew" => true in the options array to any of the pageimage size methods. Or you call the method removeVariations() on the original to delete ALL existing variations at once. (Maybe sometimes useful during development with images). This all is handled internally by processwire when you work with pageimages and its sizing methods. If you want to do something besides that, maybe creating your own variations outside of processwire and you don't want them to be get touched / controlled by PW, then you should not use the pageimages naming conventions. But you will loose a lot of comfort then. So, pageimages are basically all the images you added to PW using an image field attached to a page.

Oops I get the confusion now, sorry my fault I assumed it was the same when i saw horst name here is the link:

My reply is for @OrganizedFellow , I was just quoting a reply he made in a thread you started.

Will do, noted and yes could be Devilbox is doing that, thx for your help.

Incredibly useful resource, thank you!

This. Going into responsive image syntax a bit due to that it might not work as expected by @bartelsmedia when the user changes viewport. When I started to learn this I found out the hard way that using multiple "source" elements (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/source), as is done for art-direction, will indeed download the smaller or larger versions as the user changes the viewport. This is due to the fact that for art-direction the browser assumes that the image for the smaller or larger viewport does not have the identical content but is either a crop of the original image or a completely different image. Only when using the non-art-direction syntax will responsive images behave like you explained. This took me some time to understand but once I did it completely made sense. I found this resource to be very help in understanding the different approaches to the responsive images syntax. https://dev.opera.com/articles/responsive-images/ So @bartelsmedia make sure you are using the appropriate syntax for your use case of responsive images.

This is possible by 3party module AOS, Admin On Steroids. (On mobile, so please search in the modules directory or the modules forum for it. Author is @tpr)

My migrations module has generators. Basically everything creating a migration file for you is one. Just that those are meant to be edited further, while files generated by modules would work as is. Generally I think you‘re quite fine as you‘re doing modules and the sites using them by yourself. It‘s getting more complicated if things are no longer in one hand and happen independently from each other.

Unfortunately Ryan doesn't accept PRs, so all you can do is add to this issue: https://github.com/processwire/processwire-issues/issues/797 Welcome to the forums and thanks for your efforts to improve/fix things!

Thought you're in a hurry... ?

Hi for New Zealand! Thanks for helping Rob! Finally solved in this simple way (this PW has a zillion options ?) $properties = $pages->find("template=property, sort=pstatus, sort=date");

This profile can be used as a simple business card or it can be used as a starting profile. Live Example Can download from this link: https://github.com/rafaoski/site-minimal Basic Info Most of the profile settings and translates are in the _init.php file. Functions can be found in the _func.php file. The entire view is rendered in the _main.php file that uses markup regions. You can easily add hooks using the ready.php file. Options page added with the new “Unique” status, which you can use in this simple way like: pages('options')->site_name pages->get('options')->site_name Screenshots:

The final verdict is in! Thanks to everyone, I have moved the site to the new domain (actually it's duplicated but that's OK since I can erase the old one). When I started to act on the recommendations, I sort of accidentally discovered a 4th option (explained below) which worked. But I wish I'd done it the way suggested by @Robin S, @Autofahrn and @jens.martsch (updating $config->httpHosts in site/config.php). I'm sure that would have been even faster. So anyone else who comes across this thread looking to do the same sort of thing (moving site to new domain on same host), you might like to try that solution of $config->httpHosts in site/config . What I wound up doing However, I had not yet read those 2 latest responses at the time, so I was thinking about all the different methods and was looking to try the Duplicator module. Desiring to be a responsible site owner, I went to create a Softaculous backup of my site before trying the Duplicator module. This way I can restore my original site in 1 click if I do anything wrong. To my happy surprise, in the backup menu in Softaculous, one of the other options besides back up was "Clone site". Well, being curious, I thought "Let's try that, and if it doesn't work out, I can use one of the other methods people suggested". So, I tried Clone Site, and it worked perfectly! I just had to do point and click and tell it which of my domains to put the cloned copy of the site in, and boom, there it is at the new domain! After doing that, I then read the newest responses to my thread and realized that it would have been even faster to use the solution of Robin S, Autofarn and jens.martsch, but anyhow, the Softaculous method works too in case anyone has it available to them and was wondering about it. And after the site is in the new domain... A big thank-you to pwired for the advice given This turned out to be really helpful - I tried the search function in phpMyAdmin and found a few mentions of my old domain name still in there. It was clear from the results which pages I needed to edit in the processwire editor. So it may be a useful step for others too who are looking to do a similar type of domain move. Thank you again to everyone who responded in this thread. All of the suggestions were very useful. I really appreciate the sense of community here.

So just edit site/config.php and add the new domain to the $config->httpHosts array. "migration" done.

You don't need to migrate to a new hosting server just because the domain name for a site changes. Point the domain to your host and update $config->httpHosts in /site/config.php. Depending on the type of hosting you might need to adjust a setting there too, e.g. update the primary domain if it's a cPanel host.

Clear vote for Duplicator from my side, since its a no-brainer. You still may copy a very large (GBytes) /site/files folder manually, if required. Btw: Allowed domains are configured in your site/config.php ($config->httpHosts). If you go with the manual approach, you'll have to adjust this manually as already stated, otherwise Duplicator does this for you.

I have abandoned Windows and gone back to Debian. From beginning to end, it took me about 15 minutes to get the docker container and dependencies running + database import and another 15-20 to get VSCode extensions set up. GOSH i missed my setup. I doubt I will return to Windoze ?

The relevant rules are explained in .htaccess: https://github.com/processwire/processwire/blob/master/htaccess.txt#L145 I recommend keeping these rules and pick a location which is not protected bye the default .htaccess file.

It works without problems with the latest stable version ?

You'll need a hook, something like this: maybe along with:

AdminTheme Boss with some customizations. ?

Pretty good article about jQuery and the craziness of rejecting it "no matter what": https://www.i-programmer.info/news/167-javascript/12017-github-removes-jquery-why.html

Hey, @pwuser1! You could already reach some intermediate JQuery skill by now, spending half the time passed from the creation of this topic . The basics are easy. Most of the times for the simple sites js+JQuery is about installing and configuring some plugins, using their docs pages and the official JQuery API reference (start by adding something like Magnific Popup to your site). But if you need some link to start with, I would recommend FreeCodeCamp course. The whole FreeCodeCamp thing is a hype so you'll feel yourself trendy)) Just recently listened to an issue of ShopTalkShow, one of my favorite podcasts, that fits here perfectly. Could not resist to put it here (for some controversy at least).

Definitely agree with what @adrian say. If you are new to JS world, IMHO, I would suggest this learning curve: JS -> ES6 -> jQuery -> Vue / Angular / React https://scotch.io/bar-talk/vuejs-vs-jquery-use-cases-and-comparison-with-examples http://youmightnotneedjquery.com

For basic selectors this would have probably been enough. Though I'm not sure if it covers all edge-cases correctly. $isShown = $page->is($field->showIf);

TemplateBy adding the fields you desire to a template you basically model the content/data that you want to manage. Template file Associated to a Template, a template file is where most of the view and controller logic takes place. PW is very flexible so you can also make this more MVC-like, look at this for an example: https://github.com/fixate/pw-mvc-boilerplate/tree/develop Page A page is a data object that always follows the rules and data structure of the associated Template (you could say model). In PW pages are tree based (parent-child relationships). This gives powerfull options of organizing and relating content. Routing PW has a default way of routing following the page tree, but by utilizing urlsegments or hooking into the routing mechanism you can define your own if needed. So PW has it's own way of doing things. It may take some getting used to, but in my opinion it is a very nice way to model and manage your data. I believe one should always choose the right tool for a certain job, so there might be projects that are better suited to build from the ground up using a general purpose framework like Laravel or Symfony. But in my experience PW is the right tool for a whole lot of stuff.