Leaderboard

This week we’re proud to announce the newest ProcessWire master version 3.0.164. Relative to the previous master version (3.0.148) this version adds a ton of new and useful features and fixes more than 85 issues, with more than 225 commits over a period of 7 months. There were also a lot of technical changes in the core, including some pretty significant refactoring of several classes to further optimize and improve upon our already solid core, making it that much better. I’m confident this master version is one of our best and if you are running an older version I’d encourage you to upgrade when convenient to do so—I think you will really like what this version brings! Read all about what’s new in the latest blog post: https://processwire.com/blog/posts/pw-3.0.164/

Super! Love reading those long feature lists for the new master versions! I usually read every week's posts too. But by the time a new master is out, I forget a half of new cool things that were added. So they come as new and bring the joy once again, like finding a banknote in a pocket of pants you didn't wear for while ? Great release for ProcessWire once again!

u.can do on anyee page template like .this if($config->ajax){ // u do.ajax $data=['status'=>'ok', 'massage'=>'hi whirld']; header('content-type: application/json'); echo json_encode($data); exit; }else{ // u.do html }

Hi @Youbility, yes I did. It's working on production at https://www.brightline.org/ Here's a slightly different version of that one: https://gist.github.com/sjardim/d74fae71b5bfe6a44ab88efc9aaa5279 Hope that helps!

Quick idea, not well thought through: You could also create a custom DB table on which the client can work on and you write a script that pulls data from that table and populates pages via API (or synchronizes both).

you are sending 'search' which is null, you have to send q

Hello gentlemen and thank you for your fine module, Joshua! Is there a way to preserve the changes to the HTML/CSS of the banner after updates? Maybe there is a generic processwirish way to override module markup? Right now I added a method to the module that allows me to replace the module's markup by placing the modified files in /site/templates/MODULE_DIR/: protected function getFile($file, $is_url = false) { // we're putting module overrides in /site/templates/modules $override_dir = 'modules/' . basename(dirname(__FILE__)) .'/'; $override_path = $this->wire('config')->paths->templates . $override_dir . $file; // we're overriding files in the module's folder $default_path = $this->wire('config')->paths->$this . $file; if (is_readable($override_path)) { return $is_url ? $this->wire('config')->urls->templates . $override_dir . $file : $override_path; } return $is_url ? $this->wire('config')->urls->$this . $file : $default_path; } and using it like this: $jsFilePath = $this->getFile('js/PrivacyWire.js', true); and $output = wireRenderFile($this->getFile('PrivacyWireBanner.php'), [ 'module' => $this ]); This way I only have to add the above code into the module after the update, while keeping my changes in /site/templates/PrivacyWire/, to preserve the look of the banner, from the default to a Bulma version

Hello friends! I have another module for you, which will make your daily work as a Processwire developer easier. Introducing: AppApi This module helps you to create api-endpoints, to which an app or an external service can connect to. Features Simple routing definition Authentication - Three different authentication-mechanisms are ready to use. Access-management via UI Multiple different applications with unique access-rights and authentication-mechanisms can be defined The documentation has become quite extensive, so have a look at the Github repository for details: Installation Defining Applications Api-Keys PHP-Session (Recommended for on-site usage) Single JWT (Recommended for external server-calls) Double JWT (Recommended for apps) Creating Endpoints Output Formatting Error Handling Example: Listing Users Example: Universal Twack Api Routes Page Handlers File Handlers A special thanks goes to Thomas Aull , whose module RestApi was the starting point to this project. This module is not meant to replace this module because it does a great job. But if you want to connect and manage multiple apps or need other authentication methods, this module might help you. I am already very curious about your feedback and would be glad if the module helps you a little bit.

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

So I ran into a strange error this morning when trying to publish a page. I went to publish a new page under "clients", but I get an error that says "Cannot be published until errors are corrected". I thought perhaps I had missed a required field so I checked, but none of the fields are marked as required. I then checked to see if I could just add a basic page (default basic-page.php template) under the homepage, but I get the exact same error when trying to publish. When looking at the template, I don't see any error messages being displayed above any fields. The odd thing I found though was if I got to "settings" and uncheck "unpublished", I can then publish the page without errors. I did upgrade earlier today to the newest version to hopefully fix an issue I had yesterday (which it did). Has anyone run into this error before? **EDIT** Well, after a lot of staring and pulling my hair out, I found the issues. I had installed multi-language support sometime ago (and due to the project changing, had to remove it). Apparently in my haste, I did not remove all the dependencies so it was still trying to check for the multi-language title (I am guessing) even though it actually wasnt on the page. I went through the database and removed it and can now save/publish pages without issues.

This is great stuff! Got a question. Who is maintaining the PW Demo site? It would be nice to have these new features incorporated into the skyscrapers. Also, the demo is still on version *.101 and not using ssl.

New release for latest stable PW version 3.0.164

I just published version 4.0.0 of this module, a large update that makes it possible to completely customize the markup created for detected page titles. For example, let's say you have a glossary and want glossary terms that appear anywhere on your site to display a popover with the term's definition. This update allows you to do that! Previously, the module always created an <a> tag with an href attribute, and always checked if the page was viewable before doing anything. This update comes with configuration options to change the HTML tag, disable the automatic href attribute and disable the visibility check. This allows you to use the module for a wider range of use-cases. If you need even more control, the methods the module uses to create markup are now hookable, so you can customize the output format even further! Here are some additional links to help you get started: There's a new step-by-step guide for a setup with glossary terms with inline definitions. Both new hooks are documented with usage examples in the hooks documentation, learn how to customize the markup generated for titles and how to add attributes to the generated link / HTML tag dynamically. All the new options are available for manual usage, find the list of options here. Check out the CHANGELOG for version 4.0.0

Ah, but of course! How could I forget about hooks! Thank you, @horst! I realize now that I could probably keep all my overrides in a single place, depending on the presence of the hooks, of course. @joshua, please make the render() function hookable. Sometimes I wish ProcessWire could be more restrictive, my /site/ folder is a frankensteinish patchwork of code snippets, because I used whatever the search cat dragged in first ?

The "processwirish way", IMO, is called hooking. Therefore the originals modules author need to add three underscores to a method name: "___myMethodName()". This method than can be hooked and its output changed. Joshua, if you would add three underscores to the public render() method, I think its all done. @The G then should be able to hook in (before or after) and changes the output the way he likes to. In this case it seems like a small autoloaded custom module should fit: class MyCustomModule extends WireData implements Module { public static function getModuleInfo() { return [ 'title' => "MyCustomModule", 'summary' => "Customizes the output of PrivacyWire module", 'version' => "0.0.1", 'autoload' => true, 'singular' => true, 'requires' => [ "PrivacyWire", "PHP>=7.2", "ProcessWire>=3.0.0" ], 'icon' => 'cookie' ]; } public function ready() { $this->addHookBefore('PrivacyWire::render', $this, 'customRender'); } public function customRender(HookEvent $event) { // do your changes or complete override here // ... $myCustomOutput = $this->myHelperMethod(); $event->return = $myCustomOutput; } protected function myHelperMethod() { return 'something'; } } Not tested and I'm currently not perfect sure if its better to hook in before or after. (I think before, but you need to test it) TL;DR Other scenarios may be that the original modules author adds special hooking methods where an output finally is passed through. This function then optionally can be used for changes. // in PrivacyWire public function render(HookEvent $event) { ... $output = 'something'; $output = $this->finalizeOutput($output, $event); $event->return = $output; } public function ___finalizeOutput($output, $origEvent) { return str_replace("</body>", "{$output}</body>", $origEvent->return); } // in another module or site/ready.php, addHookAfter PrivacyWire::finalizeOutput

Hello @Greg Lumley, From what I understand (and I am not an expert as are the others here) there are two ways to process an ajax request: 1, create a page with corresponding template and php file (preferred/common method), or 2, create a php file outside of the site folder. Which method you choose has different requirements. The common method is to create a php file (in templates folder) named ajax_contact.php to handle the ajax request, assign that file to a template named ajax_contact, and create a page for that template named ajax_contact. Your ajax url them becomes the name of that page, ie, /ajax_contact/. Note that the page should be published or PW will ignore it during your request. Method two I think requires that you initially load PW (index.php) in your ajax_contact.php file since you are outside the document root referenced during the processwire installation. In this case, your ajax url would be the actual php file name; ajax_contact.php. I don't know which method is preferred, but I use the first method simply because that is the way processwire handles normal page request. I think you have both methods implemented in your script at the same time when it should be one or the other. I hope this helps. I'm sure someone more knowledgeable will provide you with a better answer, and hopefully correct me as well.

Another thing which would make usage of this module easier for users of the RestApi module would be to have an option to not have to use ApiKeys to access the API

Thank you for all your input! I've been quite busy the last weeks, sorry for my delay in answering your requests. During the last couple of days I refactored some code and implemented an suggested feature by @horst (to call a custom js function after saving the consent). As this version might not be as stable as the current version, you'll find it currently in a separate branch. The following updates are also only in this branch at the moment. I agree on that and just added this category to PrivacyWire (in the V2-Branch). In the new branch I switched to save the consent information in LocalStorage instead of Cookies. Now the lifetime in all browsers should be 365 days. About the details about cookies / categories: I also agree that there should be an option to display more details. The idea of a Textformatter for this purpose sounds good. Haven't got the time though to implement it right away. I'm open for PullRequests with improvements, if you want ? The styling is currently applied directly within the js file. To add the option to disable loading the stylesheet, I could exclude this from the js file and add an option to the module config.

@MoritzLost Thanks for the reply! Yeah that did the job! It's weird really could have sworn it was without the start=0 previously and it didn't work. Will keep a close eye on this because I've been getting some weird behaviors. Thanks!

Thanks @bernhard for the improvements. I will implement them shortly. Good suggestions!

I really like to use Insomnia testing api-calls. It's a stand-alone tool for Mac, Windows and Linux. And the free plan suits perfectly for all my needs - the paid functions are primary focuses on collaboration features for teams.

This one is actually important because it is misleading. @dotnetic could you please change that to "Aktion wird beim Speichern angewendet"?

What do you guys think of changing that to Vertikal spiegeln Horizontal spiegeln Beides spiegeln 90° drehen (rechts) 90° drehen (links) 180° drehen S&W Sepia Actually I don't understand why we have the options for 270° rotation at all? -270 = +90, so why does it show up??

One more addition to this: The API is, in fact, one of the biggest advantages of ProcessWire. While the preferred term is "content management framework", one may as well think of it as an ORM of sorts. ProcessWire was never designed for direct database access, and that's the whole point: it's meant to (mostly) abstract the database layer away so that both developers and content editors can (as much as possible) avoid the complexities and inherent risks of dealing with SQL queries. I must say that I don't agree at all with your point about ProcessWire's advantages taking a backseat once the website is finished. I get where you're coming with this, but I'd assume that we can both still agree that it's extremely rare for a client to actually prefer SQL over a GUI — let alone them being competent and meticulous enough to produce data that fulfils all expectations we as developers might have. Obviously we come from different backgrounds and thus have different expectations. If I would've suggested to any of the clients I've ever worked with a platform that requires them to use SQL, that would've been a disaster ?

@fruid I don't really understand your use-case. You say your client is going to use SQL to update the database, does that mean they are going to write raw SQL queries in front of a terminal? That seems like a really inefficient way to go about content creation, especially since you have to make sure your data fits within the constraints defined in the template and field settings. Despite that, you can still do that, you just have to add a couple of JOINs and be careful with your WHERE clauses. Each field table comes with a foreign key corresponding to the page ID. If your client is really some kind of SQL wizard who prefers the power of raw SQL for data migration over the limited interfaces puny mortals have to use, what's stopping them? Or do you mean "the client is going to log into phpMyAdmin / Adminer / MySQL Workbench / ... and insert data through that interface"? In that case, you're not really using SQL anyway, you're just using an interface that's closer to the database, that *may* be slightly more efficient to use for batch creation / updates if you really know what you're doing. If that's what your client wants – well, that's an interface you can build for them! Something like a batch update module that lists pages and allows you to edit them inline. In fact, such a module exists already: Lister Pro comes with inline editing for multiple fields at once. This gives you a convenient interface to update many pages at once and still stay within one backend and have all the input / constraint validation apply to your edits. Best of both worlds ? By the way, if you've ever tried to manually find something in a Drupal 8 database, you will like ProcessWire's database structure MUCH more ...

That was the way they did it in other CMSs I used in former times - before I luckily found ProcessWire! It was like a breeze of fresh air after a long stuffy time... The dilemma you are in is to incline to habits you are familiar with. Try to understand the way PW works, and you will soon be convinced. (And as a next step: Try to convince the client...) All the best!

Hi @fruid, I understand your concerns. The db structure can look quite complex, especially if you are used to working with db tables and SQL select ... from ... etc; Teppo explained the reason for this structure. The great thing about this structure is that you get an abstraction layer that makes all the PW awesomeness possible. It transforms all the custom fields and data in the database into PHP page objects that can be used for easy and effortless markup generation. I'm talking about the great pw api ? echo $page->title; echo $page->headline; echo $page->image->size(200,200)->url; Display all that in multiple languages? Same code ? I think that's really genius! Are there downsides of this approach? Yes, as always. For example it is not easy for PW to do a "SELECT * FROM table_xy" to get a list of thousands of rows of data. That's because the magic of transforming the complex db structure into an easy to understand and use API has some costs. It needs to load all rows of data into memory and therefore this get's slow when working with lots of data. PW handles this by applying pagination wherever possible, so that it only loads chunks of data and stays fast. But still there might be situations where you simply need a good old "SELECT * FROM ..." and "foreach($pages as $page) $rows[] = [$page->title, $page->headline, ...]" is no option. That was quite a long introduction and explanation why I built RockFinder3 ? So at least the PULL part of your request is already doable ? What about the PUSH part (meaning updating data in the DB, doing "UPDATE ... , INSERT INTO ...")? First, you can still use native SQL commands on PW, it's quite easy: $result = $this->database->query("SELECT * FROM pages LIMIT 5"); var_dump($result->fetchAll(\PDO::FETCH_OBJ)); The problem is, that updating data can get quite complex because you need to update several tables, several fields, several languages... That's why such operations should really be done via API. That's of course a totally different approach if you are used to working with SQL commands, but it is the best option in 99,5% of the cases. There's a topic about that where I showed my findings: For the remaining 0,5%: You see, it can be quite easy. Is it a good idea? 99,5% no, because you don't get all the security features of PW that ensure that data is sanitized before storage etc. And you don't get the power of hooks. Updating pages via API will still trigger saveReady() and saved() hooks while direct SQL updates will not. Hope that helps ?

Each field may belong to more than one template, and each template has a different set of fields. Current structure works well with that concept, makes it possible to connect (or disconnect) fields with/from templates with ease, makes it unlikely for a single table to grow to giant proportions (thus making all queries against it slower), and also allows fetching/searching/saving the exact data that ProcessWire needs to fulfil a specific request. So yes — there are advantages to current structure. It's also a very fundamental part of ProcessWire, so changing it is not possible without major changes to the core ? It has been. If you'd like to read a bit more on it, I'd suggest doing a google search for something like "processwire database structure". You'll find a lot of existing content on this topic ? Your point of view is not unheard of for newcomers but trust me, there are valid reasons why the database architecture is what it is. Much of it is due to the fact that ProcessWire — unlike some competing platforms, I might add — was designed with custom data structures (custom fields) in mind from the ground-up. Some other systems (WordPress, for one) have a much simpler database structure, but that's because they weren't originally intended for the same kind of use as ProcessWire. In the context of ProcessWire this would be a bad idea: First of all the Admin is a ready-to-use tool for managing content, and I highly doubt that anyone will really have easier time managing the content with raw SQL. It can be fun and/or if you've had to do that a lot in the past you may be used to it, but still: ask them to give the Admin a try and I bet that this idea will go away in no time. If you manually update the rows in the database, most of what ProcessWire's fields do will be completely skipped. This includes validation, filtering, and sanitization; things that are there to help you build sites with valid and well formed data. Without these features you will run into trouble eventually, it's just a matter of time. ProcessWire does internal cleanups and such using hooks, and those will not get triggered if you update the data manually in the database. This means that you'll likely be left with broken data, missing pieces here and there, and so on. Some fields (take Repeaters for an example) will also be very difficult to update manually via database. Finally, while we're on the topic of hooks: they are a major feature in ProcessWire, used by both core and third party (module) code — and, once you get used to it, probably your own code as well — and again if you don't go through the "official channels" (API or Admin) you'll loose this benefit altogether.

Well this was a great one to do. The Beyond Banglatown site is the public facing site for a report conducted by researchers at the London School of Economics and the University of Manchester, and published by the Runnymede Trust. The aim is to present the findingsof the report in a publically accessible way that can be used by teachers and students and well as the general public. It covers the changing face of the neighbourhood around Brick Lane in East London. https://beyondbanglatown.org.uk/ Technically this was the first project we used ProcessWire on - although what with one thing and another it's taken 18 months to get the site launched, so we've managed to get a few others out before this one. It was certainly jumping in at the deep end though and we learned a lot. The site involves a fair amount of ajax driven content and we had to get to grips with importing the data used for the maps and graphs as well as sorting out how best to manage templates and assets. As far as modules that we used there's nothing too exciting, but certainly we made good use of TracyDebugger as we fumbled about. A special mention also needs to go to the PW documentation, the API references and of course this forum which provided a great deal of help. Anyway - we're really pleased with the site and it's already been getting very good coverage. Hopefully the first of many PW sites. s.

Hey @Macrura - looks like you've upgraded from a very old version. Please just save the module settings page and it will be gone.

This is generated on the fly when a result is rendered. Behind the scenes Renderer::renderResultDesc() and Renderer::renderResultsJson() both get field values using Renderer::getResultValue(), which in turn calls Renderer::getResultAutoDesc _auto_desc "pseudo field" (as in: not a real field) is requested. There's currently no public API for accessing this directly, but if you've got a use case that can be solved by adding one, I wouldn't be against it. Though in that case I'd like to know a bit more about the context ? Sorry! Accidentally introduced a dependency for ProcessWire 3.0.160 in the Config class. This is now fixed: latest module version (0.25.1) provides proper fallbacks for core versions prior to that.

Hey, great module. Good work! I think it would be nice for the user to implement explaining textfields for each cookie category and not only titles, because people might not know what they are accepting.

Hi Joshua, the module works fine. I would like to use the Textformatter to generate a button. [[privacywire-choose-cookies]] But I don't get how to implement the shortcode.. ? In a Textfield? That doesnt work. Sorry for this noob-question. Thank you! Ok..now I got it!

Joshua, first, thank you for all your work. It looks like that we need a good solution for compliance also in Germany now (after the BGH ruling) and I am glad, that your plugin is close to what we need already. After comparing existing tools and reading more about the requirements I thought of the following strategy to add to the compliance: (My source of information: https://www.activemind.de/magazin/cookie-consent-banner/) 1. we probably need another category. "Functional" for settings that are not "essential", like settings, example use: remember that a certain popup was closed. Comes after "essential" (or better the order of the selected categories from the backend is remembered) 2. Details collection. This info should to be collected: name of cookie, issuer, purpose, functions, privacy links. Example: name: '_ga, _gid', issuer: 'Google Universal Analytics', purpose: 'Collect statistical data for service improvement.', functions: 'Number of pageviews, link clicked etc. ', privacyLink: 'https://policies.google.com/privacy?hl=en' Some vendors like cookiebot overload their popup with information. I think this confuses more than it helps. Setting content should not be rocket science to average users. Instead, I thought of having the details on a special (manually filled?) compliance page, sorted into category blocks. That means that means another optional link (next to imprint and privacy) in the settings could be useful. If this strategy makes sense, then it would be fancy if your textformatter could handle the consent from there: [[privacywire-category-settings category="statistics" ]] and display a toggle for on/off for that category. (But this has no priority) 3. Styles / Popup responsive? Right now the popup is not working correctly on mobile phones. It is not scrollable, and with lots of description and selections it easily has more content than fitting on a small screen. We need another wrapper div tag for the element and another wrapper div tag with a class for the links - and add classes to all elements like the lists - so this is easier to style. Also the body text is maybe not needed right away so there should be an option in the backend to display that only on the page which opens, when "select" is choosen? Maybe add a field in the backend to drop all the CSS so it is easy to maintain at one place? 4. External media. Can you explain what happens in that case? How can your code handle iframes, e.g. YouTube, Vimeo and maps? What happens if one of the existing video plugins are used? 5. Cookie lifetime of this plugin max 7 days? In Safari and Firefox JavaScript cookies have a short lifetime, even if the cookie is set with a very long expiration date. A user has to opt-in again every 7 days. Is this correct? and is an alternative? Source: https://alightanalytics.com/alight-insights/safari-first-party-cookies/ --- Before a line of code is written, I would ask everyone for feedback and ideas for this concept... --- By the way: here is a nice layout example with a consent banner with kind of your feature set - they also follow the route to move all complicated cookie details to a separate cookie consent page: https://www.osano.com/cookieconsent/download/

I'm sorry but this is going outside this forum scope, I suggest you study php, these are basic issues.