Leaderboard

I was tired of adding 6 different fields to an event-template just for storing the time range of the event... ?

@FlorianA, you can probably achieve what you want by using hooks. ProcessForgotPassword::renderEmailBody is hookable and includes the link URL as an argument, to which you could add the verification code (which is also an argument) as a GET parameter. Then you could hook before InputfieldText::render and if the field name is "verify" (you could do additional checks if needed) you could check $input and set the value from the GET parameter.

Just an idea: it's not the most street credible way to use Vue, but if you've got an existing app and you want to give it a try to see how it would work for you, adding it via a CDN is always an option. You won't get the benefits of a build process or all of the benefits of a full blown JavaScript framework, but what you should get is a rough idea if Vue is the right fit for your needs. Once you've (re)built a part of the admin side with Vue, you can decide to either dive in deeper, or just stick to good old jQuery+HTML ? Even if you go with the full "vue create app" route, you don't have to rewrite your entire site. For an example I recently built a PW website with a single Vue app embedded within — a member catalogue with a lot of data, sorting, filtering, etc. involved. Would've been a major headache with jQuery+HTML, but Vue made it pretty easy. I used Axios and treated one path of the PW site as a simple JSON API, which was — apart from some head scratching related to Access-Control-Allow-* headers — basically a no-brainer. Would do it again. Note: in the example above the page itself is served via PW (we've also done full-blown Vue SPA's with ProcessWire, but that's a very different route). Vue app is built in a separate location, generated JS file and required assets are moved to a directory within /site/templates/, and then the JS file is embedded within the page's markup. PW outputs a HTML element with an ID, which you then tell Vue to render the app in.

Indeed. It once took me ages to find out why. Since then I keep it installed, but only activated for certain templates ?

I have already build a "reserved area" for logged users on my PW website some years ago. I developed the "reserved area" using front end tools (Jquery and HTML) and the users don't see PW admin backend. Now I wanna extend and rebuild with modern tools this "reserved area" where users can modify their personal data, request certification cards for their students, publish courses, ecc... I was asking myself if I can have some big advantages using new frameworks, anyway your replies already cleared some doubts. About this: I wrote bad and quickly, sorry. I was meaning "That’s why we went for a decoupled approach where we use only ProcessWire to edit data and then pass it to the frontend with a single request returning everything as JSON-data" taken from this article https://medium.com/icf-church-developers/processwire-vue-js-a-lovestory-d4d5bca365 Thanks for your patience

@manlio If you want to enhance PW's backend, you're free to use whatever you find useful. Depending on the actual task / use-case, adding Vue.js or a similar SPA framework may be overkill. But if you need to build a fancy dashboard / complicated admin pages, then Vue can perhaps add some nice extras. Care to elaborate on this? You mean "where should these extra frontend assets be stored?" Typically under site/templates. Static assets maybe rather in site/assets/. Make sure to check out @bernhard's epic tutorial about building your own PW module / dashboard. There's a lot of stuff "under the hood" to discover, with functionalities already available out of the box. So if you think about building something along those lines, adding a big JS framework might be overkill, too. Generally speaking it's best to get a solid grasp of vanilla JS. Frameworks tend to make you lazy - e.g. when you're using frameworks to solve problems that vanilla JS can solve just fine by itself. A little recommendation: Here's an excellent tutorial where you learn (among other things): Nuxt Vue.js Dynamic routing (pages, categories) Axios Frontend communicating with a headless CMS (I have re-written the relevant code-bits to work with PW instead of Cockpit) Dynamically setting title tag + meta (stuff that some frontend devs often don't care about - but your customer surely will) Deployment on Netlify (not that I would actually need that - but I guess it's nice to know what the fuss is all about) I skipped several parts... Markdown, Tailwind... and I'm only done with half of it. But it's fun to see how easy it is to have PW generate one or two JSON files, and you're good to go (especially when you have a PW site already with lots of content to play around with). It depends if you really want to learn about all these things ("Developing website is not my primary job"), but it can't hurt.

First of all: for feature requests you might want to open an issue at https://github.com/processwire/processwire-requests. This is how it'll have the best likelihood of gaining the attention of Ryan ? I do agree that a sufficiently complex and rapidly expiring initial key embedded within an URL should be enough, but saying that the verification key wouldn't add any extra security isn't, in my opinion, completely fair. The longer the key the more secure it should be, and a second verification method (particularly one that user has to enter separately) adds another layer of safety. Technically it could also a) force the user to actually read the message, and b) prevent attacks where the user is somehow fooled into clicking an URL — though I'm not sure how common attack vector this would be. The way I see it, current implementation trades some ease of use to some extra safety, and personally I'm fine with that: password reset process should be a relatively rare occurrence, and attacks targeting such features are a common problem. (But you do make a good argument here; perhaps this should actually be a configurable setting for the module?) Again I think this depends a bit on your of view: on one hand current implementation makes sure that if one just gains access to a reset link they won't be able to change the password (particularly if you ask them to confirm something other than the email field), but on the other hand some experts recommend that this step should occur before sending the reset message (exactly for the same reason — security). Seems like another potential module setting to me, perhaps even so that both options (confirmation before and confirmation after) would be available. Just a quick note on this one: you don't actually have to force the users to go through the password reset procedure. In a case like this it'd be relatively simple to set up a custom process to handle the initial password reset — create and send the links to your users and process them through your own code. I've done that a few times during large scale migrations, and it's not that hard to do — though in most cases I would still recommend going through the password reset feature. Personally I don't think that the process is that hard on users. Just an idea — again I get that you're hoping to change things in general, but if you need to get this done on a timely manner, it would probably be best not to wait for a core level change. Especially since it isn't necessarily a complete no-brainer how this feature should work ?

basic example / ideas: document.addEventListener("DOMContentLoaded", function (event) { const trackedLinks = document.querySelectorAll("#content a"); // adjust selector as needed trackedLinks.forEach(function (n) { n.addEventListener("click", function (e) { e.preventDefault(); const href = e.target.getAttribute('href'); console.log(href); // api = special page with tpl and URL-segments enabled: fetch(`/api/linktracker/?url=${href}` , { method: "GET" }) window.location = href; }); }); }); (That's vanilla JS / ES6) if ($input->urlSegment1 === 'linktracker' && isset($_GET['url'])) { $url = trim($_GET['url']; // save to a textarea inside PW: $pg = $pages->get("123"); $pg->of(false); $pg->linktracker = $pg->linktracker . "\n" . $url); $pg->save(); // save to a custom DB table: $myDB = new PDO("mysql:dbname=linktracker;host=localhost", "root", "******", array(PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES 'UTF8'")); $trackLinkQuery = "UPDATE tablename SET click_count = click_count + 1 WHERE url=`$url`"; $query = $myDB->prepare($trackLinkQuery); $query->execute(); // udpate a text-file file_put_contents('path/to/file.log', $url); // if those links are saved inside repeaters or similar, add one int field that you can increment / update: $pg = $pages->get("123"); $pg->of(false); $pg->linktracker = $pg->linktracker +1; // or whatever / wherever your field is.... $pg->save(); } These are 4 basic ways how you could handle it - there are certainly more ? Hope that gives you some ideas.

That's a classic use-case for Google Tag Manager. But you can do it yourself with a bit of JS + PHP. Basically: assign a CSS class to these links, and write a litte function that posts the link href attribute to a PHP script, which in turn updates a field in PW.

Hi bernhard / teppo, Can it really be that simple? Thanks for the very prompt replies and good advice ?

Managed to miss this one. Check /site/config.php, you should find the database host/domain, credentials, etc. from there.

With this module installed: Parent pages with thousands of children do not open for editing in backend. They timeout with Error 500. I post this here, in case someone else has the problem. Thank @adrian for the hint.

Hey! Bernhard already summarised the steps quite nicely above, but one thing I'd like to add is that if you do run into Windows specific issues, you might find solutions from some of the existing threads — e.g. On a loosely related note, the forum search can be pretty horrible at times, so if you're looking for something specific you'll usually have better luck googling for it (site:processwire.com/talk) ?

Hi @JC_G and welcome to PW and the forum ? Make sure PW runs smoothly on the new server (go through the step by step installation process of the current version) If that works, make a zip file of all files of the old website and do a database dump Copy over the files to the new server, restore the database This can be all there is to do. If something goes wrong, just tell us what the exact problem is. There are also tools like https://modules.processwire.com/modules/duplicator/ that you can use. For upgrading there is a guide in the docs: https://processwire.com/docs/start/install/upgrade/

As I was looking as well for a cache clearing solution through the admin and did not find one I just found out about PWGeeks from PW news letter. It seems very nice to have a global list of existing modules, however not everyone would still be aware from the community about the tool, so we might see similar modules being developed based on the customer/developers needs. I will give a try to both cache clearing modules (if I may generalize the two) and see which one is suiting me more. At least some feedback can be shared. Thanks @MoritzLost for the new module. It is the play time now ?

Hey @bernhard - these are the two settings that control this: https://github.com/adrianbj/TracyDebugger/blob/11582e03c22db697972a08dac0e01630b0dbcb79/includes/TD.php#L156-L157 I have hardcoded them to "1" so dumps are always collapsed, but I can certainly open them up for being modified. The normal way to do these sorts of tweaks with the Tracy core is to include those as part of the options array when calling the dump, but it's usually just too much typing and not worth the hassle, so need to come up with an easier way. No time to look into this today I'm afraid, but will do sometime soon. In the meantime, you can obviously change those for your current needs.

Hi @montero4, That all makes sense. You can also do the following: // Create an image variation 1200px wide with -srcset suffix $image = $page->image->width(1200, ["suffix" => "srcset"]); echo "<img src='$image->url' alt='$alt_text' srcset='$image->srcset'>"; // PageimageSrcset will use the original to generate the srcset value If you have a look at the Pageimage options, you can add a suffix to the filename when resizing. Cheers, Chris

Hey @adrian just using the tracy console a lot gain for testing/developing a module. It's absolutely brilliant! Thx again! Do you have an idea of a quick solution for having dumped objects always unfolded? This is what I'm doing: I always have to unfold the object dump to see the results. For that I have to use the mouse - which is slow and tedious. If there where a checkbox "automatically unfold all dumps" it would speed up my process even more. Looking forward to hearing your thoughts about this, thx. Maybe there is already an option somehwere?

Would be very interested to get some details on this! ?

$config->webpOptions = array( 'quality' => 90, // Quality setting of 1-100 where higher is better but bigger 'useSrcExt' => false, // Use source file extension in webp filename? (file.jpg.webp rather than file.webp) 'useSrcUrlOnSize' => true, // Fallback to source file URL when webp file is larger than source? 'useSrcUrlOnFail' => true, // Fallback to source file URL when webp file fails for some reason? ); Set 'useSrcUrlOnSize' to false?

Thank you for all the precious advices! PW is an amazing software but community members like you and Dragan makes PW outstanding. I will follow your advices and I will start rebuilding a small part of the reserved area and see what I am able to do with Vue. Have a nice day

Hi guys, after getting a complain message from google about a robots.txt (where everything is ok), I searched for an online tool, where I can test my robots.txt files. I found this website: https://technicalseo.com/tools/ This page offers a bunch of nice tools, just wanted to share it with you.

You go away for a minute and this is what happens...? TL;DR From Device-centric to App-centric development: ambient computing Dart and Flutter ranked #1 and #2 for fastest-growing language and open source project respectively over the last twelve months - GitHub’s 2019 State of the Octoverse report. Flutter is now one of the ten most starred software repos on GitHub. Flutter described as “the fastest-growing skill among software engineers”. LinkedIn, 2019. Flutter for web is in beta. Flutter for desktop is in alpha for mac-OS. You can edit Flutter code, run it and view the rendered UI online in DartPad. See the samples drop-down on the top-right. Adobe XD, Supernova, etc: flutter plugins. Full announcement here. Videos here (Flutter Interact 2019).

I can't properly compare Svelte vs. Vue as I've zero experience from Svelte (and not a whole lot from Vue either), but regarding this question: it depends a lot on how complex stuff you're planning to build. I'm still using jQuery — or just vanilla JS, since native features have mostly caught up with jQuery by now — for stuff I can do almost completely with plain HTML and CSS (with a PHP backend), while for "complex" front-end stuff where a lot of data is processed, sorted, filtered, displayed (possibly in different ways), etc. I would definitely go with Vue. From what I have heard, the most common argument for Vue (vs. Svelte) seems to be that the Vue community is much more mature, and you'll find a lot more ready-made stuff for it. And, of course, more people with the same issues (which, as a relative newcomer to the JS scene myself, I've found really useful). This is all very opinionated, but the way I see it, jQuery is great if you just want to sprinkle HTML with some added-on behaviour, while for bigger stuff it actually tends to get more complex than if you'd chosen a full-blown front-end frameworks in the first place. So again, it depends on what you're actually building ? If you do decide to go with Vue, for admin UI's in particular you might want to check out https://vuetifyjs.com. With Vuetify you'll have to sacrifice some freedom in terms of UI design, but once you get up to speed with it, it's pretty amazing — in many cases seemingly complex stuff gets done in a matter of minutes ??

I haven't tried snipwire yet, but regarding the uninstall I have two suggestions/ideas: 1) Maybe SnipWire could state clearly before installation, that it is not trivial to uninstall this module and it might be the best option to restore a backup in case you want to get rid of snipwire. That would of course be not possible on a live system when some data has changed. In that case it might be the easiest solution to provide step by step instructions to uninstall everything manually. 2) Maybe https://github.com/BernhardBaumrock/RockMigrations have some helpful code snippets that you can use for the uninstall routine? RockMigrations are built in a way that they do NOT ask for any confirmations. That means if you delete a template all related pages that use that template are also deleted. That can be too destructive in some situations but can be exactly what you want in others... Thx for all your efforts @Gadgetto - as I said I haven't tried it yet, but it seems you are doing a great job!

Hi @nbcommunication Thank you for your reply. That's a neat solution. I didn't realize that if you resized or manipulated an image, it's -that- variation image that gets used as the src in the <img> tag. That actually makes sense. However, in my case, that approach wouldn't work because I'm disallowing access to the original jpeg images through an htaccess lockout method posted by horst in this forum. The way that method works is that it disallows all access to .jpeg files unless it has a certain suffix (like -piacontain, -pim2-full,-blogthumb, etc.). I want the jpegs to therefore have the "-srcset" suffix so that it is accessible. Here's the solution I came up with for future reference as the approach might help other people. //assemble img markup $image = $page->image; $string = $image->srcset("1200"); //create srcset of image 1200px wide $address = explode(" ", $string); $address = $address[0]; //create srcset using pageimagesrcset module default settings $srcset = $image->srcset; echo "<img src=\"$address\" alt=\"$alt_text\" srcset=\"$srcset\">"; The result of above code: <img src="/pw/site/assets/files/1070/test.1200x619-srcset.jpg" alt="alt_test" srcset="/pw/site/assets/files/1070/test.320x165-srcset.jpg 320w, /pw/site/assets/files/1070/test.640x330-srcset.jpg 640w, /pw/site/assets/files/1070/test.768x480-srcset.jpg 960w, /pw/site/assets/files/1070/test.1200x619-srcset.jpg 1200w"> This approach works and the htaccess gatekeeper lets the image request go through, but if a user attempts to access test.jpg directly, then it will not pass through. Thank you for module. As mentioned, I'm using it to serve all the images on my website. Regards,

@nabo - Thanks for letting me know. I see I updated composer.json and not info.json as well. Update: I have made the change in the repo, but will only be able to update the module directory when I find the password.

Hi @adrian, I didn't know that module existed, it's not in the directory, is it? Because I looked if something like this already existed and didn't find anything. Might've saved me some trouble ? That said, I had a quick look, here's what I found in comparing both modules: ClearCacheAdmin exposes more options through the setup page, so there are available to everyone, whereas ProcessCacheControl has it's options in the module configuration, so they are only available to the developer. ClearCacheAdmin has multiple links (and multiple options) on the process page, giving the user more fine control, whereas ProcessCacheControl goes for a simpler interface and bundles all those actions into one (configurable) action with a single button. ProcessCacheControl can delete $cache entries without an expiry date, which ClearCacheAdmin doesn't as far as I can tell. ProcessCacheControl also lets you configure caches to be deleted by namespace, whereas ClearCacheAdmin offers each cache entry to be deleted individually (I think this has mostly to do with the module being a bit older, I believe $cache didn't have all those options back then). The largest difference is my concept of "cache actions", which ClearCacheAdmin doesn't have. I'm not sure how useful that will actually be yet. I think if I can expand on the actions available by default, it will be pretty handy. With ProcessCacheControl, you can add custom cache actions / profiles through the API, that may be useful depending on the use case. Adding to that, ProcessCacheControl has permission checks on a per-action basis. ProcessCacheControl can be modified and executed through the API. In particular, you can modify the default action and execute any action programmatically.

Definitely an interesting topic! We've developed a few PWA's for our clients recently, and I'd say that they've been very well received — but, to be fair, they've been a) services for existing members and b) basically apps that wouldn't work (well) as regular websites, so that option was out of the question. When it comes to native vs. PWA, in our case PWA seems like the obvious choice: easy to use and efficient to maintain, upgrades are effortless, and obviously the web platform is "our thing" (more than native anyway) ? Some "random" websites (news sites, blogs, etc.) are now offering the option to install, but to me that feels a bit weird: unless it's a service I'm going to use regularly and there's a clear benefit for me in installing it, I don't really see the point. In fact it can also be a little intimidating: why do I need to install this service to use it? Again I think it boils down to the question of "would it work as a regular website": if the answer is "yes", then perhaps it should just be that ?‍♂️ (Sorry to hijack the thread, by the way!)

Hi @montero4, I'm sorry, I'm still not following? There's nothing stopping you changing the src - you should resize the image first: // Get the image $image = $page->images->first; // Resize the image $image = $image->size(1024, 468); // Output the image echo "<img src='$image->url' alt='$image->description' srcset='$image->srcset'>"; // Or alternatively echo $image->render(); PageimageSrcset recognises that it is an image variation and then uses the original to generate srcset variations. It isn't really this module's job to handle the src attribute. In theory you could do some manipulations of the "srcset" value to extract the first or last image for use, but I'd say it is a lot cleaner just to resize the image. Cheers, Chris

RepeaterMatrix is going to be the best choice for any type of page builder in ProcessWire (at least at this time). The recent updates to the module improve its flexibility further, such as being able to change the matrix-type of an item that's already been added to a page (this is similar to Gutenberg functionality of being able to change block-types... nice). After using RepeaterMatrix and its equivalents in other CMSes over the years (such as WordPress ACF Flexible Content field), my suggestion is you're better off NOT providing fully customizable layout functionality within your builder (that is, avoid the capability of allowing users to add things like containers, rows, columns). I've personally found that even other CMSes that do this well and are built around that concept are just too clunky. It's the nature of the beast. The better approach in my opinion is to provide a good set (5-10) of matrix-types/blocks that can instead achieve this. Once again, the recent feature addition whereby matrix types can be changed is going to help here since switching a matrix-type retains its content as long as the matrix-type you are switching to uses the same fields.