Leaderboard

Hi all Just wanted to wish everyone who celebrates it a very Merry Christmas. Thanks to everyone on the forums for all the time and support over the year and all the answers, help and general banter. 2019 is hopefully going to be like 2018. Lots of learning, lots of Processwire, lots of great new Processwire developments. Anyway - have a good one ? P

Fieldgroups currently are just an additional layer of "glue" between templates and fields, and for most they are just a few additional lines to write when assembling templates through the API. There are a few points where that additional layer can add some really nice magic to PW, but even most PW module developers never come across these. For everyone not deeply into obscure PW vodoo magic, creating a template with fields is always: Create a template Create a fieldgroup with the same name as the template Create your fields, save them and add them to the fieldgroup Save the fieldgroup Set the fieldgroup in the template Save the template Of course, you can reorder the steps as long as the objects are created before being used and saved after being changed. Yes, they are. As written above, they are just a necessary glue.

Seems like we're talking about a couple of different things here: 1. Making certain "things" (don't think I can be more specific than that) reusable in multiple projects that you work on now and in the future. These are for in-house use by a single developer or team of developers and not shared publicly with the PW community (in the modules directory for instance). You could try and use modules for this purpose (I think this is what @bernhard is interested in) or any number of other approaches. This is stuff that's very much down to individual workflow preferences and I don't think the PW core can provide easy solutions that are going to suit everyone. 2. Modules that are shared publicly with the PW community. This is totally a matter of opinion, but personally I'm not enthusiastic about things like sliders and blogs being packaged and distributed as modules. In seems very WordPressy and not really the PW way (teach a man to fish, etc). A module could provide some building block that is useful for making a slider or a blog but it shouldn't do things like try and anticipate all the fields a user needs, output all the markup, bundle third-party JS libraries and suchlike. The beauty of PW is that it's so quick and easy to build solutions that are exactly tailored to the project at hand with nothing unnecessary left lying around. And while developing these solutions you're always learning how to be a better developer. A plug-and-play module that outputs whole pieces of the website works against that IMHO.

Just add them to the template's fieldgroup. $fg = $template->fieldgroup; $fg->add($field); $fg->save(); It is save to assume that there is only one fieldgroup, the one which you can access through $template->fieldgroup (or $template->fields, which is just an alias).

I think it doesn't support it yet. I'll check how to add this, thanks for pointing this out.

This is an interesting thought. My opinion has always been: teach a man/woman to fish = pw core and API (basically, /wire/) man/woman fishing = /site/ So, modules, or as others call them, custom plugins, are exactly where the fishing should be happening. I don't find it at all WordPressy since ProcessWire's (custom) modules, unlike WordPress's, are not the cobbling together of disparate things to provide a solution to a problem that should have fundamentally been resolved by the core. Agreed, but therein also lies the beauty of reusability. If I find myself building blogs with every/most sites that I build, it makes sense to package the blog solution. In other words, modules ?. The point about second-guessing what fields a user needs is a good one, but it is not one without a solution. This is easily solved (again, back to blog module) by a 2-step installer that asks what fields the user needs. We also have Fields like Table and DynamicSelects that allow you to add/remove fields/columns even post-install.

Sometimes a module does need to create fields, templates and pages but it would be the exception rather than the rule. Most Process modules, even complex ones with multiple (pseudo) sub-pages such as Admin Actions, do not create fields, templates or pages other than the single page used to execute the Process. Instead they use multiple execute() methods that work via URL segments. The forms on those pseudo sub-pages don't save data to PW fields but save all the module-related data to the module's config (stored as JSON in a single field in the database). The "nav" array in the module info takes care of creating the navigation to sub-pages. But perhaps you already know this if you've studied ProcessHello and other Process modules. Some off-the-top-of-my-head cases where you probably would need real fields/templates/pages for a module: You want to store files or images for use with the module. You want to use a Repeater and don't want the extra work to create to repeatable input type in the Process module. You want to store a larger amount of data than is allowed for in the TEXT column type used for module config data (although alternatively your module could create a dedicated table to store its data).

Hi Folks, We've soft launched a client's site, https://canadia.ie Short summary of ingredients: UIKit based UI Some Vue.js sprinkles: Axios, GrahpQl, lot of methods for the product filtering Usual arsenal of PW modules like AOIM, AllInOneSeo, AutoSmush LeafletMaps, etc DO Server + a new tool 'RunCloud' to handle server config and the time consuming bits like SSL, DB setup etc Considering we only rolled to production today for the soft launch the site is very fast - especially filtering products, it's by far running 20x faster than the staging server. I'll post a more detailed update once we have finished fine tuning and installing any other post production modules.

It seems that only if the value is empty the cleanBasename will properly work in Windows.

I found the problem. On the LanguageSupport.module I had the "C" value translated to "en_US.utf8".

Merry Christmas to ProcessWire developers, supporting forum members and companies using PW.

Hm, I'm running out of ideas... And this? d($sanitizer->filename($filename)); d($sanitizer->filename($filename, Sanitizer::translate));

Thanks a lot, I'm going to study It and try to adapt to my needs.

You're totally right, good catch thank you! I updated the Readme accordingly.

On fresh PW installation with just TracyDebugger installed it seems I'm getting proper results:

I'm definitely interested in developing such a module, but I'm afraid my knowledge of ProcessWire isn't nearly enough... ? But I would be happy to contribute my ideas. In general, I think it would be better if it were included in the ProcessWire API.

I want to create a full featured Newsletter mailing system with subscription/unsubscription pages, profile edit pages, some backend pages for Newsletter creation, Newsletter handling (sending + CRUD).

I get the same results as Adrian. Are there any hooks in the game? Tried on fresh install? Could you also d(basename($filename)); @PWaddict

We were fortunately able to make the case for using something different, in order to meet our needs (the favoured CMS here is Drupal). It'd be great if we started a new trend!

I have previously been using uppercase URL in $page->image->URL for browser cache busting query string purpose. Is this compatible with MarkupSrcSet? My current image url is $page->image->srcset('860x0,/2,/3').

I'm on windows:

By the way, this is what we are currently doing with Media Manager. If you add a field to a media manager (in-house) template, media manager will find it and will make it accessible to you via its API. Essentially it means you can use Media Manager for a whole range of things.

@adrian You're right, I cannot duplicate ? I'm not PWing nowadays too much but so far I haven't had such issue with hidden pages. @jmartsch Thanks, I think I found why the roles select wasn't displayed to you. It uses AOS's "Add placeholder to asmSelect" (under AsmTweaks), so if you do not check that you won't see the ROLES label. Plus UIkit uses a background-image to show the arrows for the select boxes and AOS was overriding it with a white background color, that's why they were not visible to you. Try v2.0.6 where you can see at least the arrows even if AsmTweaks is disabled.

It's a perfect example of what I'm talking about: It creates these fields: And as you can see in this example it automatically adds these fields to two selected templates. These tasks are really not as easy to develop as they could (should) be imho. Once installed, you can then input data on all pages with selected templates: You can't do that using process modules, or am I missing some concept here? There are MANY use cases for this. Interesting you mention this. It's something I've thought about previously. If I had to redo the Blog module, I would combine some of the fields. Your example of an address field would maybe make sense to be combined in one new fieldtype. But in many cases I think this is not the best option. I care! Developing a new Fieldtype is a lot more effort than just creating fields, assigning them to templates and creating new pages! But as soon as you want to make that process reusable (eg for dev/staging setup)/revertable you need to use something like the migrations module. But what if you wanted to use 3 of the fields that you created via migrations in another project? Bad luck, not possible - or is it?

JSON export/import IMHO is really not a good way of doing that programmatically. There are always situations where you FIRST need to have the templates existing and THEN you set the correct settings. You can't do that in one step. Simple example: - create template "blogposts" - create template "blogpost" - set allowed children for "blogposts" to "blogpost", parents to "home" - set allowed parents for "blogpost" to "blogposts", parents to none You simply can't do that via import/export, can you? That's a special case because it's a module that is all about PW fields, templates and pages - indeed anything in the PW API. Reading this I have to clarify: Didn't want to say that the module is bad in any way. The module is great, but the situation we have is not great...

That might be true, but IMHO that's a huge limitation of PW. I've had the need to create fields/templates/pages a LOT over time. Many of us are now doing it manually (creating fields on dev, then importing them on the live system). We also have the Migrations module, but that's only half as good as it could be. At the moment it is really hard to develop modules that ship with a certain setup of fields/templates/pages and maybe on later versions upgrade those settings. I'm thinking for a long time now of a new kind of API that makes these operations a lot easier (adding and removing fields/templates/pages etc. is not easy, especially if you need to take care of collisions (field already exists, can't remove field because it's used by a template etc.). If anyone is interested in helping on developing such a module - similar to the Migrations module - send me a message.

I guess @Gadgetto is talking about how to create/edit/remove/move/etc fields/templates/pages/etc. when they are necessary for an installable and reusable module? Then pages import/export is no option. You can have a look here how you can do that: https://github.com/nicoknoll/MarkupSEO/blob/master/MarkupSEO.module#L971-L1095

You seem to be confusing Fieldsets and Fieldgroups. They are very different things. Fieldsets are special fields to help you group fields together for the purposes of how they are displayed on a page during edit. In a sense, they group the Inputfields of the fields within the Fieldset. Each Fieldset is then displayed in its own tab during page edit. As usual though, the order or even the presence of fields on a page have no bearing on their appearance in the frontend. Back to the main question, I quote the definitions of Fields, Fieldgroups and Templates as per the docs:? Fields That just means a database table, that is created via ProcessWire using a defined schema and installed as a module. You can read more about them here. Fieldgroups You will rarely have to interact directly with Fieldgroups. Each template you create has a corresponding Fieldgroup. A Fieldgroup just says these are the fields available in this template. Hence, it is possible to reuse a field across different templates (i.e. across different Fieldgroups). More about them here. Templates This one is self-explanatory, me thinks ?. More about them here.

If all your variations (thumbnails and other variations) are corrupt you can delete them with the Pageimage Remove Variations module. The variations will be recreated next time they are requested.

There is no method call on the repeater matrix field value there - I think you meant to include ->find(): $items = $page->matrix_slider->find('start=1,limit=3'); That should work.

You can use: $input->post('reset-button') or $input->post->{'reset-button'} This is not a PW issue, but rather a PHP one - you just can't use hyphens like that. That is why PW field names use underscores and not hyphens.

Try to use slice() $matrix = $pages->get(11203)->my_matrix; $items = $matrix->slice(1, 3);

Hmmm, there is a new action for PageListerPro (https://processwire.com/blog/posts/processwire-3.0.121-core-updates-and-more/).

Finally ?? Thank you adrian for this awesome tool and your great support in the forum!

It's great to see a government agency using Processwire. Here across the Tasman, I think Silverstripe has been mandated as the government CMS of choice which is sort of ok in some respects, but it's a lot more complex than it needs to be for many projects.

And a fourth: $this->wire->pages I prefer this version because you don't need to activate functionsapi (and the functions api should not be used in module development), it is multi instance proof and I get IntelliSense in my IDE Don't know which one is the best in terms of performance...

I've tried some experiments with Processwire on Heroku (with multiple Dynos). It worked - I used For Sessions: Heroku Redis + https://modules.processwire.com/modules/session-handler-redis/ + https://elements.heroku.com/addons/heroku-redis For Uploads: Amazon S3 + https://modules.processwire.com/modules/amazon-s3-cloudfront/ For the DB: https://devcenter.heroku.com/articles/jawsdb-maria

Sorry for my late response but thanks for all your messages. I'll look into the possibilities to develop this myself. If there's anything new from my side, I will keep you guys posted.

I'm writing this to give back something to the community that has given so much up front over the past year. I noticed there's hardly any discussion about testing in these forums so I decided to write this quick primer to get some discussion going. I'm by no means an expert on phpunit or selenium but I had to jump through a few hoops to get it working (especially with PHPStorm), so I thought I figured I should share my experiences with the community. Also, I'm hoping non Phpstorm users can still pick something up useful in this post. Prerequisites : It is assumed Phpunit (https://phpunit.de/) is installed via Composer, Selenium (http://www.seleniumhq.org/) and Php-webdriver for Selenium (https://github.com/facebook/php-webdriver) is preinstalled. For Phpstorm users, there's a fairly detailed installation and unit testing instructions here (https://www.jetbrains.com/help/phpstorm/2016.1/testing.html) I found some parts of it leaving me with unanswered questions, so I'm hoping this post will supplement any questions that you might encounter. Rather than writing a single monolithic post, I will write several posts covering different topics.