Leaderboard

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 ??

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).

@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.

Thank you @dragan, very constructive critic! Sorry you didn't like SnipWire... There is a single page under admin > setup which has the system flag (I decided to use the system flag because if this page is deleted SnipWire won't work). I just have not yet implemented the uninstall routine for this special page in the beta. #todo If you have a look at the docs: https://docs.bitego.com/snipwire/getting-started/install-uninstall/ the following is stated: All other SnipWire components are uninstalled perfectly here (just tested)!

Hi all, I am new to ProcessWire module development. Just recently getting back to using PW again after a couple of years away from it. I was looking for a SASS/SCSS/Compass pre-processor module for PW and couldn't find any. The closest I could find was AllInOneMinify but it doesn't do SASS/SCSS. I decided to make this module (with heavy inspiration from AOIM). This is a pretty basic module that takes one or more sass/scss/compass file(s) and compile them automatically in your template. Github link https://github.com/lesaff/ProcessWire-Sassify I really appreciate any comments, suggestions, bug fixes, etc. Hopefully this is the first of many modules. Thanks Rudy Note: Added to Modules directory, under http://modules.processwire.com/modules/sassify/

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!

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 ?

Thanks! Anyone interesting in taking this project over? Given tools like this are part and parcel of a good developer experience these days I feel it is important to keep this project active to attract new devs. I would happily contrib to setting up new docs. Just been mucking around with vuepress, makes docs a cinch.

No problem, ? I know the uninstaller needs some work to be perfect. Uninstalling a shop system and such a huge plugin is nothing trivial. Page<->field<->template dependencies needs to be resolved and you need to be very careful to prevent unintended deletion of your whole products catalogue and templates. I'm just thinking about a "fire-and-forget" uninstaller which can only be called via URL param...

@tpr I don't remember if I have posted this already some time ago... The option "disable all admin animations" practically makes the vec-dialogs unusable. The dialog will appear, but won't disappear when you choose either of the options. You then have no choice than to hard-reload the page. Maybe a word of caution would be nice in the settings. I stumbled over this a long time ago, and recently forget how to fix it.

Update: Blog 2.4.5 Changelog Added new option (see example use below) to MarkupBlog::getArchives() that allows to specify if archive months should be sorted descending (Dec - Jan). Default is ascending (Jan - Dec), thanks to question by @montero4 Fixed bug in template blog-archives.php that caused illegal offset warnings. Module has been updated in the modules directory. Example usage of new getArchives() option getArchives() now accepts a third parameter as an $options array. If you want archive months to be sorted and rendered in descending order (December - January), you will need to pass this as an option in the $options array and set the value 'descending' to they key 'archives_month_sort_order'. Since this is the third parameter for the method, you will need to pass options for the first and second parameters as well. If you want the default ascending order of months, you don't have to change anything in your code. Just call getArchives() as usual without any parameters. Otherwise, read on for descending order of months. <?php $blog = $modules->get("MarkupBlog"); // options: if we want to sort archive months in descending order $archiveOptions = array('archives_month_sort_order'=>'descending'); // get archives: order months descending $archives = $blog->getArchives(0, 1, $archiveOptions); // if you want to render the archives $content = $blog->renderArchives($archives);// order months descending Please test and let me know. Thanks.

This is fixed: in the latest dev version wire/config.php points to the HTTPS URL of the modules directory, and the modules directory also again accepts HTTP connections (which should guarantee backwards compatibility).

Downloading Media From Media Manager Library I was recently asked whether it was possible to download media already uploaded to Media Manager. Currently, there is no automated way to do this. However, using the ProcessWire API, one can achieve this. Below is a starter code showing how one can download image media from Media Manager. I'll consider adding this feature to Media Manager. Please note that I have deliberately left Tracy debugging statements in the code. You will want to wrap this around a check if user is Superuser. // get limited number of media manager images $mmPages = $pages->find('template=media-manager-image, limit=10'); $tempName = 'media_manager_downloads';// temporary name for folder to place images in // 1. MAKE DIRECTORY // @note: could have used $files->tempDir('hello-world'); but not working for some reason // create a new directory in ProcessWire's cache dir $copyTo = $config->paths->cache . $tempName; if($files->mkdir($copyTo)) { // directory created: /site/assets/cache/media_manager_downloads/ // 2. COPY IMAGES // get and copy image assets foreach($mmPages as $p) { $images = $p->media_manager_image; foreach($images as $image) { //bd($image->filename,'image path')// to debug image path $copyFrom = $image->filename; $bool = $files->copy($copyFrom, $copyTo); //bd($bool,'copied?');// just to test if files were copied } } // 3. ZIP IMAGES // if files were copied, zip them if(!empty($files->find($copyTo))){ // create zip of all files in directory $copyTo to file $zip $zip = $config->paths->cache . "media-manager-image-files.zip"; $result = $files->zip($zip, $copyTo); echo "<h3>These files were added to the ZIP:</h3>"; foreach($result['files'] as $file) { echo "<li>" . $sanitizer->entities($file) . "</li>"; } if(count($result['errors'])) { echo "<h3>There were errors:</h3>"; foreach($result['errors'] as $error) { echo "<li>" . $sanitizer->entities($error) . "</li>"; } } // 4. SEND FILES TO BROWSER FOR DOWNLOADING // if files were added to zip file, send them if(!empty($result['files'])){ bd($zip,'files were added'); $files->send($zip); } } else { bd('NO FILES FOUND!'); } } Hope this helps.

Ah! That looks much better... complete code below /** * site/config.php */ $config->appendTemplateFile = '_layout.php'; /** * site/templates/home.php */ $title = $page->title; $shop = $pages->get('/shops/mr-big'); $mainContent = $shop->render('partials/shop-intro.php', ['appendFile'=>null]); /** * site/templates/partials/shop-intro.php */ <div class="shop-intro"> <h2><?= $page->title ?></h2> <?php foreach( $page->shop_photos AS $photo ) : ?> <img src="<?= $photo->url ?>" /><br/> <?php endforeach; ?> <div class="shop-desc"> <?= html_entity_decode($page->shop_description) ?> </div> </div> /** * site/templates/_layout.php */ <!DOCTYPE html> <html lang="en"> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8" /> <title><?= $title; ?></title> <link rel="stylesheet" type="text/css" href="styles.css" /> </head> <body> <h1><?= $title; ?></h1> <div class="container"> <?= $mainContent ?> </div> </body> </html> I like it like this... If anyone has a better way, feel free to jump in.

... and assuming that you don't / can't add all image field names in your code, something like this should also work: $allImages = array(); foreach ($fields->find("type=FieldtypeImage") as $f) { foreach ($pages->find("$f.count>0") as $p) { foreach ($p->$f as $i) $allImages[] = $i; } }