Leaderboard

With everything running smoothly on the new master version, we wanted to recommend a few additional steps that will help you take advantage of some of the new features. Plus a look at developing for and with ProcessWire. https://processwire.com/blog/posts/what-to-do-after-upgrading-to-the-latest-master/

Alternate Select Multiple It refers to this (https://code.google.com/archive/p/jquery-asmselect/) developed by Ryan outside of PW, but included as an inputfield type for use with Page reference fields.

Hi, I do it this way: in /site/modules/InputfieldCKEditor/styles.js I have: CKEDITOR.stylesSet.add( 'mystyles', [ { name: '1/2 left align', element: 'img', attributes: {'class': 'align_left uk-float-left uk-width-1-2@s site-mar-r-10'} }, { name: '1/2 right align', element: 'img', attributes: {'class': 'align_right uk-float-right uk-width-1-2@s site-mar-l-10'} }, { name: '1/3 left align', element: 'img', attributes: {'class': 'align_left uk-float-left uk-width-1-3 site-mar-r-10'} }, { name: '1/3 right align', element: 'img', attributes: {'class': 'align_right uk-float-right uk-width-1-3 site-mar-l-10'} }, { name: '1/4 left align', element: 'img', attributes: {'class': 'align_left uk-float-left uk-width-1-4 site-mar-r-10'} }, { name: '1/4 right align', element: 'img', attributes: {'class': 'align_right uk-float-right uk-width-1-4 site-mar-l-10'} }, { name: 'center image', element: 'img', attributes: {'class': 'align_center uk-align-center'} }, ]); align_left and similar are for the default I copied over from /wire/modules/Inputfield/InputfieldCKEditor/contents.css uk-float-left and similar are for UIkit 3 This way I do not have to load the whole UIkit 3 css for CKEditor, instead I write my custom rules for the RTE in order the get what will be seen on the frontend. It is some extra work but there are not too many styles needed to be used in the RTE anyway.

Yeah, it is a concern for all external links in the admin, as the referrer will leak the login URL. It's straightforward to fix with a hook... $wire->addHookAfter('AdminTheme::getExtraMarkup', function(HookEvent $event) { $parts = $event->return; $parts['head'] .= '<meta name="referrer" content="no-referrer">'; $event->return = $parts; }); ...but perhaps this should be in the core admin themes.

I thought Google Analytics would log the origin of the event, but I tested it and it seems that it doesn't (unless that information is explicitly passed in the event, and I trust you won't start doing that). So that makes me feel a little better. This isn't true in the instances you mentioned, because Ryan has thoughtfully used the "noreferrer" keyword for the links, presumably because of the privacy concerns we're talking about here. And as a site developer you have control over referrers using the meta referrer tag if need be (in the past I have added this to the admin theme on some sensitive sites). By ecosystem I mean all the software associated with ProcessWire that isn't in the core. Rightly or wrongly, people's perception of a system is influenced by the third-party software associated with it. The WordPress plugin ecosystem is like the wild west, and that's a big part of the reason for WP's poor reputation as a platform for serious development. The PW module ecosystem is as good as we make it. You're absolutely right that the onus is on the user to check what they are installing to their site. But it has been quite nice so far to have a sense of trust that the folks who are contributing modules to the PW community are taking care of privacy and security in the ways that I think everyone expects. I completely get why developers are curious about how many installs, who is using their tools how often, and lots of other things I wouldn't mind knowing myself. I just don't think that curiosity in any way trumps the right of users to control what is being disclosed. Crossing this line to actively sending data to a third party makes me uneasy, and personally I won't be installing any modules that do this.

@bernhard, you are of course free to put whatever you like into your modules. However, having your modules "phone home" like this discloses data that users may not want shared. At the minimum the website URL is disclosed. Not every site that exists on the internet is intended for public access. There are things like staging servers, and probably a whole range of other sensitive sites. My personal opinion is: 1. I think there should be a very clear and prominent statement so that users know that the module will send data to a third party, and what data will be sent. And I'm not sure that only a notice in the module readme would be satisfactory because users might download via the PW admin without seeing the readme. And if you start adding this to existing modules that didn't have it before it could pass by unnoticed when the module is updated. Basically there needs to be informed consent before data is sent, and probably also a privacy policy. 2. I think this crosses a line that shouldn't be crossed, and sets a dangerous precedent that if followed by others could be harmful to the PW project/ecosystem. There is a huge amount of trust placed in third-party modules by users. Modules can potentially access any website data. The very notion that a module phones home erodes trust. We don't want to create a sense of unease where every time a user contemplates installing a module they feel like they ought to comb through the source code to see what the module might be disclosing to a third party. In the bigger picture, I'd like to see PW get a reputation as being a system suitable for large institutional and government clients. Here in New Zealand, SilverStripe is in the enviable position of being seen as the go-to system for government websites. I think PW should be competing in this space. But government and institutional clients won't touch PW with a pole if there is a perception that there are privacy issues with modules in the PW ecosystem. I think the right way to track software popularity is by counting downloads, not phoning home. Sadly GitHub and GitLab don't provide useful tools for this, but that is another discussion.

Pages Export This module is for specifically exporting ProcessWire 2.x sites for later importing into ProcessWire 3.x. Github: Project Page Modules Directory: https://modules.processwire.com/modules/process-pages-export/ Credits: Ryan Cramer Background As I make my modules ProcessWire 3.x-compatible only, I've had the need to re-create/mirror their ProcessWire 2.x test sites in respective ProcessWire 3.x sites. These ProcessWire 3.x sites (one for each module) were already in place and I didn't feel like re-doing them by exporting/importing site profiles. I also like working with JSON rather than other export formats. So, I decided to write a custom pages export/import script for moving the ProcessWire 2.x sites to their respective ProcessWire 3.x counterpart sites. I'd just finished the export side of things when I came across a post in the forums that reminded me that ProcessWire 3.x already boasts a pages export/import feature, although some of it is still in development. Great! I like its API (PagesExportImport.php) and GUI (ProcessPagesExportImport.module) so no need to re-invent the wheel. I still had the small problem of making sure my JSON export would be compatible with the JSON input that the ProcessWire 3.x import expects. No need to re-invent the wheel, again! I ditched my custom script and instead ported the export functionalities of ProcessWire 3.x Pages Export/Import for use in ProcessWire 2.2 - 2.7, specifically to help migrate older sites to ProcessWire 3.x. Compatibility The module and class have been tested and work in ProcessWire 2.2, 2.3, 2.4, 2,5, 2.6 and 2.7. The module is currently tagged as 'in development' until Pages Import feature of ProcessWire 3.x is released as stable. Nonetheless, I have not encountered any issues so far in either the export or the ProcessWire 3.x import. I think Ryan is waiting until he can support more complex field types before tagging the ProcessWire 3.x Pages Export/Import as production-ready. This is not a ProcessWire 3.x module and will never be. It has no such need . Just in case you forget and try to install it in a ProcessWire 3.x site, the module will throw a WireException(). I will also not be porting the ProcessWire 3.x import functionality for use in ProcessWire 2.x. That will defeat the purpose here; to move sites to ProcessWire 3.x and not the other way round. Supported Fields All non-complex fields such as integer, text, textarea, etc Page fields Repeaters File and Image fields I think these cover most needs. Note: not yet tested with Multilingual fields. Technical To ensure exports will be compatible with ProcessWire 3.x Pages Import, where necessary, the module borrows (and amends as needed) methods from ProcessWire 3.x for use in ProcessWire 2.x. For instance, ProcessWire 3.x Pages Export/Import uses the new(-ish) $file functions found in WireFileTools. Rather than copy and include such files, the module only borrowed and amended needed methods. These are listed below. PagesExport.php From /wire/core/Functions.php: wireInstanceOf(), wireClassName() and wireClassParents() From /wire/core/Fieldtype.php: getImportValueOptions() and getDatabaseSchema() From /wire/core/WireFileTools.php: zip(), chmod() and mkdir() From /wire/core/WireHttp.php: sendFile From /wire/modules/Fieldtype/FieldtypeFile.module: exportValue() and exportDescription() From /wire/modules/Fieldtype/FieldtypeImage.module: exportValue() From /wire/modules/Fieldtype/FieldtypePage.module: exportValue() and exportValuePage() From /wire/modules/Fieldtype/FieldtypeRepeater.module: exportValue() From /wire/core/Fieldtype/WireTempDir.php: create(), createName() and getTempDir() All the export methods from the /wire/core/PagesExportImport.php class ProcessPagesExport.module All the export methods from /wire/modules/process/ProcessPagesExportImport/ProcessPagesExportImport.module Newer methods such as $this->wire() will gracefully degrade to the older wire() function, ensuring smooth and uniform operation in ProcessWire 2.2 - 2.7. Use This module and class is for supersusers only and has only 1 aim; to export ProcessWire 2.x sites ready for importing into ProcessWire 3.x sites. You can either install (like any other module) and use the process module (ProcessPagesExport.module) or skip the install and just include and use the class (PagesExport.php) to export your sites. Both the module (Export GUI) and API require that you are logged in as a supersuser before you can use them. The PagesExport class has a gateway method and option not found in the original class (PagesExportImport). The method export() allows access to the three export methods in the original class, i.e. pagesToArray(), exportJSON() and exportZip(). See example usage below. GUI/Process Module On install, the module will create a new admin page Export Pages. Please note that unlike the original code, this page is created directly under /admin/ and not /admin/pages/. Click on Export Pages to start. Nothing much has changed from the original ProcessPagesExportImport. In older ProcessWire versions where InputfieldSelector was not available, the module will instead present you with a text input to specify a valid (for that version of ProcessWire!) selector for finding pages. The other two methods for adding pages (add pages manually or add by parent) are still available. Custom JS ensures older installs without showIf functionality still get the inputfield dependency treatment. API export($items, $options) PageArray $items: The PageArray to export. Array $options: In addition to the options in the original class that you can pass to pagesToArray(), there are two more options here. mode to specify the export type (array or json or zip) and fieldNamesExclude, to specify fields to exclude from the export. Note that the original class option fieldNames still works. It's for specifying the fields to include in the export. // API USAGE // get and include PagesExport class /* @note: you'll need to include the path differently if you are using the class directly without installing the Process module */ $path = $config->paths->ProcessPagesExport . 'PagesExport.php'; require_once($path); // create new instance of the class $siteExport = new PagesExport(); // find items to export /* a. export whole site! (minus admin and children) careful! in some cases, better to export in batches */ //$items = $pages->get('/')->find('has_parent!=2'); // export a batch of pages $items = $pages->find('template=basic-page|computer'); /* you could also use these methods directly #$data = $siteExport->pagesToArray($items); #$data = $siteExport->exportJSON($items); #$data = $siteExport->exportZIP($items); */ $options = array( // @kongondo addition: export to screen as 'array' or 'json' OR export to zip // zip will be saved in /site/assets/backups/PagesExport/ 'mode' => 'array',// array or json or ZIP // export only these field names, when specified 'fieldNames' => array('images', 'files', 'multi_pages'), // @kongondo addition: exclude fields from export. Here we exclude 'body' field 'fieldNamesExclude' => array('body'), ); // get the export $data = $siteExport->export($items, $options); if(is_array($data)) { echo '<pre> EXPORTED SITE USING pagesToArray '; print_r($data); echo '</pre>'; } // JSON export else echo $data; Screenshots See also the links to Ryan's blog posts above. ProcessWire 2.2 ProcessWire 2.4 ProcessWire 2.5 ProcessWire 2.7 Video Demo (Sorry, long and boring) Demo shows various exports from ProcessWire 2.x and their importing into ProcessWire 3.x. Remember the old Skyscrapers site profile? See how a whole Skyscrapers site gets exported from a ProcessWire 2.7.3 site and imported into a ProcessWire 3.x starting from here.

I've opened a GitHub request: https://github.com/processwire/processwire-requests/issues/172

Yep, makes implementing websites a hell of a lot easier. If you don't like it, that's your choice. I don't appreciate your use of the term "gay" as something terrible or wrong. My brother happens to be gay and your opinion may have had value if you hadn't showed your hand and made such an ignorant reference.

The problem with such a system is that it'll always be skewed towards "does not work" simply because when a module does work people are very likely to move on without any feedback while the ones where there's a problem with the module are likely to complain somewhere.

Generally speaking your proposal could be useful, however, I think it is questionable whether it would work or not in practice. Just because a module works for someone, it does not mean it will work in a different environment. Also, ProcessWire's active online community is just not enough for this. The WordPress plugin directory used to have this feature and even they removed it, even though the WP ecosystem has far more users to utilize it, the low number of feedbacks made them realize it was not useful, I guess. Their new "Issues resolved in last two months" feature is more useful, I think. If the maintainer of the plugin/module is willing to support the users, that is a great sign in the first place.

Sounds to me like it should - I don't think module authors should have to worry about this. Are you interested in raising this with Ryan?

you can use grid in grid. since there is no support for sub-grids at the moment, the only way to do a layout is grid within grid. you just have a re-declare the grids that go inside the other grids. here's a quote from the smashing mag grid article What this is saying is that you cannot have a single grid system to deal with the layout but rather you need grids within grids. This creates extra code but still not as much as say something like flexbox and all it's css&divs. Also there is not reason why you can't use css-grid and bootstrap together. SImply ignore the flexbox components. Here is a sample Bootstrap responsive layout using CSS grid . Not a whole lot of code. (make sure to click the html/css tabs to see the src) also, here's a neat project Bootstrap’s grid in CSS Grid https://mdo.github.io/bootstrap-css-grid-layout/

The great thing about PW is that there's never just one solution to a problem but usually half a dozen. Thanks again for sharing the module and the background behind it.

Thank you for pointing this out! Sorry for not checking and making an incorrect assumption. What about module authors who use Markdown links on the config settings page of their module, or in the ReadMe or Documentation (and you have @netcarver's ModuleReleaseNotes installed). I can't seem to find any issue on adding noreferrer etc to Markdown links. Any thoughts on what we should do on this front, if anything?

After you had started to explain the use of the users directly rather than the pages I began thinking in that direction as far as the URL segments go and I just read about the login-disabled role a couple of days ago but didn't think of that use case until you mentioned it. That very well may have swayed me away from building this module. Unfortunately in my case we haven't updated our core yet and we're still back on a .6 version. We're upgrading to the latest with our next feature push so I'm pretty stoked about that. Your method is really solid and I am very sure I'm going to run into places I can use that. Building page references with better selectors opens up a ton of possibilities. Thanks for the explanations and help- I really appreciate it!

Sorry for bumping and old topic... but it seems there is still no language-module features for swapping languages with the default? I had this issue and found that dealing with PW databases was the fastest route for me: To swap language strings repeat this SQL for each multilanguage field: UPDATE field_FIELDNAME s1, field_FIELDNAME s2 SET s1.data = s1.data123, s1.data123 = s2.data WHERE s1.pages_id = s2.pages_id; FIELDNAME is your fieldname in PW and data123 is the column name for the language your are swapping the default for. Just check any multilanguage field table to see the correct column name. Finally to swap page names run this SQL: UPDATE pages s1, pages s2 SET s1.name = s1.name123, s1.name123 = s2.name WHERE s1.id = s2.id AND s1.name123 IS NOT NULL Obviously it is risky to tamper with databases, but this approach saved me lots of work with a big site with reasonably few fields. The language-module should have this sort of swappery built-in.

Sounds like MyISAM is switched off in your database server. You can either switch this back through a storage engine setting in your server configuration (see MySQL docs for details) or you could try switching to InnoDB (if your version already supports FULLTEXT indexes for InnoDB) by adding $config->dbEngine = 'InnoDB'; in site/config.php.

I think this idea has come up a couple of times in other threads, but this is just to rationalise it a little. Currently, the Page Table works rather like a repeater in that it is a way of adding and arranging new content in sections via a field. However, because it works in a more public way (the pages created can be arranged within a publically accessible part of the tree rather than buried under admin), the potential for the field is greater than with repeaters. Primarily, there is the opportunity for the field to have the characteristics of a page field. Take this case: A complex, technical article about using Processwire will be much improved by the use of additional information in the form of asides. Using a page table, it is possible to create the five or six asides needed, sort them into the right order and then insert them into the right places using hanna code. (the hanna code could either call them using their key in the array, or by title or by page id, even - if it were displayed) However, in such an article, it would be also very useful to use an existing aside. For instance, the nice aside "what is php?" might be very useful. But that does mean that it needs to be selected from the existing stock and that is not currently possible with a page table, though it is possible with a page field. What it looks like If the functionality were added to the page table field, this is how I would see it being used in practice: On the creation of the page table field, under the option for selecting a parent, a check box is added "allow selection of existing page" When using the field on a template, where currently you have "Add New" at the bottom of the field you now have a second button "Select" This opens up a lister in a modal window where you can select one or more Asides from the given parent as set in the field. These are then added to the list of asides in the field. Preventing Editing One of the dangers of such a system is that the content of a page called by a page table might be edited out of context. Back to our field! A third checkbox says "prevent editing if used in more than one page." Basically, if our aside is used in more than one page it can no longer be edited from the page table field. The only way it can be edited is by going to the page directly as normal via the page tree, and that might be subject to permission restrictions. There may also be a situation where asides are created in their position within a page tree and the ability to edit them via a page table is completely removed for everyone. Perhaps that is an automatic feature where the aside is created via the page tree and not via a page table field. However, in this case where an aside is not editable, another option may be available: Cloning Another possibility is the idea of New from Old. for instance, I want to use that very good aside about what is PHP but I want to add my own relevant information. In this case I can choose my starter aside and click on "Create New from this aside" in the lister modal. A new aside will be created using the same template and the same content which I can then edit. Limiting Inclusion There are situations in this case, however, where an aside has content that is really limited to that one article and should not be reused. (Legal reasons, perhaps, or just simple editorial context). Back on the field settings there would be another check box "allow limited use" Now, when as Aside is created, on the modal window in the Settings tab it has a checkbox that says "Limit to this article only?" This Aside can now not be selected for use by another article. Other Uses Using this modification as an aside is a very basic example, but there are probably hundreds of others. For instance, product variations or attributes in e-commerce where certain variations need to be available to a range of products. With e-commerce, the various restrictions about editing and limiting inclusion would become very important. So there you go, a lot more power and uses. (Note: this might be the wrong starting point, of course, as it could be argued that this should be a modification of a page field!)

It works perfectly fine now. And yes, @theo it worked with Bootstrap and uikit. Thanks again. I guess I could do the same exercise for styling ordered and unordered lists, block quotes etc.

When you 're lucky and happy with your WP blog for your needs, it's okay. This shouldn't be an offence against gay people. They were always my favorite singers (Little Richard, Rob Halford, Freddie Mercury,.. ). I just have an antipathy for everything wp related.

There has been a bit of a delay, I'm afraid. It might be another 3-4 weeks (with Easter around the corner), sorry. Yes . See this quick video demo. Users will be able to edit media as normal ProcessWire pages. You can upload more media to the page, sort the media, edit image media using the new and any future ProcessWire image functions (focus, crop, sepia, etc), add more fields to the media templates, e.g. text, integer, page fields, etc, (and be able to access these fields using Media Manager API), etc. Basically, you'll be able to do whatever you can do to any ProcessWire page. Yes. I'll tell you more via email.

Ok - I think I've got this half-way solved. I found a similar discussion on this site: https://forum.bubble.is/t/solved-fb-login-domain-problem/3267/36 March 2018 Facebook have changed their app policy to use Strictmode for redirect URI's. So you need to enter https://YOURDOMAIN.COM/login-facebook/ into the 'Valid OAuth Redirect URIs' field. I think you probably also now need be using https to make it work. So I get the correct FB authorisation screen when you visit the /login-facebook page. The remaining problem now is that the redirect after FB authorisation isn't working. I get a 500 error - FB seems to be trying to send me back to https://YOURDOMAIN.COM/login-facebook/ rather than the page I've chosen in the module settings. Any ideas? Edit: The above works fine - I was trying to map the FB profile image field direct to a ProcessWire image field which you can do and this was causing the error.

@ak1001, Forget about home.html. You only need to use home.php and home.twig. All of your PHP stuff goes into home.php and your html stuff goes into home.twig. Example: in home.php <?php namespace ProcessWire; $view->set('mytitle', $page->title); In home.twig <h1>{{ mytitle }}</h1> <div class="body-content">{{ page.body }}</div> This code assumes your Processwire home template has a title and body field.

ah gotcha, thanks for the clarification. I think the simple fallback solution is awesome. here's a list of the latest supported browsers for anyone interested https://caniuse.com/#feat=css-grid

When I said "you naturally can't use "grid in grid" for navigation layout etc.." I was referring to the simple fallback solution of all unsupported browsers falling back to mobile layout. I was not referring to what CSS Grid can or cannot support.

A class using float:left should be enough for both frameworks imho. .float_left { float: left; } Or separate for BS4: https://getbootstrap.com/docs/4.0/utilities/float/

Thanks, @szabesz . Initially I thought it would need some styling for the output, however I was mislead by the appearance of the content inside the editor and thought that I am not doing something properly. Your suggestion seems to be quite easy doable however I should just match the proper classes for bootstrap as I don't use uikit on this project.

Welcome, dubiosa! Well, whatever you've got going on, it's very strange. If I visit the http URL you posted (with a full stop at the end (?)), I get the default Apache page. If I remove the full stop, it redirects to https and I get a certificate error. If I replace the full stop with a slash, I get an actual web page over https. Is the server a VPS? Is it managed or unmanaged? Is it shared hosting? As far as I can see, it's likely to be either a server misconfiguration (Apache etc.) or your .htaccess, or a bit of both. Tell us a bit more and we'll try to help.

I needed clean installs free from some modules and pages in the 2.x sites. I didn't want those carrying over into the new install and then uninstalling/deleting them.

@BitPoet You're a hero. Adding that to config file immediately solved the problem. Many thanks.

With what I was proposing you don't use the created_users_id at all - the author is always identified via the Author field. You can make it a required field, and even have it default to the current user with a hook to Pages::added() if you think that would be useful (I can explain that more if needed). One thing I'm not understanding is why you are creating extra pages for users when a user is a page already. Regarding the module naming, it's best not to use "Process" in the class name because your module doesn't extend the Process class.

Working great, thanks!

Oops - sorry, I committed the tag and release for 4.9.32 but not the actual code Try again now!

Thanks. Did you push the changes to GitHub? It's still showing 4.9.31 which is the version I was seeing the issue with.

Related issue: https://github.com/processwire/processwire-issues/issues/259 Ryan said:

Haven't used it directly in a while, but it is live and running on at least 3 sites and haven't had any troubles with those.

Hi @ak1001, Welcome, I personally like to use home.php as my controller and home.twig as the view. Using the .twig can provide Twig syntax highlighting in some text editors. Make sure you set the .twig extension in the Template Engine Twig module settings > Template File Suffix I prefer to keep those file in the same directory. It's less context switching when your looking for files. Template Engine Twig module settings > Path to templates = templates/ In your case, I would use the following: site/templates/home.twig <!DOCTYPE html> <html lang="en"> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8" /> <title>{{ page.title }}</title> </head> <body> <h1>{{ page.title }}</h1> {{page.body}} <hr> <p>myvar:{{myvar}}</p> </body> </html> site/templates/home.php <?php $view->set("myvar", "my test var"); Hope that helps

Hi @ak1001 Thanks! 1. Do not delete /site/templates/home.php. This file now acts as a "controller" and you will pass variables to your twig templates via $view. 2. You don't need this file, the corresponding twig file would be in /site/templates/views/home.html. Note that this path and the file extension depend on your module configuration. 3. Yes, this is actually your twig template. The below code belongs to /site/templates/home.php <?php $view->set("myvar", "my test var"); Think of this file as layer between ProcessWire and your twig template. So instead of echo stuff there, pass it to the twig template which takes care of the rendering. Hope that helps! Cheers

Just cross-referencing: I've ported the export functionality into a module and class for exporting ProcessWire 2.x sites in a format compatible with importing into ProcessWire 3.x using PagesExport/Import.

Hi Robin and szabesz, I was actually expecting that something like this would come up. I'm happy about your feedback I'm not sure about that. I can actually only see the number of Events that occured. Nothing else. No visitor information at all. The request is sent with an anonymous client ID, so there is really no data connected to anybody. No cookies are set. Nothing. Basically it's just a counter. I partially agree. I would love to have some kind of pre-screen before a module is installed. Maybe I'm wrong, but I think at the moment we only have the "summary" statement that is shown before installation? It does not support HTML though. I think it would nice to have the possibility to place some statements before installation and also before updating a module that the user must accept. This could be nice in several situations. The user could check a box to agree to data submission, the user could be informed about breaking changes that may be installed with an update, we could show a donation button etc. I don't agree with you here. Actually I do think it is quite the opposite. Trust in ProcessWire is for sure a good thing. In its security, in its features, in its future. But I do not think, that (blind) trust in 3rd party modules is good. As you said, any module author can basically do anything within the instance where it is installed. This may not be obvious especially to unexperienced users. So I think actions/discussions like this support the ecosystem and do not harm. But again, I agree that a "feature" like the install/uninstall tracking should be stated more prominent. BTW: I have 26 likes and 0 installs for RockForms so far, so nothing happened until now

https://modules.processwire.com/modules/process-page-list-multiple-sorting/

This profile can be used as a simple business card or blog. The profile does not use any framework css structure, only styles based on CSS GRID and FLEX. To minimize page loading, I added lazy load for images ( Tupola Lazy Load ). With include functions like: MarkupRegions FunctionsAPI CAN DOWNLOAD FROM THIS LINK: https://github.com/rafaoski/site-grayscale-pw https://github.com/rafaoski/site-min-grayscale-pw Screenshot:

That's the whole point of this thread I don't think there necessarily needs to be a plugin for outputting legal stuff. Considering the basic contact form, there should be a privacy policy page somewhere that describes what happens to the data, and we have some guidance for writing that up here: https://ec.europa.eu/info/law/law-topic/data-protection/reform/rules-business-and-organisations/principles-gdpr/what-information-must-be-given-individuals-whose-data-collected_en. But that's our clients' responsibility, not ours. Of course, this will vary greatly from site to site. It's not the same as the cookie consent message. The company has to describe exactly what they will to do with the information and how long they'll keep it. We should also add the "I accept the terms of this site's privacy policy" checkbox on any forms that ask for private data, and the words "privacy policy" linking to the page where it's all described. There shouldn't be a problem stating that the form submits the data to our email for appropriate response, that no data is stored permanently on our servers, and should you require the right to be forgotten, please submit your request to the email xxx. This and all the rest that's stated in the link above. But so far this isn't more than a disclaimer and examples will start popping up everywhere on the web in no time. What worries me more is when the data stays in our PW. If the server is hacked and info is leaked, there can be an investigation that will evaluate how careful we were with the way we've built the site. They mention database encryption, security by design, and keeping the data for the least possible time. For me this is where one or two new modules may come in handy. Not keeping the CMS updated can theoretically burn someone. Example: We have a jobs form that stores a user's CV. In a year that CV will be outdated and would serve no use. A module that automatically manages that content's (page) date of expiration and deletion could be useful. Another example: A site that has a private area that a user can register to gain access to. After X months without logging in, the data is deleted. Maybe even notify the person that it will happen unless they log in before day X. Doesn't sound too complex to do. Now, security by design... I'm clueless. I saw a mention of stuff like scattering personal data in more than one DB and only by comparing a blind ID you can tie the info together. I can see the coolness, but can't see it as something viable for smallish sites.

Thanks for this module! I had to change a few things to get this to work with PW 3.0.84 a) add PW namespace b) change page id from 2 to 3 (2 = admin root, but 3 = page, which is the actual default landing page after login) if ($this->page->id === 3) { (and then the two lines from @Macrura above) c) // $t = new TemplateFile($this->config->paths->siteModules . __CLASS__ . "/dashboard.php"); // this creates a URL like site/modules\ProcessWire/ProcessDashboard/ $t = new TemplateFile($this->config->paths->siteModules . "ProcessDashboard/dashboard.php"); Perhaps you could re-check, and publish a new version that officially supports PW 3 ?

I hope you have been able to get this working. I will detail how I'm use Google Tag Manager for an upcoming project, just in case you still are having problems. Background I'm working on a new website where we are using an Ecommerce Widget. We normally use Piwik for basic analytics, however this Online Store solution uses Google Analytics to track things (shopping cart, etc). This is where Google Tag Manager becomes a great solution. We ended up using both Piwik and Google Analytics. In Google Tag Manager you create the needed Tags with Firing Triggers. In this situation, we created one for Google Analytics (using Universal Analytics tag) and one for Piwik (using a Custom HTML Tag). The Custom Tag is simple, you enter the Piwik code and save. Now that these tags are created, you take the Google Tag Manager code and add it to your website. Just follow the instructions, as listed. My website configuration has a _head.inc and _main.inc. You can see (above in the 2 files) where the Google Tag Manager code is put. It turns out to be a very clean solution when you need to track many things or have more than one analytical tool that needs to track things. One of the good things about using Google Tag Manager is that you can verify that the 2 Tags are firing, as you need them to. Additionally, you can create more Tags to track a multitude of things on your website. Google provides free training courses on Google Tag Manager, if you are interested: https://analytics.google.com/analytics/academy/ I hope this helps someone out.

http://cssgridgarden.com

Ok, apparently slowest response to an email ever (3 years), but Microsoft has confirmed they are working on getting their Grid implementation updated in Edge.

in another thread I had posted some useful links to this too: https://processwire.com/talk/topic/15886-different-styles-for-results-of-an-array-page-grid/#comment-141785

It's about time this was pulled together as a configurable module. So here it is on github and in the module DB. You can configure a set of roles and a target redirect page under the module config. I've done very limited testing here - hence it being marked as alpha in the module DB - so please let me know if it works for you. A word of thanks to both Wanze and kongondo are in order as they pulled most of the material together that I used for this!