Leaderboard

If I understand the question correctly, you might be looking for a regex capture collection, but I think support for that is really rare and am pretty sure PHP/PCRE does not have such a thing. So I think you'd have to use a couple of regular expressions here: one to find all the {mailto...} tags, and another to isolate their attributes into independent arrays. That's because presumably the attributes can appear in any order and some may or may not be present. Here's how you might do it: function findSmartyMailtoTags($markup) { $tags = []; if(!preg_match_all('/\{mailto(\s+.*?\baddress=".*?")\}/', $markup, $a)) return array(); foreach($a[0] as $key => $tag) { $attrs = [ 'address' => '', 'text' => '', 'subject' => '' ]; if(!preg_match_all('/\s+(?<name>\w+)="(?<value>[^"]*)"/', $a[1][$key], $b, PREG_SET_ORDER)) continue; foreach($b as $attr) { $attrs[$attr['name']] = $attr['value']; } $tags[] = [ 'tag' => $tag, 'attrs' => $attrs ]; } return $tags; } If you wanted to do it without a regular expression, you could do this: function findSmartyMailtoTags($markup) { $tags = []; foreach(explode('{mailto ', $markup) as $cnt => $line) { if(!$cnt || false === ($pos = strpos($line, '"}'))) continue; $mailto = $line = substr($line, 0, $pos+1); $attrs = [ 'address' => '', 'text' => '', 'subject' => '' ]; while(strlen(trim($line))) { list($name, $line) = explode('="', $line, 2); list($value, $line) = explode('"', $line, 2); $attrs[trim($name)] = trim($value); } if(!empty($attrs['address'])) { $tags[] = [ 'tag' => "{mailto $mailto}", 'attrs' => $attrs ]; } } return $tags; } In either case, either version would return exactly the same thing (print_r result): Array ( [0] => Array ( [tag] => {mailto address="someone@domain.com" encode="javascript" text="link text" subject="The subject line"} [attrs] => Array ( [address] => someone@domain.com [text] => link text [subject] => The subject line [encode] => javascript ) ), [1] => Array ( [tag] => {mailto address="hey@hello.com" text="Hi" subject="Welcome friend"} [attrs] => Array ( [address] => hey@hello.com [text] => Hi [subject] => Welcome friend ) ) )

Remove Blocks A textformatter module for ProcessWire that removes blocks of text/markup between configurable delimiters from output. This allows you to "comment out" blocks of text/markup so they remain present in the field but are not shown in the front-end output. This can be handy if content needs to be removed temporarily and will later be reinstated. Or you could use a commented block as a placeholder to indicate to an editor where some content should be added. Installation Install the Remove Blocks module. Configure the open and close delimiters if needed. The default open delimiter is {{ and the default close delimiter is }}. Tip: don't use delimiter characters that CKEditor will encode to HTML entities, e.g. >. Usage Add the Remove Blocks textformatter to one or more fields. Add the open and close delimiters around any content that you want to be removed from output. https://github.com/Toutouwai/TextformatterRemoveBlocks http://modules.processwire.com/modules/textformatter-remove-blocks/

Just use `<?php foreach(): ?>` and `<?php endforeach; ?>` - I very much doubt hosting companies will remove support for that. I wouldn't bother using a Template Language. It's just overhead that's not often worth it.

Visit Pigtail Pundits For a digital agency, finding the time to do your own website is always difficult. It gets marred by other priorities - new projects and ongoing projects. Unless of course, there’s some slack, and you’re alert to leverage it. We were lucky to steal some 30 odd days from other work. In the bargain we revamped our old website into something fresh, complete with updates on our newer solutions and Case Studies. The Thinking Behind the Design & Copy The whole subject of digital marketing is abstract and fuzzy to most clients. Jargon, complicates its understanding further. If we could use a familiar metaphor to describe the digital marketing solutions that we provide along with its benefits, we could perhaps inch closer to getting messages understood. Or so we thought. Equally, we could introduce some flavour into the language that metaphors do allow. Metaphors, by the way, are double-edged swords. It clarifies and also confuses. It tickles your imagination. It can also put people off. Extreme reactions, we felt, are far better than neutral ones. That was a risk that we decided to take knowing the consequences. The theme lends itself to some delightful metaphors which are not part of the usual digital marketing lexicon. The tone is aggressive. The metaphors help in blunting the sharpness. The metaphors color the language and visuals. The overall effect of this is unique. We also attempted to peel off some of the fuzziness that exists in digital marketing, especially in India, using copy. We tried to identify with the pains of the customer and then focus on our solutions as the best answers to the pains. We followed the StoryBrand framework by Donald Miller to craft the copy in the Solutions section. Visit Pigtail Pundits Under the Hood We have been votaries of ProcessWire since 2014 and have always used it on our own and client projects to great benefit. This occasion too was no different for our own website. Under the hood it uses Processwire CMS Bootstrap for theming Form Builder ProCache [gives us a page speed between 2 and 3 secs] Custom PHP for image alt tags SVG icons to reduce the weight and improve page speed. Visit Pigtail Pundits Bouquets and brickbats, welcome.

Agreed. In template files I personally prefer <?php foreach (): ?> ... <?php endforeach; ?> (and similar syntax for if...endif etc.) and for output the short echo syntax (<?= $some_var ?>) makes sense, but I'd also advice against using short opening tags (<? ... ?>). Although it remains a part of PHP syntax, there's no guarantee that it's always going to be enabled, and it's commonly frowned upon by PHP devs ?

Hey Robin - I am really loving this module - it's becoming one of my key navigation tools, so thank you! This might be feature creep so I definitely won't mind if you don't think this is a good idea, but I was thinking an "Add New" link at the top of each list could be quite useful.

I've done a RockGrid that lists the translation availability like this and I think for custom listings that's the best option and better than adding labels for all kinds of whatsoever to the tree: I think somebody in the AOS thread came up with a solution to style language tabs differently based on the state (populated/empty). @tpr ?

Browsing this new Pundits' site a came across this little blog. Although it was spotted before by @diogo, I thought it might be a good idea to link it here, as it has a couple of PW cases described and seems to be made with PW itself.

Congratulations to all of you on your new design. As with all the sites you do for me and my clients, it is appropriate, clean, and supports (not overwhelms) the message.

$string = '{mailto address="someone@domain.com" encode="javascript" text="link text" subject="The subject line"}'; function mailtoArray($input) { preg_match_all('/(?<attr>[\w]+)=\"(?<value>.[^\"]+)\"/i', $input, $matches, PREG_SET_ORDER); return $matches; } if (strpos($string, '{mailto') !== false) { $matches = mailtoArray($string); print_r($matches); } I would do it that way. One of the matches is the entire tag, it's [0], then [1] or ['attr'] is group match 1 and [2] or ['value'] is group match 2. However you can do a string replace on just match 1 to format it to an anchor tag.

? Congrats for the new site! ? ... and, as always, the good write up! --- --- --- I never forgot your first case study here back in 2014. Especially one post a bit down in the thread: --- --- --- There is only one question I have: Why you’re called Pigtail Pundits? ?

I started making this so it puts it in an anchor tag <a href="mailto:"> but then I realised I was guessing what "link text" and what "The subject line" is. Instead I've just done the function what will split them up into an array. For simplicity it also adds the `$matches[0]["attr"]` and `$matches[0]["value"]`. You can foreach them and just use `$match["attr"]`. function mailtoArray($input) { preg_match_all('/(?<attr>[\w]+)=\"(?<value>.[^\"]+)\"/i', $input, $matches, PREG_SET_ORDER); return $matches; } $matches = mailtoArray('{mailto address="someone@domain.com" encode="javascript" text="link text" subject="The subject line"}'); print_r($matches);

For selectors you can't use '->' as that is reserved for things like $page->title (Array). Instead you use 'upload.description'.

Thanks for sharing! This is a dead simple but really great idea! Have you thought of supporting clients – who are generally unable / do not care to memorize features like this – by optionally adding a CKEditor button in order to add/remove the delimiters? I have two of those buttons in mind: 1. simply adds/removes delimiters of selected block(s) 2. adds/removes delimiters around the selected block(s) but also clones it, putting a copy of it right below the selected part of the text. The second point is for a use case of a simple "draft" feature: when an already published page is being edited, one could work on rewriting a paragraph – for example – and save the page before the original version is removed and the new paragraph version is published by removing the delimiters too.

@Jan235 You could also try out the TextformatterFluidImages module that does some of what you are after (setting custom classes) and perhaps modify it to add the srcset attribute if it is going to be the same for all images in the CKEditor inputfield.

There is no hookable method especially for images inserted in a CKEditor field. But two options: 1. Use/code a textformatter module to manipulate the image tags within a field. This approach has the advantage that you don't have to mess around with your field settings to make sure the classes and attributes you want to add are allowed by ACF and HTML Purifier. There is even an existing textformatter module you can use: https://modules.processwire.com/modules/textformatter-srcset/ 2. Hook the saving of pages (e.g. Pages::saveReady) and modify the markup in your CKEditor field before it is saved. The approach would be similar to the textformatter option - you parse the markup to identify the image tags (using regex or a DOM parser such as DOM) and use the src attribute to get the relevant Pageimage to create your different sizes from. The difference is that this parsing/modification is done whenever the page is saved rather whenever the field value is loaded. Option 2 is more efficient, but I would tend to go for option 1 because it's not destructive and gives greater flexibility to make changes down the line. And maybe that existing textformatter module is just what you need.

Hi everyone, I know we'd all like to see ProcessWire grow in popularity (maybe not hugely, but just enough that more people know about it which can help to convince clients to go with it). It strikes me as strange that the ProcessWire Github repo still has less than 300 stars - I'd like to see us well over a thousand which should be an easy task for the forum members to achieve. I see so many other projects with lots of stars but for some reason it doesn't seem like it is something we tend to do around here, despite being a very active, friendly, and supportive environment. I also think that starring your favorite modules doesn't hurt either - I think that will also help to increase the visibility from PW and also help out module authors a little as well. If you can show your Github project has a decent number of stars it shows that you are building things that people want which can help you land a job and helps you to convince the client that you and ProcessWire are a good mix. Anyway, if you have a minute to do some starring of PW and your favorite modules, hopefully it will benefit us all a little. Thanks!

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

v0.1.6 released - introduces a feature for adding a new sibling page, as requested above by Adrian.

Hi @adrian, just noticed I'm getting this warning with debug mode on for a site I updated to the latest version... ( ! ) Warning: Illegal string offset 'value' in <snip>/site/assets/cache/FileCompiler/site/modules/CookieManagementBanner/CookieManagementBanner.config.php on line 109

@adrian Ok, works again with Lister disabled in the Batch Child Editor. For some reason the site hoster doesn't want to upgrade PHP. Thanks

I think it was a custom CSS rule, not a built-in aos feature.

Hey @bernhard. You should change the link to the repo in your first post to https://gitlab.com/baumrock/FieldtypeRockGrid as the URL has changed. Also, is the information that this module is still an alpha correct?

Thank you @horst for all the warm comments. Your question is answered here: https://www.pigtailpundits.com/about-us/our-name/ Warmly, Unni.

Done ?

I create a 'ready.php' in the '/site' folder. This is where you can put your class and you can access it anywhere. If you need to re-use it or plan on releasing it, or just want to keep your code tidy. I would use a module.

Hey @adrian, amazing Module, works like a charm! May I ask why you use two checkboxes for the consent instead of radios which toggle automatically in relation to each other? Imho radios would be a better fit for they transport the notion of having an OR relation better than checkboxes where the user probably assumes its a AND relation… For anyone not wanting to use a module, check out http://cookieconsent.insites.com – pretty easy to integrate, I've included it before as a simple first step, with using page-fields to feed the labels.

I like idea 1 - will explore that. Idea 2 I don't think is necessary - even technophobes know how to copy/paste text if they want to duplicate it.

Mmm, I don't think this will be as straighforward, I think this is all performed in javascript: https://github.com/processwire/processwire/blob/master/wire/modules/Inputfield/InputfieldCKEditor/plugins/pwimage/plugin.js Maybe override the whole CKEditor module (copy the whole module to site/modules) and rewrite the line where the img tag is created, which i think is here: https://github.com/processwire/processwire/blob/master/wire/modules/Inputfield/InputfieldCKEditor/plugins/pwimage/plugin.js#L210

There are several outlined in the second Issue that @Robin S linked to. It would actually be great if you could comment on that issue to get Ryan's attention once again if you wouldn't mind.

Best wishes for the new part @kongondo. It feels like a perfect fit, Padloper and you. ?

Thank you all for your answers! Also interesting with URL segments and GraphQL. It seems it produces slightly slower requests, so I will test it for another project. Using a router solution like the one you pointed seems a bit overkill at this stage specially for my knowledge level. So far Vue and Processwire work very well together. I built some kind of REST api and the performance is very good both for read or to create pages. In some pages I am using regular forms to create posts, users... and in some others I am using vue. Vue of course offers much more potential to build complex, modern interfaces. Great that I can combine both methods. I think Processwire is flexible and powerful enough to build webapps with a smaller learning curve than a full fledged framework such as Laravel. It would be just perfect if creation of APIs for consumption by the front-end would be just a bit easier out of the box. (Is not that the hot keyword of the year? Headless CMS?).

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.

Right, but I don't know how to get the results in the frontend. Here is what Ryan wrote in the template file:

This should work: <?php $features = $pages->find("template=newsitem, limit=3, sort=-date"); foreach($features as $feature) { $img = $image->first()->size(320, 180)->url; echo " <div class='column is-4' >" . "<img src='$img' alt='' />" . "<h3 class='title is-4'><a href='{$feature->url}'>{$feature->title}</a></h3>" . "<p><span class='date'>{$feature->date} &nbsp; &bull; </span>" . "{$feature->summary}</p>" . "</div>"; } You can read more in the docs. On why you should use first() - or not.

Nice module, I see I can get the current user's vote but what about a given user's vote?