Leaderboard

Reactions is a module that collects reactions for pages from site users/visitors based on a click of a reaction button. It's basically the same thing as those "did you find the information you were looking for" thingies you see on some sites. An example of what the buttons might look like: There is also a very simple process module that displays pages along with their reaction counts for each enabled reaction type. GitHub repository: https://github.com/teppokoivula/reactions Modules directory: https://processwire.com/modules/reactions/ Needed this for a project and was kind of in a hurry, so it's not super polished, but seems to work well for basic use cases. One thing that's kind of fun (or scary) about this module is that it modifies the structure of the reactions database table automatically based on active buttons; this is done using ProcessWire's built-in features ? Getting started You can install the module the usual way; clone or download the code, or install via admin. Or via Composer: composer require teppokoivula/reactions The easiest way to define available buttons is via site config: $config->reactions = [ 'reaction_types' => [ 'like' => [ 'title' => 'Like it', 'icon' => '<svg xmlns="http://www.w3.org/2000/svg" height="24" viewBox="0 -960 960 960" width="24"><path d="M720-120H280v-520l280-280 50 50q7 7 11.5 19t4.5 23v14l-44 174h258q32 0 56 24t24 56v80q0 7-2 15t-4 15L794-168q-9 20-30 34t-44 14Zm-360-80h360l120-280v-80H480l54-220-174 174v406Zm0-406v406-406Zm-80-34v80H160v360h120v80H80v-520h200Z"/></svg>', // optional attributes, either as an associative array or as a string, e.g.: // 'attrs' => [ // 'data-some-attr' => 'value', // ], // 'attrs' => 'data-attr="value"', ], 'love' => [ 'title' => 'Love it', 'icon' => '<svg xmlns="http://www.w3.org/2000/svg" height="24" viewBox="0 -960 960 960" width="24"><path d="m480-120-58-52q-101-91-167-157T150-447.5Q111-500 95.5-544T80-634q0-94 63-157t157-63q52 0 99 22t81 62q34-40 81-62t99-22q94 0 157 63t63 157q0 46-15.5 90T810-447.5Q771-395 705-329T538-172l-58 52Zm0-108q96-86 158-147.5t98-107q36-45.5 50-81t14-70.5q0-60-40-100t-100-40q-47 0-87 26.5T518-680h-76q-15-41-55-67.5T300-774q-60 0-100 40t-40 100q0 35 14 70.5t50 81q36 45.5 98 107T480-228Zm0-273Z"/></svg>', ], 'haha' => [ 'title' => 'Haha!', 'icon' => '<svg xmlns="http://www.w3.org/2000/svg" height="24" viewBox="0 -960 960 960" width="24"><path d="M480-260q68 0 123.5-38.5T684-400H276q25 63 80.5 101.5T480-260ZM312-520l44-42 42 42 42-42-84-86-86 86 42 42Zm250 0 42-42 44 42 42-42-86-86-84 86 42 42ZM480-80q-83 0-156-31.5T197-197q-54-54-85.5-127T80-480q0-83 31.5-156T197-763q54-54 127-85.5T480-880q83 0 156 31.5T763-763q54 54 85.5 127T880-480q0 83-31.5 156T763-197q-54 54-127 85.5T480-80Zm0-400Zm0 320q134 0 227-93t93-227q0-134-93-227t-227-93q-134 0-227 93t-93 227q0 134 93 227t227 93Z"/></svg>', ], ], ]; ... though you could also add them programmatically, e.g. if you wanted to manage them via admin: $wire->addHookBefore('Reactions::setReactionTypes', function(HookEvent $event) { $reaction_buttons = $event->wire()->pages->get(1)->reaction_buttons; if ($reaction_buttons->count()) { $reaction_types = []; foreach ($reaction_buttons as $reaction_button) { if (!$reaction_button->title) continue; $reaction_types[$reaction_button->name] = [ 'title' => $reaction_button->title, 'icon' => $reaction_button->icon && $reaction_button->icon instanceof Pageimage ? $reaction_button->icon->filename : null, ]; } if (!empty($reaction_types)) { $event->arguments(0, $reaction_types); } } }); The module has basic styles and scripts bundled in, though you'll have to load them yourself: <link rel="stylesheet" href="<?= $config->urls->Reactions ?>styles/reaction-buttons.css"> <script src="<?= $config->urls->Reactions ?>scripts/reaction-buttons.js"></script> ... and then call the render method to render the buttons in your template file(s): <?= $modules->get('Reactions')->renderReactionButtons() ?> For those interested in doing stuff like displaying something based on the answer, bundled JS triggers an event that you can listen to: document.dispatchEvent(new CustomEvent('reactions-updated', { detail: { pageID: pageID, reaction: reaction, }, }, { bubbles: true }));

There's no such thing as an ignorant question, but in this case I would probably lean towards "unnecessary headache" ? If ithe goal is to use some data from Strapi and combine that with some content produced in ProcessWire, this might make sense. E.g. the data from Strapi would only cover part of the project. But if the client wants to continue to manage all their content in Strapi and you'd just be using ProcessWire for the front-end, this would mean that you'd be mitigating much of what ProcessWire has to offer. Not to mention that it might be a bit of work to make the systems run smoothly together, and when things inevitably change in the future, you'd be doing every update to the content structure twice: once in Strapi, and again in ProcessWire. I'm not familiar with Strapi, but I'm pretty sure they have a decent API already (considering that it's a headless CMS that's kind of their bread and butter) so personally I'd consider building the front-end using something else. Laravel might be a decent PHP choice, but there are many other solutions as well. Most commonly folks seem to combine Strapi and similar headless systems with some JS framework, e.g. https://strapi.io/integrations/vuejs-cms. Anyway, that's just my opinion ?‍♂️

When $config->debug and $config->advanced are true there is an "Autoload disabled" checkbox available in the module info for any autoload module. Checking this box disables the module in the same way as Tracy's Module Disabler panel, but might be useful on a site that doesn't have Tracy installed.

If the file vendor/autoload.php exists, it will be called automatically by ProcessWire's index.php. No need to call it manually.

Padloper 009 I am pleased to announce the release of Padloper 009! It has been a minute! I apologise for the delay. Padloper 009 introduces a number of new features, bug fixes (especially in Multilingual sites) and improves overall code efficiency. Credits Before I get into the details, I would like to say massive thanks for all who have contributed to this release in various ways. You have contacted me via the forums, via PM and via email to report bugs, test Padloper and suggest and sponsor new features. In particular, I would like to thank (in no specific order) @Spinbox, @alexm, @joe_g, @ank, @csaggo.com, @Jan Fromm, @Pete, @Sonia Margollé and @kalimati. Whilst I will not name those who contacted me privately, please accept my gratitude for your help. Apologies if I forgot to give anyone a mention! Massive thanks to @ryan for ProcessWire. Padloper 009 is the most battle-tested Padloper yet! It has been tested and developed on high volume sites, sites that require lots of customisations and multilingual sites whose default language is not English. This robust development has helped fix bugs that I would not have been aware of otherwise as well as new ideas and features to improve the API, workflow and GUI of Padloper. Many of the suggested features have made it into this version. A few others are planned for the future. There is a lot to talk about in this version. Below I’ll just give a summary of the changes and where necessary, create separate topics to discuss some of the new features. Although Padloper 009 has undergone thorough testing, there might, inevitably, be some bugs. If you find one, please let me know in the forums under a separate topic. Thanks! Changes Features Home Customisable dashboard. You can render your own dashboard by creating a template partial named ‘padloper-process-render-shop-home.php’ and placing it at ’/site/templates/padloper/backend/padloper-process-render-shop-home.php’. Please see this thread for more details. Orders Customisable single order view. You can render your own dashboard by creating a template partial named ‘padloper-process-render-orders.php’ and placing it at ’/site/templates/padloper/backend/padloper-process-render-orders.php’. Please see this thread for more details. Order status actions: Can be applied manually for order, payment and shipping status. Quick filters e.g. ‘open’, ‘cancelled’, ‘abandoned’, etc. Products Configurable pricing fields. Sales and Normal Price (e..g WooCommerce) vs Price and Compare Price (e.g. Shopify). Please see this topic for more details. Categories can optionally be named ‘Collections’. Configurable via ‘/admin/shop/configure-padloper/’. Bulk clone existing products. Allow duplicate titles for products. Discounts (new) 4 discount types: Orders, products, free shipping and BOGO (Buy One/Get One - unfinished; see below). Can be applied manually or automatically at checkout. Please see this thread for more details. Add/remove via ‘/admin/shop/configure-padloper/’. Part sponsored by Nifty Solutions. Thanks @Pete! Customers and Customer Groups (new) Customer creation and management. Please see this thread for more details. Customer Groups. This feature will be expanded in the future. Please see the above thread for more info. Add/remove via ‘/admin/shop/configure-padloper/’. General Settings Redone interface Add ‘from email’ settings.. Add bank details settings.. Add order ‘least and most’ sales thresholds for orders’ quick filters. Settings for ‘low stock’ and ‘price fields’ for products. Add tab ‘user interface’ with settings for shop navigation (can have side menu and/or dropdown navigation) and search features (can use quick filters and/or advanced filter). Other Backend Quick filters on various dashboards. Custom Dashboards for Home and Orders. More to be added in future. Frontend Custom shop root page. This allows you to move product-related pages and legal pages to live under a frontend-accessible page. Configurable via /admin/shop/configure-padloper/. Please see this topic for more details. For instance, /myshop/products/, /collections/, /products/, etc. This means you can directly access products on the frontend using their real paths/urls instead of using URL segments. This setting can be changed anytime via configuring Padloper at /admin/shop/configure-padloper/. Custom URL segments for checkout out. E.g. instead of /checkout/success/, /checkout/confirmation/, etc., you can have custom, multilingual segments, e.g. /checkout/order-success/, /checkout/tilaus-menestys/, etc. Miscellaneous Various UI improvements. Dashboards tables sorted by title by default. Breaking Changes Template partials for the frontend have been moved from /site/templates/padloper/ to /site/templates/padloper/frontend/. Deprecated ‘Search Feature’ on the home dashboard has been removed. Use ProcessWire in-built search instead. Padloper hooks into it to group padloper related results. PadloperProcessOrder::orderSaved now becomes PadloperProcessOrder::orderSavedHook.The new approach is to have all hooks in one please for easier maintenance and usage. Bug Fixes Please see the bug fixes topic. How to Get It Padloper 009 is available at https://processwireshop.pw/products/padloper/. For those renewing subscriptions, you will have to wait a bit, apologies. I am finalising work on renewal codes. I am hoping this will be ready by tomorrow. Any issues with the (revamped ?) site please let me know ?. Upgrading This is a major upgrade. Lots of code has been moved around. Best way to upgrade files is to empty the contents of the root Padloper folder and upload the contents of the new version there. There are no data model changes affecting existing features but as always, back up your site(s) first! Next Steps In addition to fixing any bugs that show in 009, these are the plans for the next 3-6 months, possibly more, in order of priority. No new features will be introduced until these are completed. Documentation Documentation will cover all topics including installation, backend and frontend use and the API. ‘How to guides’ will consist of short videos with corresponding textual content on a dedicated Padloper site. Discounts Finish work on the Buy One Get One (BOGO) Discount and automatic discounts. Gift Cards Finish work on Gift Cards. Road Map I will talk about this when the ‘next steps’ tasks have been completed. Thanks!

Presentation Originaly developped by Jeff Starr, Blackhole is a security plugin which trap bad bots, crawlers and spiders in a virtual black hole. Once the bots (or any virtual user!) visit the black hole page, they are blocked and denied access for your entire site. This helps to keep nonsense spammers, scrapers, scanners, and other malicious hacking tools away from your site, so you can save precious server resources and bandwith for your good visitors. How It Works You add a rule to your robots.txt that instructs bots to stay away. Good bots will obey the rule, but bad bots will ignore it and follow the link... right into the black hole trap. Once trapped, bad bots are blocked and denied access to your entire site. The main benefits of Blackhole include: Bots have one chance to obey your site’s robots.txt rules. Failure to comply results in immediate banishment. Features Disable Blackhole for logged in users Optionally redirect all logged-in users Send alert email message Customize email message Choose a custom warning message for bad bots Show a WHOIS Lookup informations Choose a custom blocked message for bad bots Choose a custom HTTP Status Code for blocked bots Choose which bots are whitelisted or not Instructions Install the module Create a new page and assign to this page the template "blackhole" Create a new template file "blackhole.php" and call the module $modules->get('Blackhole')->blackhole(); Add the rule to your robot.txt Call the module from your home.php template $modules->get('Blackhole')->blackhole(); Bye bye bad bots! Downloads https://github.com/flydev-fr/Blackhole http://modules.processwire.com/modules/blackhole/ Screen Enjoy

Hi all, my proposal is, that every module should have an "active" checkbox, which allows to quickly deactivate it, instead of being forced to uninstall/reinstall it. Like AdminOnSteroids had and TracyDebugger has. Best regards!

Hey @netcarver and @gebeer great news for you (and all RockFrontend users) I've fixed an issue with ajax endpoints not replacing ALFRED markup (thx for the report @gebeer) and while working on that I got quite a lot of errors in the console about the livereload stream having a wrong mimetype, which has also been observed and reported by @netcarver some time ago. So I fixed that as well ? Please try the latest version on the dev branch, which will be merged to master in some days. LiveReload only reloads the visible tab. This is to avoid endless loops where one window reload causes the other one to reload as well and vice versa. In older versions you had to reload the tab manually once you switched back to it. In the latest version it will wait and as soon as you switch back to the tab it will be reloaded automatically if a file changed in the meantime ?

Thank you @Ivan Gretsky! Your ideas are what I was looking for. My goals are more for a user navigation perspective than SEO. Until now, this page can be reached only by modifying URL bar, but my clients do that apparently! (I do too sometimes). I think 2. is the best option for my case. Thank you again!

Hi @rooofl! What are your goals? Is SEO a conсern? Best practices should always help achieve a goal. Anyway, let me add some options to go under "something else": Create a template for projects and out put nothing there but a link to the main page. Optionally restrict its indexing. Make sure no links point to that page (take care of breadcrumbs if you have them). This way noone but freaks who like to modify the url bar in the browser will ever get there. Same as 1 but add a redirect. You could put it in the template file for projects with something like this. Maybe with 303 or 307 code. If you really care about the beauty of the urls, could make use of url segments and make your project pages be accessible as home/project1. But that would require some work. You could put something useful on the projects page' Like a search box.

[SOLVED] The source of the error has been found. There were two closing </body> tags in the HTML layout. This caused the JS script to be called twice.

@nurkka - I agree, but a couple of things that might help you in the meantime. If you install https://processwire.com/modules/module-settings-import-export/ it will automatically backup module settings when it's uninstalled so that you can easily get settings back where they were when you reinstall it. Also, Tracy's Module Disabler panel can be helpful to disable modules without uninstalling - the catch is that it needs advanced and debug modes turned on to work.

Well, one is a spider and the other is a club that I'd use to kill spiders with. I vote for Padu #2.

UPDATE 2022 Simple and powerful - put this at the end of your config.php file: $localConfig = __DIR__ . "/config-local.php"; if (is_file($localConfig)) include $localConfig; Then put all local settings into config-local.php (same concept for DEV/STAGING/PRODUCTION): <?php namespace ProcessWire; /** @var Config $config */ $config->debug = true; $config->advanced = true; $config->dbName = 'db'; $config->dbUser = 'db'; $config->dbPass = 'db'; $config->dbHost = 'db'; $config->userAuthSalt = '1234'; $config->tableSalt = '1234'; $config->httpHosts = ['xyz.ddev.site']; // this prevents logout when switching between // desktop and mobile in chrome devtools $config->sessionFingerprint = false; // RockFrontend $config->livereload = 1; // RockMigrations // $config->filesOnDemand = 'https://your-live.site/'; $config->rockmigrations = [ 'syncSnippets' => true, ]; // tracy config for ddev development $config->tracy = [ 'outputMode' => 'development', 'guestForceDevelopmentLocal' => true, 'forceIsLocal' => true, 'localRootPath' => '/Users/xyz/code/yourproject/', 'numLogEntries' => 100, // for RockMigrations ]; $config->rockpagebuilder = [ "createView" => "latte", ]; -------------------- OLD POST from 2018: Have you ever come across the situation where you needed to change your config.php file for local development? Have you ever come across this warning? Say goodbye to this little annoying tasks Some of you might know that you can have a separate config-dev.php file for local development. This is nice, but also needs some setup (for example excluding this file for git upload) and there is still some danger of uploading this file to a place where it should not be... The other option was to keep the database settings for your live and dev server in sync - also not easy and maybe not the best... My solution is as simple, fast and I think it should be even safer than the other options. Just put these lines at the end of your config.php file: if(strpos($config->paths->root, 'C:/www/') === 0) { $config->dbUser = 'root'; $config->dbPass = ''; $config->httpHosts = [$_SERVER[HTTP_HOST]]; $config->debug = true; } elseif(strpos($config->paths->root, '/var/www/vhosts/') === 0) { $config->httpHosts = []; $config->dbUser = 'XXX'; $config->dbPass = 'XXX'; $config->debug = false; /** * Redirect to HTTPS * ATTENTION: This will NOT work with ProCache enabled! Use .htaccess instead */ if(empty($_SERVER['HTTPS']) || $_SERVER['HTTPS'] == "off"){ $redirect = 'https://' . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI']; header('HTTP/1.1 301 Moved Permanently'); header('Location: ' . $redirect); exit(); } } else die('wrong config.php'); Having a separate config-dev.php file also makes it necessary to keep both files in sync. That was my first idea: To include the original config and then overwrite settings. But it's just simpler the other way round: Using the default config.php file and overwriting settings there.