Leaderboard

Here is the first very early concept of a Page Builder. As per the conversation in the 'ProcessWire beyond 2021' conversation, I set myself a challenge to make a clone of YOOtheme Pro's Page Builder. This was mainly spurred by @Jonathan Lahijani's excellent overview of ideas of a page builder for ProcessWire. This is still in very early stages and I am not really sure where it is headed. I would like to hear the thoughts of like-minded persons ?. I would especially love to hear from @Jonathan Lahijani, @szabesz, @AndZyk and @flydev ?? please. Concept The page builder in its current state is a Fieldtype + Inputfield supported by other behind-the-scenes Fieldtypes without Inputfields. There are no hidden or extra pages in contrast to Repeater Matrix. All values are stored in the Page Builder fields for the page being edited. The fields do not store values as JSON. Definitions for elements, rows, grids, etc as stored as JSON. Currently, for storage purposes, 4 datatypes are supported - Text (HTML), images, plain text and headlines. From a storage perspective, the latter two are one and the same. Just texts with different 'schemas/definitions'. More on this below. The fields are multitype fields. This means one page can hold multiple texts, allowing for repeatability. Similar datatypes are stored together in one field/table. For instance, there is no reason why a (future) URL element (datatype) should not be stored in the same table as plain text. At the database level, they are both just texts with similar requirements. At the processing level, URLs vs other plain texts (headlines, etc) are handled differently (validation, sanitisation, etc). Each 'element' represents a row in a table for most types (e.g. slideshows are slightly different). Querying and access of field values is via the main Fieldtype - FieldtypePageBuilder. However, the supporting Fieldtypes can be also be accessed and queried individually, if one wishes, using normal ProcessWire selectors. The supporting Fieldtypes, if such need arises could easily become custom tables instead (but best to keep them as Fieldtypes - easier querying with selectors, etc). It is totally CSS-agnostic in relation to frontend output. You bring your own CSS. In the preview, you can also use your own CSS. In the frontend, you can choose to output raw values as you wish or use inbuilt render methods to render the whole layout for you or to render the value of an element as per its tag definition (e.g. headlines as h2, h4, etc) where applicable. Fully multilingual (although the editing UI not yet implemented). Issues The main issue is the real estate needed for InputfieldPageBuilder. Any such page builder would require the whole width of the window. As you can see from the screenshot below, this obviously throws things out of kilter with respect to the ProcessWire page edit UI, in any theme (I believe). I am not a designer so would love to hear from you about possible solutions. My current thoughts are: Modal Open the page builder in a modal for editing. Pros Would allow for use of whole real estate. Title and other fields would not be in the way. Cons Editing in modals can be tricky? Other..? Process Module Pros Solves the real estate issue. Cons Disconnect between the page being edited/created and the page tree. Screenshot No attempt has been made to theme it as per any current ProcessWire theme (that I know of). This was a quick and dirty-ish clone of YTPB. As stated, however, the current ui is not acceptable as an Inputfield for, mainly, real estate reasons. Video Demo This is a demo for the Page Builder app outside ProcessWire. Thoughts? Thanks. PS: I currently have no time to continue working on this (Padloper, etc..)

Around 3yrs ago I got excited about Progressive Web Apps (PWAs) and found a site that magically created an offline experience with a few clicks. It worked until it didn't. Had to backtrack and remove the PWA code on lots of sites due mainly to exceeded offline cache storage causing problems. My JS skills weren't, and still aren't, up to the level of expertise needed to rectify. I still did the manifest.json thing, reduced the network load wherever possible and got some great Google Lighthouse performance results by tweaking PW especially with ProCache. 3yrs is a long time in web life. If 1 dog year = 7 human years, then 1 web year must be 10+ human years. I delved back into PWAs recently and Google Workbox in particular. The biggest hurdle I had to overcome was Google's own Workbox docs. Forget the "Import" statements and the CLI easy PWA method recommended in the docs. They don't (or I could not get them to) work with ProcessWire. They're geared to web apps like React that have a build process that publishes to a directory eg 'app'. ProcessWire doesn't work that way. So here's what worked for me: Create a template. I called mine "offline" that may only have one page, no children and does not have a trailing slash at the end of the URL. Create a page, add fields as necessary, eg 'body' and apply the 'offline' template and save as a child of "Home" Change the page url to 'offline.html' - this is the default page name for Workbox. Easier to change this than fiddle around overriding the Google Workbox defaults. For extra comfort, I made the page name 'Unique' and 'Hidden' from lists and searches. Ensure the workbox service worker javascript is NOT appended to the offline.html page On all other pages append the following to the <body> tag. I'm using Regions so this goes in my <region id="regFooterScripts"> in _main.php <?php if ($page->name != "offline.html") : ?> <script> if ('serviceWorker' in navigator) { let scrUrl = '<?=$pages->get('/')->httpUrl?>sw.js'; window.addEventListener('load', () => { navigator.serviceWorker.register(scrUrl, {scope: '/'}).then(registration => { console.log('Service Worker registered: ', registration) }).catch(registrationError => { console.log('Service Worker registration failed: ', registrationError) }) }) } </script> <?php endif; ?> Next, by hook or by crook, get the workbox library into a directory of your PW project. You can use the CLI 'copyLibraries' feature. See https://developers.google.com/web/tools/workbox/modules/workbox-cli for more info. Do NOT use any of the other CLI features! You can also download the library from gitHub. Didn't go there so please don't ask for help. I used the CLI method & saved the files to site/templates/scripts/workbox. Now you can start building your sw.js file which is saved in root directory. Here's mine using the Google Workbox docs & recipes. The big thing to remember is NOT to "Import" anything despite what the docs say. When you configure workbox to use your local copy of the library, all importing is done for you by using the 'workbox' namespace. importScripts('/site/templates/scripts/workbox/workbox-v6.0.2/workbox-sw.js'); workbox.setConfig({ modulePathPrefix: '/site/templates/scripts/workbox/workbox-v6.0.2/', globIgnores: ['processwire/**.*'] // change according to your PW admin URL }); // Include offline.html in the manifest workbox.precaching.precacheAndRoute([ {url: '/offline.html', revision: null } ]); workbox.routing.registerRoute( ({url}) => url.pathname.startsWith('/processwire/'), // change according to your PW admin URL new workbox.strategies.NetworkOnly() ); workbox.recipes.googleFontsCache(); workbox.recipes.pageCache(); workbox.recipes.staticResourceCache(); workbox.recipes.imageCache(); workbox.recipes.offlineFallback(); These are all the basic workbox features & recipes including offline.html and will probably need updating as time goes by. Up to you to add/modify/delete as you like and outside the scope of this tutorial. Good luck & have fun with Google Workbox PWAs in ProcessWire sites.

I think both would be nice ?

Hi @psy, thanks for the tutorial. I've implemented workbox in the Architekturführer Köln project, though I used the Workbox webpack plugin to generate the service worker (which is easier for JavaScript-applications that use Webpack anyway, not for ProcessWire sites). A couple of things that stood out to me in your guide: What's the purpose of not including the service worker on the /offline.html page? Service workers have a seperate lifecycle from individual page visits. Once registered, they will stay active until replaced or manually removed. It shouldn't matter if the registration code is repeated on the offline fallback page. One way to improve the user experience would be to precache important pages, so they will be available offline even before the user has visited them! See https://developers.google.com/web/tools/workbox/modules/workbox-precaching The list of pages to precache could even be generated dynamically, maybe have a checkbox on all pages to allow them to be precached, expose that list to the service worker and take it from there ... Seems like you're jumping through many hoops just to avoid having a simple build step for your JavaScript code. I often see people shy away from JavaScript compilation and actually make their job much harder because of this, but your code could be much simplified with a simple JS build step that would take only a couple of lines of configuration to set up. This will make it much easier to use libraries like Workbox, since you can just follow the installation and setup guides without having to, for instance, find workarounds for imports. I've written a guide on how to setup a basic JavaScript build step with ParcelJS on processwire.dev, take a look if you're interested. (Admittedly, Parcel seems kinda dead, nowadays I would recommend using Webpack 5. Or Snowpack, which seems to be all the rage right now ? ) Finally, and I know this may be personal preference, I feel like the whole "offline.html" thing is kinda ... superfluous? For an app / SPA, yes, I would expect a custom offline notification screen. But for a classic website with individual page loads, telling me I'm offline on a custom page with your logo on top doesn't really help me in any way, since it doesn't offer anything that the "you're offline" page of the browser can't …

This is the ProModule Textareas amd it is supposed to be there. Maybe a failed upload of files during the update?

Well... what module is affected and which versions of PW are you running. This kind of error is uncommon to me at least. It looks like the regular textarea field needs an update so this error is even more... weird. Are you running a special kind of setup... like IIS oder NGINX or... whatever?

This post might help you: Specifically the Page::editable and Page::addable hookable methods.

Combine the power of ProcessWire selectors and SQL Differences to previous RockFinder modules RockFinder3 comes with extensive docs ? RF3 supports chaining: $RockFinder3->find("template=foo")->addColumns(['foo']). RF3 fully supports multi-language. RF3 makes it super-easy to add custom columnTypes. RF3 makes it easier to use custom SQL statements. No bloat! The module does just do one thing: Finding data. Differences to findRaw Background: RockFinder has been there before findRaw existed findRaw makes it a little easier to query page fields, but RockFinder is more flexible in that regard RockFinder might be faster than findRaw: see here DOCS & DOWNLOAD: https://github.com/baumrock/rockfinder3 Thanks for using RockFinder3. If you find RockFinder3 helpful consider giving it a star on github or saying thank you. I'm also always happy to get feedback in the PW forum! Happy finding

Good day, @teppo! There is a rather empty Patterns and practices section in the docs. I got a suggestion for what to put there. Or should it be in examples? Anyway... Could you describe how does the template with a controller handle get variables and/or url segments? I do not quite understand that, as I have no prior experience with general purpose frameworks.

@Erik - it doesn't look like @Pete is maintaining this module anymore. Give https://processwire.com/modules/protected-mode/ a go - it also has the advantage of optionally sending proper 503 headers when you're using it for blocking access during maintenance downtime.

Hi @flydev ?? - yeah, @Robin S and I have been discussing this one. As @bernhard mentioned to you, this is a change in the Tracy core. I have mixed feelings about the change - it is kinda nice seeing the actual bd() call that was made, I do find myself hovering to see the file/line quite often. Unfortunately I think to change this behavior, I'll probably need to hack the Tracy core. Note that I am already moving the position of that element compared to the core because they had it top right which is really messy if the bd() call is long. Curious what others think of this - do we need to revert this, or do you like seeing the bd() call next to each dump? Would it be better if both the bd() and the file/number were visible?

I found what I was trying to remember. Try what is said in this thread, last answer, it seems it's a related issue (I have the same one in a setup). Direct answer: Modules order in the db.

Thanks @adrian i'll give a look, i ended up using this mentioned module https://github.com/Toutouwai/RepeaterImages

Oke thanks @Klenkes Then he should also verify namespaces on the templates / modules following the stack-trace. I have an issue like this on an install, due to a namespace error, I have to rename each modules called then installing it again.

I don't know why you have this module in `site/modules`. 1 - make a backup 2 - rename the folder `FieldtypeTextareas` to : `.FieldtypeTextareas` and refresh modules, then if you are invited to select a module between `site/modules` and `wire/modules`, choose the last one. 3 - report here

I have a bank account, some fifty online accounts with various providers, have to look at unsave sites because I moderate forums, run a small wiki historical material, love to play with software, must run windows from time to time because some of my hardware uses drivers that won't run in Linux. I am looking very closely at this. It seems much more useful than just a Linux box with a VirtualBox inside.

@ryan - any reason why Soma's PageEditSoftLock has been removed from the modules directory? I still install that on all my sites so it would be great to have it back please. Thanks!

Hi @flydev ??, I haven't made a firm decision yet but it may not be ready before the launch.

I was also thinking of mentioning it, however, Unipoly seems to implement a lot "more features" and its more advanced, soon to be released new version can be expected in weeks: http://triskweline.de/unpoly2-slides/#1 Note, that while these libraries are similar, but they are far from being the "same". Unipoly is opinionated while HTMX "is not" (at least not that much...), which is a big difference. However, Unipoly offers a lot more out of the box, so I'm myself thinking of using Unipoly v2 in the future. Unipoly v2 also – optionally – supports Bootstrap which is good for even more rapid development. I'm not a big fun of Bootstrap, but Bootstrap 5 and Unipoly 2 looks like a good combo, so I will definitely find some time to test them together in the near future.

It would be great if Wireframe got it's own Module-Specific Support forum.

It worth to mentions https://htmx.org/ the successor to intercooler.js.

The work on the project got seized so no the need is no longer valid.

Hi HI David, in PW any function in a module that has ___ at the start, like ___handleApiRequest() in the AppAPI module you can use as a hook in your own code. See https://processwire.com/docs/modules/hooks/

This tutorial is largely to remind myself of the sequence of steps, but if this helps someone else too, that's wonderful! I've recently moved several PW sites to another host, and I've been refining the order of steps to minimize downtime. Please note, this tutorial is for those moving a site from one host to another host, NOT for local computer to live host (although certainly the same general principles apply). This is written from the point of view where both web hosts have cPanel - for convenience I only use hosts which have cPanel. The nameservers are one of the last changes you'll make, so don't do that yet! In the old host, go to phpMyAdmin and export the database to your local computer. In File Manager, export your website files as a zip and save to your local computer. Do the same for your email files (e.g. inbox and sent folder). Please note that if you get a lot of email coming through, and/or if you do not plan to complete all the following steps quickly, you might need a more sophisticated solution so as not to miss emails while switching over. Think about what you want your new db, db user, and db password to be (I like to change all this for security reasons). Even if you wished to keep these identical, you couldn't, because your new host will automatically force a different prefix for the db and db user, so you'll wind up with a new db and db user name anyway. The next steps are all done in the new host. In MySQL Databases in the new host, create a new database, db user, and user password from what you decided above. Also, still in MySQL Databases, add that user to the database (this is surprisingly easy to forget). In phpMyAdmin, import the database you exported from before into your freshly created empty database. If your domain name is NOT the main domain name of your new hosting account, create the new domain using Add-on Domains. Otherwise, move on. Go to the main directory for that domain (if your domain is the main domain of your hosting account then public_html, otherwise the folder of your new add-on domain), and upload your zipped website files there and unzip. Go to site/config.php and edit dbname, db user, and user password so that they match the new ones you set up. At this point, be sure you at least have a plan for SSL before moving forward. If your host does AutoSSL that's probably the easiest, at least to get started. If not, or if you're doing e-commerce, look into purchasing a new SSL cert that fits your requirements, either through your host or via a 3rd party if your host allows installation of 3rd party SSL certs. Just as importantly as minimizing downtime, you'll also want to minimize the time your site is without SSL. Then, and only then, change your domain's nameservers at your domain name registrar to point to the new host. Once this change is live, set up SSL right away - however you want to do that is up to you. For cPanel hosts running AutoSSL, just go to SSL/TLS Status and click on "Run AutoSSL" - wait until that domain's status turns green, it could take several minutes. Finally, set up your email on the new host and move the mailbox folders over (don't forget the "sent" folder!) Optional: If you have Softaculous (which I highly recommend for its auto backup capabilities), go into Softaculous, go to "ProcessWire" and click on "Import" and go for the local option not the remote one. Select your site in the fields and it will automatically import your PW installation. Then to set auto backup schedule, still in Softaculous, go to "all installations" at the top right menu, then on your list of installations go to "edit" (the pencil symbol) next to your new domain's installation. Leave all details the same except for "Automated backups" - select your desired backup rotation options and then click "Save installation details".

As @Robin S noted in the post that @3fingers linked to - that example is a Page reference field. I just recreated that here and it works as expected: A little OT, but creating Page Reference fields is really quick and easy with: https://processwire.com/modules/process-page-field-select-creator/

Just a small question about payment gateways. Have you a plan to release something like an abstract class to be able to be ready on the lunch of the version 2 ? I made last week a module to manage payment trough VivaWallet which I would like to port to PadLoper v2 asap.

Compared to v2, there is still one feature missing in v3 of Snipcart: Recurring subscriptions As soon as v3 is feature complete I'll starting development on v3 support.

This is a textformatter module that will automatically replace titles of other pages on your site with links to those pages. For example, if you have a template glossary-term, and mention the exact title of one page using that template in a textfield, the title will be automatically linked to that page (if the textfield uses that formatter). This is good for SEO, and saves you some manual labour. You can configure which templates should get automatically linked, and of course the formatter is only active for the fields you add this formatter to. Note that if you need more manual control over when and where titles are automatically linked, you're probably better of using Autolink from a Glossary by @mr-fan. Features Allows you to limit the automatic links by template. Only includes published & visible pages by default, with an option to include hidden pages. Automatically excludes the current page, with an option to change that behaviour. Allows you to configure the minimum title length for linked pages. Doesn't overwrite existing links, and detects most edge cases (titles inside other tag's attributes, titles inside existing links et c.). Supports multi-language sites. Titles will only be linked if a title in the current language is set. Can add configurable attributes to all automatically created links. This includes the ability to use page fields as replacement patterns for attributes. For example, you can create CSS classes that include the name of the template of the linked page. Extensive options and hooks to change the generated markup completely. Need <mark> elements with a title attribute based on a page field instead of a link? No problem. See the example project below. Prefer oldest or newest page in the case of duplicate titles. Queries the database directly for improved performance. Has options to switch between case sensitive and case insensitive modes, and force case sensitive behaviour even for case insensitive database collations. Allows you to overwrite the module configuration via the API to call the module with different settings for different requirements on the same site. Download & Documentation The module is now available in the modules directory: https://modules.processwire.com/modules/textformatter-page-title-links/ You can download & install it through the backend using the classname TextformatterPageTitleLinks. To install it manually, download or clone the module from the Github repository into your site/modules folder and install through the backend. The complete documentation can be found in the README in the repository. Make sure to check out the module configuration page after installing the module. Requirements PHP 7.1 or higher ProcessWire 3+ (it will probably work in older versions, I haven't tested those though). This is my first module, I hope it may become useful to some of you ? If you find any errors or have some other suggestions or feedback, let me know!

@Pierre-Luc Even if this issue is from 2015. Did you give Postgres/Postgis a try? What did you end up with?

Solved by @flydev! Turns out I had the wrong permissions set for the top-level directory. Nothing to do with .htaccess as it turns out! All content of /var/www/html was attached to root's group. So a simple chown -R www-data:www-data /var/www/html did the trick. I just want to say that I'm so thankful for how helpful the ProcessWire dev community is and will make sure to pay it forward!

By default, the "Forgot Password" module is not turned on in v2.1. My thought was that lack of such a function is technically more secure (on any site or CMS). Why? Because having such a function active means your password is only as secure as your email (*though see note at end of this message). So I thought we'd start things out as secure as possible and let people adjust it according to their own need. But I'm rethinking that decision, and may change it to be 'on' by default. If you don't already have that "Forgot Password" module installed, it is relatively easy to reset your password with the API. Lets say that you lost the password for your account named 'admin' and you wanted to reset it. Paste this code into any one of your templates (like /site/templates/home.php in the default profile, for example): <?php $admin = $users->get('admin'); $admin->setOutputFormatting(false); $admin->pass = 'yo12345'; // put in your new password $admin->save(); …or if it's easier for you to copy/paste everything on one line, here's the same thing as above on one line: <?php $users->get("admin")->setOutputFormatting(false)->set('pass', 'yo12345')->save(); Replace "yo12345" with the new password you want and save the template. Then view a page using that template (like the homepage, in our example). The password for that account has now been reset, and now you are ready to login. Don't forgot to now remove that snippet of code from the template! Otherwise your password will get reset every time the page is viewed. Once logged in, here's how to install the Forgot Password capability: 1. Click to the "Modules" tab. 2. Scroll down to the "Process" modules. 3. Click "Install" for the "Forgot Password" module. That's all there is to it. You will now see a "Forgot Password" link on your login page. *ProcessWire's "Forgot Password" function is actually a little more secure than what you see in most other CMSs. Not only do you have to have the confidential link in the email, but the link expires in a matter of minutes, and PW will only accept password changes from the browser session that initiated the request. So an attacker would have to initiate the password change request and have access to your email at the same time, making it a lot harder for a man-in-the-middle snooping on your email.