Leaderboard

If you have the core ProcessPageClone module installed you can copy a page via Page List: But sometimes I don't want to hunt around through Page List to find the page I want to copy, and instead I have found the page via the admin search and have it open in Page Edit. So I used this hook in /site/ready.php to add a "Clone this page" button to the bottom of the Settings tab. // Add a clone button to the Settings tab of Page Edit if this page is allowed to be cloned $wire->addHookAfter('ProcessPageEdit::buildFormSettings', function(HookEvent $event) { $wrapper = $event->return; $modules = $event->wire()->modules; $page = $event->process->getPage(); /** @var ProcessPageClone $ppc */ $ppc = $modules->get('ProcessPageClone'); if($page && $ppc->hasPermission($page)) { /** @var InputfieldButton $f */ $f = $modules->get('InputfieldButton'); $f->value = 'Clone this page'; $f->href = $event->wire()->config->urls->admin . 'page/clone/?id=' . $page->id; $wrapper->add($f); } }); Maybe somebody else has this need and finds this useful.

I take it you mean vanilla JavaScript? Here's a short list of candidates ?. https://www.youtube.com/playlist?list=PLillGF-RfqbbnEGy3ROiLWk7JMCuSyQtX https://www.youtube.com/playlist?list=PLillGF-RfqbZ7s3t6ZInY3NjEOOX7hsBv https://www.youtube.com/watch?v=ZcQyJ-gxke0&list=PL4cUxeGkcC9jx2TTZk3IGWKSbtugYdrlu https://www.youtube.com/watch?v=iWOYAxlnaww&list=PL4cUxeGkcC9haFPT7J25Q9GRB_ZkFrQAc https://www.youtube.com/watch?v=4l3bTDlT6ZI&list=PL4cUxeGkcC9i5yvDkJgt60vNVWffpblB7 https://www.youtube.com/watch?v=FIORjGvT0kk&list=PL4cUxeGkcC9gfoKa5la9dsdCNpuey2s-V https://www.youtube.com/watch?v=0Mp2kwE8xY0&list=PL4cUxeGkcC9gKfw25slm4CUDUcM_sXdml https://www.youtube.com/watch?v=YxWMxJONp7E&list=PL4cUxeGkcC9jAhrjtZ9U93UMIhnCc44MH https://www.youtube.com/watch?v=0Mp2kwE8xY0&list=PL4cUxeGkcC9gKfw25slm4CUDUcM_sXdml https://www.youtube.com/watch?v=ANDyf6VEYHE&list=PL4cUxeGkcC9gdqHxcUgGhl_cV6xET1_0N https://www.youtube.com/watch?v=qoSksQ4s_hg&list=PL4cUxeGkcC9i9Ae2D9Ee1RvylH38dKuET

Also, I want to open the page in Page Edit after it is cloned. Here is a hook for that: // Edit the cloned page after it is created $wire->addHookBefore('ProcessPageClone::execute', function(HookEvent $event) { $event->wire()->addHookBefore('Session::redirect', function(HookEvent $event) { $url = $event->arguments(0); $id = (int) filter_var($url, FILTER_SANITIZE_NUMBER_INT); $redirect_url = $event->wire()->config->urls->admin . 'page/edit/?id=' . $id; $event->arguments(0, $redirect_url); }); });

Kevin Powell has a good tutorial using grid columns and rows to overlap content.

Greetings! Webflow has an super nice tutorial on implementing this using their app, BUT it's totally fine to just learn from it and to it by hand, so if you are more of a visual learner, like me, you'll enjoy it:

Good point, as many took the road without javascript like me. Lately I am catching up with "talking to the server without page reload" (ajax - XMLHttpRequest) I left treehouse and moved to udemey.com as I experience them more professional/friendly and they have a lot of offers. https://www.udemy.com/course/the-complete-javascript-course/

@ryan, a few things to clarify and add to my earlier post... My dream/request for ProFields Textareas and ProFields Combo is really about the Page Edit interface. It's only about the modules in that they render multiple inputfields in Page Edit and I'd love to have extra flexibility to arrange those inputfields. The fieldtypes work brilliantly just as they are. To me, the attractiveness of Textareas and Combo is that they reduce the number of fields that are required for some projects. The only time this matters to me is on large sites that have hundreds of fields (or rather would run into the several hundreds if I don't take measures to be efficient with fields). And although I always plan for efficiency and haven't yet run into performance issues due to excessive fields or templates, there are topics in the forum that indicate it can be problem: A typical project scenario for me is... Client describes what they want - often it's a catalogue-type site for scientific data. I can see it's going to involve a ton of fields (or might in the future), so I start planning how I am going to handle them efficiently. Often a lot of the fields in a template will have identical requirements - they're just simple text/textarea/CKEditor fields without any special settings needed. I look at Textareas and read in the description: Sounds perfect! But when I get into the nitty gritty of the project it turns out that all these similar fields need to be interspersed with image, file, table, repeater fields. Or worse, I see a bunch of fields that are all adjacent and related so a great candidate for Textareas but some time down the line the client wants to stick an image field in the middle of them. Now I have a problem and have to scrap the Textareas field and break it up into multiple fields. I can see the same situation arising when I start using Combo (which seems like it can do everything Textareas does and then some, which is awesome). The way I see it, the beauty of Textareas and Combo fields is all about the reduction of fields needed for a project. Their appeal to me is not about grouping fields into a smaller set beyond the bigger grouping of "all these fields belong to this template" and I've never needed to add a Textareas field to more than one template. The loading of the field data and the field.subfield API syntax doesn't matter to me one way or the other - it's not a benefit or a problem. But the fieldset grouping in Page Edit is a limitation rather than a feature because it often means having to rule out Textareas/Combo from scenarios where otherwise they could avoid a lot of field overhead. Right now we have a "Fields" inputfield in Edit Template that is doing two duties: 1. It allows fields to be added and removed from the template/fieldgroup. 2. It determines the order and layout of inputfields that are rendered in the Page Edit form. These two things are related to an extent but in some ways they are quite different. Bundling them into one interface has worked fine for almost all the fieldtype modules in PW, but when I think about special fieldtypes like Textareas and Combo that can render multiple inputfields it seems like this interface holds them back from going to another level of usefulness. I don't know what the perfect way to handle it is, but one idea is to separate 1 and 2. So there would be a "Fields" inputfield that simply determines which fields belong to the template. And there would be a "Page Edit layout" inputfield that is all about the layout of inputfields in Page Edit, not concerning itself with which field each inputfield corresponds to. In most cases adding a field to "Fields" adds one inputfield to "Page Edit layout". But for some special fieldtypes (Textareas, Combo, maybe FieldsetGroup, maybe some third-party fieldtype modules in the future) these modules add multiple inputfields to "Page Edit layout" that can be sorted individually. And when the Page Edit form renders it loops over the data from "Page Edit layout" and renders those inputfields accordingly. As far as I know this wouldn't require any changes to how the Page Edit form submission is processed. In my hacky module I am moving inputfields all around the Page Edit interface and it doesn't affect anything else in PW. I know this wouldn't be a simple change but for big sites I think it could allow Textareas and Combo to cater to more scenarios, be more accommodating to changing project requirements, and thereby save a lot of field overhead.

Worries? Combo achieves these these goals perhaps the best of all the ProFields. And all of the ProFields achieve these goals and more, and I stand by that 100%. If we could solve every use case with one field, we'd only need one. But there are several ProFields because each solves a different use case. That's the point. To gain the benefit, you have to use them for what they are designed for. No field in PW can pursue the use case mentioned earlier because it's outside the scope of what fields can do or are even for. I'm interested in the use case still, but for the core, not for any individual field, where it would be technically impossible. Good strategy, and same here. I don’t often reuse fields unless the name makes sense for it. That’s how it’s supposed to work. It’s the more generic (title, body, images, files, headline, summary, etc.) that make the most sense for that. Though in my case at least, the reusable fields are also the ones most used, since they generally apply to almost all templates. Yes, I wouldn’t do that either. Though something like “headline” and “headline2” or “body” and “body2” (or further) might be fine as it’s not uncommon for a template to represent primary and secondary headline/body content, and for that need to be a recurring one on multiple templates. Respectfully, I think that’s backwards, and not a correct statement in my opinion. You are of course entitled to your opinion, and no problem, but I would not put my time and effort into building something that “isn’t beneficial in very many cases.” These fieldtypes (and Combo in particular) I think are beneficial for a ton of cases. In the case of Combo, it’ll likely be one of the first modules I install on every site I work on, and have no doubt it’ll be the same for others. Everyone has different needs, but I think easily more than half of all ProcessWire users will find major benefits in Combo. But I don’t claim that ProFields or even ProcessWire will solve every need that every person has ever had either. Though my hope is that ProcessWire is the platform for solving most. And combined with ProFields, even more so. Btw, Textareas and Combo are completely different animals, and while they keep getting mentioned together, they really have no relation to one another other than that they are both ProFields. Relative to using separate fields (first_name, last_name, street, city, state, zip) I think the performance benefit will depend on when and where you are using the content of those fields. If you are using all the info in those fields in a given request, then it will be a definite worthwhile benefit. If you are more often just using the "city", then probably not a benefit. In reality, this particular example is too small for it to matter one way or the other. So I would say for this case it depends on whether you prefer to treat these bits of content as a group or not (in your page editor, in your template placement, and in your code). Likewise, if you are reusing that combination of content (group), it’d be a lot simpler to just add the Combo field to a template rather than all the fields individually. Same goes for whenever you want to change something about it. It adds a lot of development efficiency to work with the combo rather than always all the bits within it. Or maybe even a 3rd option: use both. But only you can decide what option best suits your need. They are all good options. This is a concern I have with what’s being asked for with mixing subfields and fields together. It’s confusing for me at least to start mixing up what these things are. They would definitely need to be well isolated, though I think Robin S.’s screenshot did a good job of that making it clear what was what in terms of the definition stage. I would find it confusing in the page editor though, as the editor would no longer accurately reflect the actual field. Could be an issue, or not, I’m not really sure. Count me is interested, but just not in achieving it with a field like Combo, since it’s not even possible. But it is possible in the core. And it sounds like it may be possible to some extent in a module (per what Robin S. as developed), though I'm not sure exactly how, but am curious. This is not at all true, so I’m assuming this is just a hypothetical “if” for your particular use case. There is indeed a performance advantage, and it can be major. And for most it will be significant. But like with anything in software, it depends on what you are doing and how you are using it. If you are actually using the content as a group (as intended), I think the performance benefit can be major, as the effort of loading multiple fields is now reduced to the effort of loading just one. If you are wanting to use it as a storage container for other unrelated fields that aren’t used as a group, and may be used inconsistently, performance would be better served by regular PW fields, which are already designed for this and are already quite performant. Based on everything you’ve mentioned, I agree that think your particular needs sound like they are best served by PW fields. Combo offers a lot of flexibility, but it was never intended to replace all that you can do with templates and fields. It is itself still a field, after all. Combo would be very useful for this, no doubt. A group of normal content fields is a fine use case for Combo. But if wanting to use it as a storage container for some normal content fields that don’t really go together, I agree that you’d want to resist the urge to use it in that way.

I found this little gem just the other day: https://github.com/felippe-regazio/php-hot-reloader How do you do live reloading?

For years I called myself a web developer, without really knowing much JavaScript. Where are some good sites I can start my journey? Prefer something that has be building projects as I go. I'm decent enough with HTML & CSS + PHP, but JavaScript is my weakness. I found these while searching: forces me to a credit card page, disappointing => https://www.codecademy.com/learn/build-interactive-websites just leads to a 3.5 hour YouTube video=> https://www.freecodecamp.org/news/learn-javascript-full-course/ but was wondering if the community has some other suggestions.

I’ve just released the first version of the ProFields Combo field and it’s now available for download in the ProFields support board download thread! Rather than writing a long post today, I’ve instead focused on writing the Combo field documentation. The documentation page includes a lot that you may already know from previous posts, but it also includes a lot of new details that haven’t yet been posted. Please consider this version to be a development/beta version. It’s the first release and hasn’t had a lot of testing yet, so consider it not yet ready for full production use. Though if you get a chance to test it out, please let me know how it works for you. I appreciate any feedback you have. A couple things I haven’t yet tested thoroughly enough yet are exporting/importing of Combo fields or pages using combo fields. I also haven’t done enough testing in FormBuilder yet. So I’d recommend avoiding use of PW’s field or page export/import functions with this, or using in FormBuilder, at least for a few days. By next week I will have tested those things and made any necessary updates. Thanks for reading and have a great weekend!

I use gulp with browser-sync in my current workflow. I really like it as I can specify what files extensions (php, css, etc etc) to watch for changes and once it detects a file change, it automatically reloads the page. I also will be using gulp-cache for cache busting (for changes with my scss/css). So far I have been very happy with the results.

Thanks @psy. I saw his other older ones but I missed this one.

HOLY SMOKES, all i had to do was Log in!!!!!!!!!!!

@modifiedcontent Not quite your question but in your template, where you are rendering the comments entry form, you can do this instead. This should set up the correct value for the cite field for new entries... <?php echo $page->comments->renderForm([ 'presets' => [ 'cite' => wire()->sanitizer->entities($user->fullname), ], ]); For existing entries, I think you can iterate the comments and then set the cite attribute to the value you want.

Thanks @Sergio!

What version of PW are you running? In 3.0.156 there were a bunch of changes related to page parents: I am wondering if these changes might help, or if you are already running this (or later version), if it was faster before?

I can also recommend this course. Currently I am 40 % into it, and I have learned a lot.

PHP Versions available on ServerPilot, if you still need 5.6 - it's also available without any CVE holes.

Hi @Sascha Nos take a look there : https://wire shell.readthedocs.io/en/latest/commands/module/

You couldn't use that action anymore, since you're not be adding each file to an image field, but instead you'll be adding a new item to a repeater field AND adding the image to a field in that newly created repeater item. You can copy that action to create a new action that does that. Looking at the code of that action https://github.com/adrianbj/ProcessAdminActions/blob/master/actions/FtpFilesToPage.action.php, in the defineOptions() function, and assuming that the existing 'field' option would hold the repeater field, you'd need to create a new 'image_field' option to hold the image field inside the repeater. Then you'd need to update the code inside the executeAction() function to create the repeater items. In line 78 you'd have something like (written on the knee and not tested): $newItem = $destinationPage->$fieldName->getNew(); $newItem->$imageFieldName->add($item->getPathname()); $newItem->save();

Correct :-)

@Robin S - what about being able to select a subfields like you can with Lister Pro for Page Reference fields etc. Do you think this sort of interface would work to allow for interspersing image etc fields in between Combo subfields effectively? I realize there are some technical issue for Ryan to overcome, but I think this interface might work to allow the arrangement flexibility as we are envisioning.

Love Cloudways. Ability to clone a site/app is great. For usual sites, I can use it as a starting point with the default modules ready to go for the next site.

This will count the number of published pages (not under Admin or Trash). Is this what you need? $pages->count('has_parent!=2,has_parent!=7,status!=unpublished');

Ignore the above I just realised I can use the srcset and sizes methods separately. Man, responsive image markup fries your brain. Great module thanks!

Well, hello somebody! Look at what I've stumbled upon ?. Tailwind Starter Kit A beautiful extension for TailwindCSS. Tailwind Starter Kit is Free and Open Source. It does not change or add any CSS to the already one from TailwindCSS. It features multiple HTML elements and it comes with dynamic components for ReactJS, Vue and Angular. Yes and vanilla JS as well! (currently, 16 dynamic components.). License: MIT GitHub: https://github.com/creativetimofficial/tailwind-starter-kit Site + Demos: https://www.creative-tim.com/learning-lab/tailwind-starter-kit/ A tutorial on YouTube. I haven't dug in deep yet (e.g. purge/tree shaking, etc). @Jonathan Lahijani. What do you think? ?

ServerPilot is a cool service and deserve a word here. I know this service because of @Macrura and I never get out. Thanks dude ! You buy a dedicated server, attach it to ServerPilot and you get your server up in minutes, he will get updated without any intervention. You will get the right stuff, updated with every last software and dependencies version, patched, without "any" security hole. I even some at the start tried to hack the server with no luck, I had to make a vulnerability myself to get into ? no really you get all needed architecture, like app isolation and more with security in mind. And if you know what your are doing, you can install any software you want, do any ninja command or add any config through SSH. You will also like their support lol, full of experienced geeks veterans. That's all, this was my 10$ spam for today ?

For anyone who is interested in integrating tailwind inside a processwire project here is a little walktrough based on my workflow. This little guide is based on Tailwind 1.9.6 (latest before 2.0 release) because some PostCSS library I use are still not compatible with 2.0 version (not a big deal, really). You can find the necessary files here. - Place package.json, tailwind.config.js, postcss.config.js inside your template folder. - Create a "pcss" folder, and make a structure like this: pcss ├── inc │ ├── colors.pcss │ ├── fonts.pcss │ ├── media_queries │ │ ├── lg.pcss │ │ ├── md.pcss │ │ ├── sm.pcss │ │ └── xl.pcss │ └── sitewide.pcss └── kickstart.pcss Now you got everything to get started, let's have a look at the files: package.json Inside "package.json" you have different dependencies I've installed to mimick my "old" scss workflow (importing, nesting, etc..), the important part however is the script section: "start": "npx tailwindcss build pcss/kickstart.pcss -o css/dist.css", "watch": "npx postcss pcss/kickstart.pcss -o css/dist.css --watch", "build": "cross-env NODE_ENV=production npx postcss pcss/kickstart.pcss -o css/dist.css" "start" is the bootstrap script you have to run at first, to let node compile tailwind as a whole. Do it at the beginning of the project or everytime you make some changes to "tailwind.config.js" Change the name of your pcss files accordingly (I've used pcss as an extension, but css would work perfectly fine) "watch" is the next script you have to run in order to have live reload of your stylesheets. "build" is the script you have to invoke once you are ready to deploy to production (you need to specify your purge rules inside postcss.config.js, keep reading.) tailwind.config.js Here you can specify your tailwind configurations, read the docs here. One thing to notice inside mine is that I've set purge: false because I prefer to configure the purge part inside a dedicated file, which is: postcss.config.js This file is responsible to handle postcss options, and purge is one of them. The paths you declare inside the content array are the ones whom will be scanned and purged eventually. Mine could be different than yours, so pay attention. The whitelistPattern array is useful when you want to exclude some classes from the purge phase, below I'm excluding the ones whom starts with "fff-". ... content: [ './*.php', './inc/*.php', './fields/*/*.php' // etc. ], whitelistPatterns: [ // Pattern to exclude during extraction /^(fff-)/ ], ... The other settings are pretty explanatory (cssnano is used in production for minification). As a final note you'll notice that every pcss file I use starts (and ends) with: /* purgecss start ignore */ css... /* purgecss end ignore */ Those tell purgecss to ignore completely the file, since I know I want to retain every rule/class I write in there. If you got everything setup correctly you can start having fun ? Run: npm install then: npm run start and finally: npm run watch Hope this little "guide" could enlighten in using Tailwind ?

Apologies guys, I seem to have skipped 0.6.0, which was sitting on develop for quite some time. That's fine though, because if there are no issues, I'd like to bump it to v1.0. Given that it's not there yet, I've marked the module as Beta. If anyone does bump into funny stuff, let me know and I'll get it sorted as soon as I can.

25,000 per hour/day/week? It all depends. From what you described about the app, even 25k users a day should be fine to start with a VPS with 2GB of RAM. If its usage increase a lot you can move the database to another VPS on its own AND/OR increase the VPS CPU and RAM resources very quick. My advice is to keep things simple and not try to over-engineer the application performance from the start. But if you feel "adventurous" ? or think that the project will have this many users right away on day one (which I doubt) you can start with a "serverless" approach where the infrastructure is scaled on-demand, using https://vapor.laravel.com/ and you don't have to worry. There's a course about this approach that is very interesting: https://serverlesslaravelcourse.com/

@gunter: see if httpHosts setting is in place in your /site/config.php and contains only "localhost", that's the most likely culprit. Ryan: if you're reading this and if aforementioned really is the problem here, I'd say that this is an issue that should be dealt with.. personally I'm against this whole setting (I'm seeing more issues than benefits there), but at least it should stay out of way as far as possible -- opt-in instead of opt-out.

Right now the field is basically following the rules of PHP's URL filter. I can experiment more with this to see about adding mailto. It does make sense as a possible configuration option as there are many places where you might want to use mailto where you'd also use a URL.