Leaderboard

First of all... thank you @adrian for the introduction and the great work with this module. In the last couple of days I created a DEV branch with some minor changes and fixes I found while testing the latest version (0.4.11). If you are interested in playing around with that version, grab a copy over at Github - the DEV branch is linked below. As always: backup your site and previous module first. All changes so far: FIXED: Vanilla JS version notice toggle didn't work when MANAGE disabled FIXED: Version change didn't trigger reset INFO: Added usage examples (assets/html) CHANGED: Removed CLOSE option ADDED: Datalayer details to README Issue tracking on Github was also enabled. This could make things easier in the future. Feel free to open an issue there whenever you find a bug. Don't forget to add the obvious details (ProcessWire version, PHP version, expected behaviour, your module settings and custom code). DEV-Branch https://github.com/webmanufaktur/CookieManagementBanner/tree/dev Issues https://github.com/webmanufaktur/CookieManagementBanner/issues

@Klenkes @eelkenet @Jens Martsch - dotnetic Thanks, I was able to duplicate and fix the issues mentioned above. Please let me know if you observe any other issues.

I never submitted the newest iteration of my own business site which already is 3 years online, promoting my webdesign/UI/UX/Frontend stuff. "Just" a Onepager, content managed by PW, usage of D3 for the circles and a completely handwritten gallery at the top. But as always, way more hours went into this as expected ? https://siebennull.com

UPDATE 2019-10-18 Some time has passed since the last update. But don't worry I've been working on it! A good back of time devoured the development of our new documentation platform. The new docs website can be found here: https://docs.bitego.com (of course it runs under ProcessWire) Most contents of existing projects are already imported. And I just started with the documentation for SnipWire. Of course development on SnipWire itself has been continued as well: the stability of the REST queries and their processing has been significantly improved the filter (search) functions for the list views (orders, customers, products) have been implemented. native ProcessWire pagination for list views has been implemented more snipcart fields have been added to the product definition several bugs have been fixed Next steps: finishing detail-views for Customers, Products and Orders development of a parallel process that continuously fetches data from Snipcart and makes it available as a local cache. (this should significantly minimize the waiting time for REST queries) implementation of Abandoned Carts Handling implementation of Refunds Handling Thats it for now! I also hope some of you will find the time and testing the current status. I would be very grateful for your feedback.

Hi! I've created a small Inputfield module called InputfieldFloatRange which allows you to use an HTML5 <input type="range" ../> slider as an InputField. I needed something like this for a project where the client needs to be able to tweak this value more based on 'a feeling' than just entering a boring old number. Maybe more people can use this so I'm hereby releasing it into the wild. EDIT: You can now install it directly from the Modules directory: http://modules.processwire.com/modules/inputfield-float-range/ What is it? The missing range slider Inputfield for Processwire. What does it do? This module extends InputfieldFloat and allows you to use HTML5 range sliders for number fields in your templates. It includes a visible and editable value field, to override/tweak the value if required. Features Min/max values Precision (number of decimals) Optional step value (Read more) Optional manual override of the selected value (will still adhere to the rules above) Configurable rounding of manually entered values (floor, round, ceil, disable) Usage Clone / zip repo Install FieldtypeFloatRange, this automatically installs the Inputfield Create new field of type `Float (range)` or convert an existing `Float`, `Integer` or `Text` field. To render the field's value simply echo `$page->field` Demo A field with Min=0, Max=1, Step=0.2, Precision=2 Field with settings Min=0, Max=200, Step=0.25, Precision=2 Todo Make the display-field's size configurable (will use the Input Size field setting) Hopefully become redundant Changelog 008 (current version) - Add composer.json and submit to Packagist, making the module installable via composer 007 - Add defaultValue field (as requested by @charger) - Fix a silly mistake where a negative rounding (-1) resulted in removing all decimals instead 006 - Fix bug where InputfieldFloat negative precision prevented the displayed value to be updated properly - Revert installs & requires, so direct installs from Modules Directory (should) work 005 - Fix bug where the Inputfield would not work properly within repeaters / repeater matrices 004 - Make rounding of manually entered values configurable (floor, round, ceil or disable) - Fix small JS bug where the value-display field was not displayed - Update README 003 - Code cleanup, add some ModuleInfo data & LICENSE - Submit to PW Modules directory (http://modules.processwire.com/modules/inputfield-float-range/) 002 - Fix issue where setting the step value to an empty value created problem with validation - Make the display-field optional 001 - Initial release Thanks!

We recently rebuilt the Architekturführer Köln (architectural guide Cologne) as a mobile-first JavaScript web app, powered by VueJS in the frontend and ProcessWire in the backend. Concept, design and implementation by schwarzdesign! The Architekturführer Köln is a guidebook and now a web application about architectural highlights in Cologne, Germany. It contains detailled information about around 100 objects (architectural landmarks) in Cologne. The web app offers multiple ways to search through all available objects, including: An interactive live map A list of object near the user's location Filtering based on architect, district and category Favourites saved by the user The frontend is written entirely in JavaScript, with the data coming from a ProcessWire-powered API-first backend. Frontend The app is built with the Vue framework and compiled with Webpack 4. As a learning exercise and for greater customizability we opted to not use Vue CLI, and instead wrote our own Webpack config with individually defined dependencies. The site is a SPA (Single Page Application), which means all internal links are intercepted by the Vue app and the corresponding routes (pages) are generated by the framework directly in the browser, using data retrieved from the API. It's also a PWA (Progressive Web App), the main feature of which is that you can install it to your home screen on your phone and launch it from there like a regular app. It also includes a service worker which catches requests to the API and returns cached responses when the network is not available. The Architekturführer is supposed to be taken with you on a walk through the city, and will keep working even if you are completely offline. Notable mentions from the tech stack: Vue Vue Router for the SPA functionality VueX for state management and storage / caching of the data returned through the API Leaflet (with Mapbox tiles) for the interactive maps Webpack 4 for compilation of the app into a single distributable Babel for transpilation of ES6+ SASS & PostCSS with Autoprefixer as a convenience for SASS in SFCs Google Workbox to generate the service worker instead of writing lots of boilerplate code Bootstrap 4 is barely used here, but we still included it's reboot and grid system Backend The ProcessWire backend is API-only, there are no server-side rendered templates, which means the only PHP template is the one used for the API. For this API, we used a single content type (template) with a couple of pre-defined endpoints (url segments); most importantly we built entdpoints to get a list of all objects (either including the full data, or only the data necessary to show teaser tiles), as well as individual objects and taxonomies. The API template which acts as a controller contains all the necessary switches and selectors to serve the correct response in <100 lines of code. Since we wanted some flexibility regarding the format in which different fields were transmitted over the api, we wrote a function to extract arbitrary page fields from ProcessWire pages and return them as serializable standard objects. There's also a function that takes a Pageimage object, creates multiple variants in different sizes and returns an object containing their base path and an array of variants (identified by their basename and width). We use that one to generate responsive images in the frontend. Check out the code for both functions in this gist. We used native ProcessWire data wherever possible, so as to not duplicate that work in the frontend app. For example: Page names from the backend translate to URLs in the frontend in the form of route parameters for the Vue Router Page IDs from ProcessWire are included in the API responses, we use those to identify objects across the app, for example to store the user's favourites, and as render keys for object lists Taxonomies have their own API endpoints, and objects contain their taxonomies only as IDs (in the same way ProcessWire uses Page References) Finally, the raw JSON data is cached using the cache API and this handy trick by @LostKobrakai to store raw JSON strings over the cache API. Screenshots

We're finally launching a redesign of our website! Doesn't feel like it to us, but our previous design was already from 2013 ? https://ed-works.com/ We like to keep things simple, so the only third-party modules that we installed were Tracy debugger, Admin on steroids and Admin Theme Boss, which we tweaked a little bit to our taste. All in all, there's not much going on inside PW. Our main concern was to serve the frontend with responsive images with a close quality to the originals, and for this, it's important that PW allows us to use ImageMagick for resizing them. We also love to use PW's image tags to add classes to the images. In this case, we use them to display the images with three different sizes. We also had to change the templates to serve the projects to the homepage via Ajax. We hope you guys like our new baby ? Edit: I forgot to refer that we also changed our logo and tweaked our name to ED works.

You need to pass your settings to $config->js() in a renderReady() method. https://github.com/processwire/processwire/blob/7d4ca45673152436ea492b6577341ee3550e2821/wire/core/Inputfield.php#L1224-L1244

Hello, thanks for sharing, for everyone who came here like me and the proposal did not work for some reason, I invite you to read the instructions here: It is also important that they use the following web.config file (which contains minor corrections to the code initially shared by @nikola). I hope it helps you with something like me. Regards!

By toggle off, I assume you mean "unpublish"? It's possible, but it's a real mess. However if you read through this: https://github.com/processwire/processwire-issues/issues/36 you'll be able to get it working.

Thanks @wbmnfktr good suggestion. I did already try this though, logged into the cms on Firefox and with an incognito windo open in Chrome to view the front end site. Thanks

It looks like you could use: $config->pagefileSecure More details here: https://processwire.com/api/ref/config/ and of course via search in the forum. ?

Your development environment should have the same prerequisites as on your server. You should have a local web server like Laragon (on Windows) or Xammp installed, and also mirror/replicate the ProcessWire installation with the database from your live server. Then you can make modifications to these local files and upload them to the live server as they are. No conversion needed anymore. I would recommend you to use a translator like deepl.com if you are not very good with english, so your questions can be understood better.

The module has been updated to 004 005. Besides a small JS bugfix, this update makes the rounding of manually entered values configurable (floor, round, ceil or disable completely). Edit: As of version 005 it also works within repeaters / repeater matrix, thanks to @Robin S' help.

Under permissions is a setting where you can archive that users can only edit their own created pages. Like I answered here: To prevent page editing and listing pages in a normal lister or ListerPro I use hooks (this can be made in a custom module or in _init.php): $this->addHookAfter('ProcessPageListActions::getActions', $this, 'restrictListerEditAccess'); $this->addHookAfter('ProcessPageEdit::buildForm', $this, 'removeTabs'); $this->addHookAfter('ProcessPageEdit::buildForm', $this, 'restrictEditAccess'); public function restrictEditAccess(HookEvent $event) { // don't do this for superusers if ($this->user->isSuperuser()) { return; } if ($this->config->ajax) { return; } // bd($event->return); $process = $event->object; $page = $process->getPage(); $form = $event->return; if ($condition !== true) { $this->error("Thou shall not pass"); //$this->removeSaveButton($form); return; } } /** * removes edit links from lister it the user has not the correct edit access * @param HookEvent $event * @throws WireException */ public function restrictListerEditAccess(HookEvent $event) { if ($this->user->isSuperuser()) { return; } $page = $event->arguments[0]; $editAccess = $this->hasEditAccess($page); // this is my own function for checking if the user has edit access, in the core there is $page->editable() if ($editAccess === false || $this->user->hasRole('someRole')) { $actions = $event->return; unset($actions['edit']); $event->return = $actions; } } /** * removes tabs in Edit form for specific roles * @param HookEvent $event */ public function removeTabs(HookEvent $event) { if ($this->user->isSuperuser()) return; $p = $event->object->getPage(); $form = $event->return; // bd($form); $fieldset = $form->find("id=ProcessPageEditChildren")->first(); if (is_object($fieldset)) { $form->remove($fieldset); $event->object->removeTab('ProcessPageEditChildren'); } $fieldset = $form->find("id=ProcessPageEditSettings")->first(); if (is_object($fieldset)) { $form->remove($fieldset); $event->object->removeTab('ProcessPageEditSettings'); } $fieldset = $form->find("id=ProcessPageEditDelete")->first(); if (is_object($fieldset)) { $form->remove($fieldset); $event->object->removeTab('ProcessPageEditDelete'); } // hide delete tab $fieldset = $form->find("id=ProcessPageEditDelete")->first(); if (is_object($fieldset)) { $form->remove($fieldset); $event->object->removeTab('ProcessPageEditDelete'); } }

I've just pushed an update that prevents Exceptions when loading RockTabulator before RockMarkup2 is available: thx @Kiwi Chris

$grid must be a RockTabulatorGrid object, not RockFinder2. It seems that your code is wrong. Thx, I've pushed a fix for this ?

Have you tried Repeaters? This sounds like a good use case for those: each repeater item would include a body field (and possibly a header), and thus you don't have to add lots of individual "body fields" to your template(s). Google doesn't care (or know) about your template structure, it indexes what it sees on the page. If the (rendered, final) page contains specific piece of content, it will likely get indexed by Google. Same answer here: Google doesn't know anything about your templates, it only sees your (public) pages and the content on those, and that's what it's going to index.

@adrian Just a thought, could you go into GH and update your readme to point to the new code under @wbmnfktr's account and also your GH repo to "Archived"? Many thanks for the work you've put into this BTW.

What I forgot to tell: Snipcart recently became even more interesting in terms of cost! Snipcart removed the Pro Pack bundle (70 USD/month) from their pricing. All Pro features will be available on Standard plan: Abandoned carts recovery Real-time shipping estimates Inventory management Custom email templates TaxCloud & TaxJar integrations

Thanks you two ? Is not online anymore. But I have a backup, it was in German:

After making more App stuff (UI/UX/SPA) lately I finally made a website again ? It is the Website of the German Association of Osteopaths. Information about the Association, Osteopathy, workshops, search for Osteopaths (Members) as well as a Membership description plus application form. Mentionable: 100% 100% 100% 100% Lighthouse score with only 121 KB transferred data/8 requests for the start page. Processwire-wise usage of ListerPro (for managing Members and workshops), Form Builder for application of members. Croppable Image for the images. Managing pages with flexible teaser blocks, built with ASM select and core functionality. Pretty fun project especially because client delivered his part on time and we ramped up the thing in 4 weeks (me working part time). https://vwod.de

To be honest I didn't check out that module in a long time, and had even forgotten it existed.. ? But the major differences would be FieldtypeRangeSlider is a full-fledged module with its own API, depends on jQueryUI, and.. has not been updated in 5 years. The one I created is much simpler and light-weight: it's really just a basic HTML5 <input type='range'> with some styling, feedback and validation. As such, it is just another way to use the regular Float/Integer inputfields.

@Noel Boss This is a very good looking theme. ?

Hi,sorry if the topic is covered elsewhere.Background : I'm a part-time, for hobby (ie. not-for-a-living) processwire developer,so I'm probably not very representative of the community, Question : I'm wondering what is the "governance" status of processwire, these days ?With this question, I mean that let's say we segment processwire as follows :1- pw core / roadmap / Ryan new features2- pw core / roadmap / community features requests3- pw core / issues fixes4- pw websites / main site5- pw websites / forum6- pw plugins ecosystem / Ryan commercial extensions7- pw plugins ecosystem / community free + community commercial8- pw weekly...My understanding of the current governance status is :1- : This is Ryan's soverain decisions (for very good reasons ? , with addition of some core members work (on some pull-requests).3, 4- : This is also Ryan driven ; with several core community members doing the diagnosis & triage of issuesAll the above activities (1, 3, 4), along with activity 2-, basically, are funded by the community purchasing Ryan commercial extensions (6).5-, 8- : These are mostly run by several core community volunteer members.Now I'm wondering about 2- :What is the governance system for defining pw roadmap ? for "injecting" the community feature requests into pw roadmap ?Is there some kind of "board" of core members + Ryan, for deciding on the prioritization of these things ? or something like that ?Is there some kind of baseline defined for the breakdown of work on core activities 1- vs 2- vs 3- ?As a not-for-a-living user, I don't have any special nor legitimate expectations about pw roadmap decision-taking (besides having a better understanding of what becomes a feature request which one deposits on github ?But I guess the expectations must be different for other people, who are financially involved in pw ecosystem.And as a side note, I'm also wondering about 7- , as my feeling is that a frontend merging of 6- (which would remain prime) and 7- would, I think, be key for a broader pw outreach beyond the current adopters, for the benefit of the whole community ; something similar to eg. https://www.opencart.com/index.php?route=marketplace/extension thanks for your insights

Hi everyone, a year ago we had put online a first version of our website, which didn't satisfy me much and had several bugs. This year I started working on a complete restyling, both in terms of functionality and graphic. I am very happy with the result obtained. Finally, last week we put this version online that I am proud to show you! Site EU: https://www.playwood.it/ Site USA: https://www.us.playwood.it/ It is an eCommerce for a small StartUp, the PlayWood, based in Reggio Emilia, Italy. The site is multilingual, has two areas of purchase and has two levels of registration. Redirectory based on the source IP for the USA customer and preferred language in the browser for the others countries. It has systems for use registration and sending emails dependent on specific actions, like: registration, purchase, request for quotes, information request, etc. Through the API the site communicates with external platforms such as the management software, Mailchimp and other systems to support marketing and company operations. The site is constantly evolving, in the future we intend to add new features. The site was created with these modules: Padloper Login/register Media Library ProCache PayPal Checkout Subscribe to Mailchimp Tracy Debugger Cookie Management Banner Continent and country names ImagePicker Field Map Marker External libraries: Spectre, scss framework Swiper slideshow verlok/lazyload fancybox Creating this site with ProcessWire represented a moment of strong professional growth. When I started I had little knowledge of some types of language, but Processwire and its APIs give me the ability to easily build pages, manipulate data and integrate any external library easily. Thus, I was able to deepen my knowledge more and more. So I wanted to thank the creators of the cms, who keeps it and who implements it, obviously all the people in the forum for the help they gave me, was very important. Thank you!