Leaderboard

Imho the big benefit of modules is installability. So anything reusable or more generic can be a fit for a module. Other than that I don't see much reason to use modules over just classes. Personally I'm of the opinion to keep modules just for the code needed to interface with processwire anyways. Business logic, which is not processwire specific can just as well be in a plain class the module brings with it.

Just came across this thread - for those who were wondering, we switched from ServerPilot to RunCloud + Linode for many PW projects and find it to be a great setup. Their support is great too, they’re in the Far East but always respond very quickly, not that we’ve had many issues. Very favourable pricing too compared to ServerPilot and way more features.

For example, I have a Galleries repeater field (or repeater matrix), named galleries and I want to render galleries within a text field. Each repeater has an images and title field. Let's say you fill one repeater item's title field with "Party gallery". Then, I have a hannah code that has a title attribute available and is used in the text fields like the following: [[gallery title="Party gallery"]] Then, in the hannah code's code (?), I do a selection like this one: $gallery = $pages->get("galleries.title=$title"); That way the $gallery variable will hold the gallery referenced by the title, which can be picked from setting the hannah code attribute making it very flexible cause then you can have all sort of settings and just pick whatever gallery you want. The pain point for the users is usually going to find out galleries titles, but most users have found it to be quite flexible. Maybe a custom CKEditor toolbar dropdown would complement this approach even better, filling it with gallery names available. Check this awesome module from @Robin S .

I wasn't talking about the frontend lazy loading, but the fact that in processwire fields are lazy-loaded from the db by default. So you load a page (+ autoloaded fields; 1 query) then you access the first field in the page (1 query), then you access another field of the page (1 query) and so on. That's why autoloading fields can be so useful, as it can quite quickly drop the query count and therefore improve performance. Using fieldtype matrix makes it sounds like it's still just one page, but with 30 blocks it's more in line of loading 31 pages, the parent page and all the blocks are also pages. Now if each page lazy loads their fields you're basically in a n+1 query situation.

Hi all, I have posted this in the VIP support forum of Padloper as well. Some of you do not have access to that board so posting here as well. Hopefully it doesn't count as spamming?! In June 2018, Antti announced that he was looking for a new product owner for Padloper. Sometime after, I had a fruitful discussion with him about my vision for the project if I was to take over. We agreed that commitment, motivation and a concrete plan were all important ingredients for the continued success of Padloper. I would like to officially announce that I am now the product owner and lead developer of Padloper. For those who may not know, I am the author and maintainer of several ProcessWire modules, both free and commercial. I am also a moderator in the ProcessWire forums. I would like to share with you a number of things regarding what’s going to happen next. This will be a long read. First, I would like to thank Antti for developing a great product. A lot of man-hours, dedication, passion and love has gone into making Padloper what it is today. Secondly, I would like to thank all users of Padloper. A great product is nothing without active users utilising it, putting it to the test, reporting bugs (even offering possible solutions) and proposing new features. So, thank you for helping make Padloper great! Support Thousands of hours have gone into developing Padloper. Although the code is well-written and easy to follow, Padloper is a big application with many moving parts. As such, it will take some time before I can fully grasp its inner workings. To make this transition as smooth as possible, Antti will help me with support for Padloper for some time. Currently, Padloper has a dedicated support forum. This is an arrangement between Ryan and Antti. The support forum works great as it allows the opening of multiple support threads to cover different issues. I have yet to speak to Ryan whether this arrangement can continue. However, given that I have other pro modules that I support in the open forums, it is unlikely that I will be requesting Ryan to let Padloper’s dedicated forum carry forth. A dedicated forum for one of my pro modules and open forums for my other pro modules will lead to confusion and questions from users of those other modules. Hence, Padloper support in the forums will move to the open forums. The disadvantage here is obviously the fact that support will be offered in one single (and maybe massive) support thread. To get around a ‘single thread support forum’, I am thinking of developing a simple online support queue system for all my modules. Meanwhile, support will continue in a new single thread and via email. Roadmap This list is neither exhaustive nor cast in stone. Its aim is to give an overview of my plans for Padloper. · Padloper 2 – a new major release · New backend for Padloper · Optional pro frontend module for Padloper · Documentation · New payment modules Let’s talk a bit about this list. Padloper 2 Release Padloper 2 will be a major release that incorporates a new, central backend shop for Padloper. This will be a new process module that pulls from the existing parts of Padloper (data models, etc) into one interface (more on this below). This version will also be extensible in the frontend, allowing for the plugging in of a new, optional, commercial frontend shop (full featured shop profile). Padloper 2 will not support the current ‘any page can be a product’ paradigm. Technically, products will still be pages. However, all products will utilise the same Padloper template. These will be invisible to the shop users themselves (e.g., hidden in admin tree). Only superusers will have full control of the Padloper system stuff. Support The current Padloper will continue to be supported until the new Padloper 2 is released. New features will be included in Padloper 2 only. Once Padloper 2 is released, legacy Padloper will only receive security fixes. All other support will cease. Upgrade There will be no upgrade path from the current Padloper to Padloper 2. Although their underlying architecture is the same, making sure that everything works in different setups and environments will be time consuming. However, for those who really need to migrate, if time allows and for an agreed fee, I could develop a custom script for the migration. Backend A new backend interface will be the major visual difference between the existing Padloper and Padloper 2. It goes beyond visual differences though. The new backend will be the single gateway for managing all shop-related features, both current and new ones. The backend will unify and include: · Easily add shop products. · Ability to add as little or as many custom fields to products as required (title, SKU, price, discount field, image/photo, description, categories, tags, etc). · Discounts manager (including auto start/expire discount codes). · Customers manager. · Invoices manager. · Taxes management. · Payment gateways manager. · Improved digital products management. · Stock management. · Manual order creation. · Graphical sales report. · Customer support. · Access-controlled shop editors/staff. · Dashboard for shop metrics. · Shop settings. · Product variations. · Import/export products as CSV or JSON. · Products search/filter. · Etc. Users will be able to turn off backend features that they do not need. This will enable a more streamlined experience for users. I plan to release Padloper 2 within 4 - 6 months, hopefully sooner. This is a major undertaking, hence the timescale. Please note that the first release of Padloper 2 will not include all of the above planned features. The idea is to build incrementally, adding new features in minor updates, focusing on stability, usability and security. Frontend Past requests have included the development of a full featured frontend shop. This is planned for Padloper 2. However, this will be an optional pro module priced separately from Padloper itself. The ability to build own frontend shops using Padloper API will still continue. For those who want a plug-n-play solution, this frontend shop will come in handy. The frontend shop profile will feature an ajax-powered shopping cart and a customisable ready-to-go theme. Pricing Model There are no plans to change the current prices of the 3 Padloper licences (Single, Developer and Agency). However, in order to continue to provide Padloper as a stable product with great features, it is also important that it remains a competitive and financially sustainable project. In order for this to happen and to also bring Padloper in line with my existing pro modules, the pricing model itself has to change. Starting from Padloper 2, the pricing model will shift to an ‘annual subscription’ model rather than the current ‘lifetime licence model’. I am fully aware that there are different opinions for and against annual subscriptions. However, I believe that this model is the most equitable approach that suits both the developer and the clients. The annual subscription will allow users (licence holders) to get 12 months of free VIP support for Padloper as well as future updates available within that time period. After the 12 months, users will be able to renew (online) their subscription at a discounted cost (worked as a fraction of the full purchase price) for a further 12 months (perpetually). Users will be able to continue to use Padloper for life even if they don’t renew their subscriptions. Upgrading current licences to Padloper 2 will be a paid upgrade. Current users of Padloper will get an attractive discount. This will be a time-limited offer (maybe a couple of months) that will start with the release of Padloper 2. New customers will pay the full price for Padloper 2. I hope the planned features are reason enough for you to consider upgrading to Padloper 2. Payment Modules I will be taking over as the maintainer and lead developer of the existing payment gateways (Payment base class, PayPal and Stripe). New payment modules are also planned. Payment modules will continue to be free. However, only ProcessWire 3+ support will be provided going forward. Padloper Domain and Future Downloads I have also taken charge of the Padloper domain. Within the next 12 months, purchase and download of Padloper will shift to processwireshop.pw. Please note that this is not the official shop for ProcessWire! It just bears a name that reflects its product offerings ?. Eventually, traffic to padloper.pw will redirect to processwireshop.pw. Feedback I would love to hear your thoughts about the upcoming changes and any feature requests you might have for Padloper 2. Whilst I cannot guarantee that any request will be implemented, I can promise that I will thoughtfully consider all feedback. Thanks for reading and thank you for supporting Padloper! kongondo

If you've ever needed to insert links to a large number of files within CKEditor you may have found that the standard PW link modal is a somewhat slow way to do it. This module provides a quicker way to insert links to files on the page being edited. You can insert a link to an individual file, or insert an unordered list of links to all files on the page with a single click. CKEditor Link Files Adds a menu to CKEditor to allow the quick insertion of links to files on the page being edited. Features Hover a menu item to see the "Description" of the corresponding file (if present). Click a menu item to insert a link to the corresponding file at the current cursor position. The filename is used as the link text. If you Alt-click a menu item the file description is used as the link text (with fallback to filename if no description entered). If text is currently selected in the editor then the selected text is used as the link text. Click "* Insert links to all files *" to insert an unordered list of links to all files on the page. Also works with the Alt-click option. Menu is built via AJAX so newly uploaded files are included in the menu without the page needing to be saved. However, descriptions are not available for newly uploaded files until the page is saved. There is an option in the module config to include files from Repeater fields in the edited page. Nested Repeater fields (files inside a Repeater inside another Repeater) are not supported. Installation Install the CKEditor Link Files module. For any CKEditor field where you want the "Insert link to file" dropdown menu to appear in the CKEditor toolbar, visit the field settings and add "LinkFilesMenu" to the "CKEditor Toolbar" settings field. http://modules.processwire.com/modules/cke-link-files/ https://github.com/Toutouwai/CkeLinkFiles

I use DBPowerAmp for ripping, there are a lot of advantages to using that, it handles cover art fetching very well, and the accurate rip is also very useful

Just throwing one more in there...just in case. Not open source but has served me well in the past, TagScanner: https://www.xdlab.ru/en/ Beyond tagging, renaming and moving based on custom rules makes this very powerful.

https://www.discogs.com/developers/index.html (untested)

I've used http://www.tuneupmedia.com/ a few years ago quite successfully. The interface is a bit wonky, but it get's the job done.

This may not help, but you could look into: https://picard.musicbrainz.org/

I was able to solve the problem meanwhile. It was related to my template file structure. I’m using the delayed output strategy together with some nested wireRenderFile() calls which lead to the problem.

Thanks @kixe - I didn't have a need for repeaters when I wrote this module, but it's certainly a good idea to support them. I have gone ahead and updated the module based on your idea and it now works for repeaters as well. Thanks!

Thanks for the heads up - I have removed this one from the module.

Thx, done! Also added an example for the hosts setting.

It's in the selectors docs (admittedly, in the fine print at the bottom of the relevant section):

@LostKobrakai It's not the first time when I met that something works with memory and not DB. Maybe the dumb question, but is there some way to determine it? (I guess the answer will be like - read source code ? ).

Which PHP version? No problems here so far with PHP 7.2.11

Hi @adrian, I was working with geoip.nekudo (it was among the services you suggested in another post) and so, geoip.nekudo it's not more free service it was bought by ipapi.com ?

OR-Groups are not supported by the in-memory matcher.

@adrian Hi Adrian, I quickly tried your module and find it very useful. But does it work with repeater fields? I couldn't get it working ... I played a bit around and found another simple solution. config.php /** * array of pages or page trees having multilanguage disabled in the edit screen * */ $config->singleLanguagePages = array(11973 => 0, 12334 => 0); ready.php /** * disable multilanguage in Page Edit for specified pages or page trees * define array of single language pages in $config * where the key is the page id and the value defines if the page acts as a tree parent or only for a single page */ $wire->addHookBefore('ProcessPageEdit::execute', function($e) { $page = $e->object->getPage(); $slps = $this->wire('config')->singleLanguagePages; // exit if doesn't match if (empty($slps)) return; $parentIDs = array_intersect($page->parents()->prepend($page)->each('id'), array_keys($slps)); if (empty($parentIDs)) return; foreach ($parentIDs as $parentID) { if ($page->id == $parentID) break; // page matches itself if ($slps[$parentID]) break; // page is part of a single language tree return; } // page is set as a single language page $page->template->noLang = 1; // we want repeater fields single language as well foreach ($page->fields as $f) { if ($f->type instanceof FieldtypeRepeater == false) continue; $this->wire('templates')->get(FieldtypeRepeater::templateNamePrefix . $f->name)->noLang = 1; } });

@tron1000 Do you have any js errors on page? Have you tried to clean the browser cache?

I haven’t really investigated this. But it’s interesting to get a little insight into how PW handles all the database queries when rendering a page. Thanks for that. ? Perhaps I’m going to play around with the Autojoin settings a little bit. For now, caching does the job. But autoloading fields would perhaps make sense to improve the performance of the first rendering of a page, the result of which is then stored in the cache.

Did you check your site for the query count. ProcessWire generally uses quite a lot of queries and given you seem to have quite a lot of nested stuff + probably some loops over the content types it might just be that the lazy loading of fields results in your code constantly talking to the database. Adding some auto-joins here and there might already make things faster.

Those sound exactly like the migrations / helper functions my Migrations module does provide ?

I understand now. There are a couple of ways you could do this - a simpler way and a more performant way. In the demo code below my selector is for sorting news items by title - you would adjust the selector as needed to find your restaurants. This code would go in the template file for your restaurant location template. 1. Simpler way: probably fine if there is not a huge number of matched pages // Function to get number plus ordinal suffix function ordinal($number) { $suffixes = ['th','st','nd','rd','th','th','th','th','th','th']; if(($number % 100) >= 11 && ($number % 100) <= 13) { return $number. 'th'; } else { return $number. $suffixes[$number % 10]; } } // Define the selector that finds your pages $selector = "template=news_item, sort=title"; // Get all the matched pages $items = $pages->find($selector); $position = $items->getItemKey($page) + 1; // add 1 to adjust for zero index $position_str = ordinal($position); // the position with ordinal suffix echo "This is the $position_str item."; 2. More performant way: if there are a large number of matched pages you can use an SQL query which avoids the overhead of loading all the pages First work out the SQL query for matching your pages: $query = $pages->getPageFinder()->find(new Selectors($selector), ['returnQuery' => true])->getQuery(); bdb($query); // Use Tracy barDumpBig() to dump the SQL query Now tweak the query a bit because you only need the IDs of the matched pages. The finished example for my sorted news items is below: $sql = "SELECT pages.id FROM `pages` LEFT JOIN field_title AS _sort_title ON _sort_title.pages_id=pages.id WHERE (pages.templates_id=45) AND (pages.status<1024) ORDER BY _sort_title.data"; $query = $database->query($sql); // Get the IDs in an array, flipped so the ID is the key and the position is the value $results = array_flip($query->fetchAll(\PDO::FETCH_COLUMN)); $position = $results[$page->id] + 1; // add 1 to adjust for zero index $position_str = ordinal($position); // the position with ordinal suffix echo "This is the $position_str item."; Credits: 1, 2, 3

I'm still fairly new here having switched to using ProcessWire for pretty much every project (hence the frequent questions ? ) from Concrete5. Concrete5 has had Gutenberg-esque block-based front-end editing for nearly 10 years longer than Wordpress. Although a finished site using C5 can look great for a site editor/frontend-only user with various drag-drop layout tools, we were finding c5 development had become very convoluted and was starting to make simple website projects unnecessarily complicated. C5's core weighs in at a hefty filesize too. This is why we started researching for alternatives and landed happily at ProcessWire. I already find WP development unnecessarily convoluted, especially compared to the simplicity of ProcessWire. And with Gutenberg, I can only foresee the same sort of headaches ahead for the WP community that we were finding with C5 - namely conflicts between blocks and the core and frontend UI and your design style and functionality being dictated to by the CMS in order to work in the Gutenberg features. Discovering ProcessWire has been a revelation for us - the clean API and design agnostic approach are making everything from simple website projects to complex web apps a breeze, with the added bonus of super simple frontend editing that not only wows client's used to site builder platforms but requires basically zero onboarding too. I would urge anyone thinking of building out Gutenberg inspired modules for ProcessWire to consider the above comments to ensure that what makes ProcessWire special is retained.

Hello @Michael van Laar, To answer you main question first: Yes, I don't see a performance issue in using either. The RepeaterMatrix and PageTable field are similar in that they use pages which can be used for content elements. I prefer the RepeaterMatrix field, because it has a better usability in that you can edit the content elements on the same page. Before there was the RepeaterMatrix field, I also used for a few times the PageTable field with the PageTableExtend module. But if you have bought the ProFields I would recommend using the RepeaterMatrix. On the back-end it is best when using a RepeaterMatrix field to have the default option on, that all repeater items should be loaded via Ajax. I assume the page you linked is not cached? According to WebPagetest the document was loaded after 670ms, which is good (best would be under 300ms). Everything after that are your styles and scripts which are not related to the RepeaterMatrix. For a regular XML sitemap, you would just output all visible pages on your website. So in your example that would be around 150 pages. But even more should be no issue. I usually use the module MarkupSitemapXML for this. With other sitemap formats I have not much experience, I have just learned about them: Image sitemap: You could output the link of a page and all it files like this. Video sitemap: This seems to work only with self hosted videos. So not embeded videos. But I could be done like mentioned before. All of those solutions mentioned are decoupled from the RepeaterMatrix and PageTable field. On every page you only output the content elements used for the page. So the total count of content elements wouldn't matter. If you have a page with 10 or 50 content elements, it should not really be a performance issue. I can think of no use case, where you would output all content elements of all pages at the same time. As mentioned before the sitemap example can be handled without have to deal with RepeaterMatrix or PageTable. Yes, thats what the RepeaterMatrix field is build for. Caching always helps if you don't have user input on your page. But depending on how you build your templates, without cache there should be no performance issue. For content elements I can't think of a better solution than RepeaterMatrix. If you have more questions, it would be best if you would share some screenshots of your set-up. ? Regards, Andreas

If anybody might wonder. This is how to setup permissions for a sub-page of a processmodule: As easy as adding the permission to the nav item! If you want the permission to be created/deleted on module install/uninstall you also have to add it in the "permissions" array: $info = [ 'title' => 'ProcessProjects', 'summary' => 'ProcessModule to manage all Projects', 'version' => 1, 'author' => 'Bernhard Baumrock, baumrock.com', 'icon' => 'thumbs-up', 'permission' => 'projects', 'permissions' => [ 'projects' => 'Run the Projects Management Module', 'aggregate' => 'Create Aggregated Reports', ], 'page' => [ 'name' => 'projects', 'title' => __('Projekte'), ], 'nav' => [ [ 'url' => '', 'label' => __('Projekte'), ],[ 'url' => 'mails', 'label' => __('E-Mails verwalten'), ],[ 'url' => 'reports', 'label' => __('Berichte verwalten'), ],[ 'url' => 'aggregate', 'label' => __('Aggregierten Bericht erstellen'), 'permission' => 'aggregate', ], ], ]; Make sure to logout/login, otherwise you won't see the changes in the menu! If you call the ProcessModule's page directly you will instantly get the result of the changed permissions: Whereas in the menu it is still there until you logout+login: @szabesz you asked for that in the blog comments...

Just had a small world experience. I have been emailing with Ueli at https://www.whatwedo.ch/ who are the folks who operate the https://ip.nf/ IP to country API service. He just mentioned that they are partners with https://novu.ch/ (built with PW) and that they use ProcessWire a lot. So anyway, he is keen to support this module and to make sure their service will be able to keep up with any requests made by it to their service ?

Not to sure how the rest of your template is set up, but I have found that the following does work. $page->getField('body')->label; Are you using the label in the template corresponding to the actual page, or are you pulling in the label in another template?

More updates! Here is what was added since my last post: FieldtypeDatetime now supports format argument. Which allows you to pass PHP date format string and retrieve your datetime values formatted the way you want. Besides FieldtypeDatetime fields, the built-in fields created and modified are also support new format argument. FieldtypeOptions is now supported. first and last fields on PageArray types are now supported. As per @eelkenet's request. See above post for details on those. Finally, now there is a way to add support for any fieldtype you want via third-party module. What you need to do is create a module with the name exactly as the fieldtype you want to add support for with "GraphQL" prefix. So for FieldtypeMapMarker it would be GraphQLFieldtypeMapMarker. Then you need to add three required methods and install it. This will automatically add GraphQL support for your desired fieldtype and it will be available in your GraphQL api. Checkout the documentation and an example module for reference.

Hey everyone! It's been a while since I last had a time to work on this module. But now I finally managed to focus on this module. So here are the latest updates. The codebase of the module grew very big and the more features I added the more time I had to spend to make sure the changes I made does not break anything. Because I had to manually verify if everything works as expected. After long night hours of trial and error I managed to setup tests for this module. Tests will help us quickly add/remove features as needed, because now there is no need for manually verifying all edge cases. Also I setup the Travis-CI so people can contribute more confidently and I can merge pull requests without worrying! There are already bunch of tests, but there is still some I'll be adding. ? ? I will add some documentation on how to run tests locally in github wiki pages soon and let you know here. Another thing to note is that the master branch of our module no longer tracks the vendor code. This means that if you download the master branch and put it into your /site/modules directory it will not work. Instead you should use release builds that are a cleaned version of the module. It includes required vendor codes and does not have extra files that are not relevant to ProcessWire. Like presentation gif images, test files and so on. This makes the module size smaller!

A customer wanted to disable save ( $config->demo ) for users with a specific role. I created a module for that. If you need it, it's over here. To select the role(s), go to the modules config settings. download at github