bernhard

RockGrid is perfect for such scenarios: You get nice, condensed, sortable, paginated tables You can style cells easily (like statuses for sent, pending, draft etc) You have a batcher built in, making it possible to send x mails at a time, running via AJAX so you don't get server timeouts The main reason why I released it under the MIT license was that it can be built into other modules easily. That would be a process module and MarkupAdminDataTable and LOTS of custom code...

I'd load all quotes on page load and display one random quote via javascript. Similar to this example https://embed.plnkr.co/plunk/RHIPp8

Some what? 5-10? 100s? 1000s? Yes ? But I don't get what you are trying to do exactly. Where does the user click? What should then be showed? Some quotes randomly sorted? Or one random quote of many? Please be more precise in your question - there are always many ways in ProcessWire and the best depends a lot on the scenario.

Just read "headless" on their site and thought this would be an important keyword for processwire.com as well. Maybe something like: I'm neither a native speaker nor a marketing slogan guru, but I hope you get what I'm trying to say. And as a proof, this statement could be linked to this video as discussed here: While I love that video content and know how true every word in it is, I think for new users this might not be obvious. Quite on the contrary, I think a video with one stranger telling something about a great system that he developed in his living room (sorry ? ) does not have the professional impression that it deserves. Also 33k views since 2010 is really not a lot - all of us know that these are no fair indicators for the power or greatness of processwire, but new users might not get that. I think it would be great to have a 2minute introduction video in a modern and professional design. I even think that it would be great to let this video have 100% the same text of the first 2min of the ancient video from 2010 to show how revolutionary the platform was back then (all modern CMSs sell that as the new big thing) while on the other hand PW has it for 10 years and has been stable all the time! Maybe someone could help with such a video? @heldercervantes or @Jonathan Lahijani ? One more thing that I like on modern websites about products is a section where the product is compared to other players in the market. Like runcloud does it on their website: Here is how such a page looks like: I think such pages could make a LOT of sense because people already know DroomlaPress and such a comparison page could outline the differences and show the strengsths of processwire in a fair and efficient way. If you try to compare it via google/youtube searches processwire will always lose the game because it's just not focussed on marketing the way the other platforms are. But that could easily be outlined on such pages, e.g. comparing CMS XY to PW: Good luck with the new processwire.com and happy and successful new year to everybody ?

Maybe it's easier to let Google do the heavy lifting and just display the results on your website... https://processwire.com/blog/posts/composer-google-calendars-and-processwire

Never had any problems loading the tracy settings.

In general there are 3 things to watch out Any redirects in .htaccess file? Any redirects in Apache config (see your webserver or panel config) Any redirect settings in pw backend (template settings for http/https, trailing slash yes/no) Two of them are likely working against each other and leading to an endless redirection loop

This post by Ryan shows how you can do it. I've never done it on my own, so I'd be happy to see a step by step guide that I might add to my custom admin pages tutorial!

Hi @tpr I've had a problem when using the skip trash feature of AOS with ProCache, here is Ryan's explanation: Is this feature only enabled for super users or for everyone in the admin? Maybe it would be better to trash pages first and delete them thereafter (automatically) rather than skipping the trash? Here is the complete post: Are you aware of that?

Thx @Robin S, interesting points. As always it's not black/white - the question is how far one can/should go in terms of packing things into a module vs. building it from scratch all the time via the API. IMHO there are standard things like blogs, forum, sliders, guestbook etc. that are not that easy and quickly to create with PW and therefore cost a lot of time and money on my end. I wished I had more reusable products for such tasks. And I'm working on it. On the other hand I love the freedom of PW. But I think both worlds can live well together in our universe. And that might be another argument for using regular fields over custom fieldtypes @kongondo: When using regular fields, the user can easily customize those templates to their very own needs. Imagine a blog module that ships with fields blog_title blog_date blog_content blog_gallery If the user needed a field to store files he could either create a PR with an update script (again both migrations and export/import would not work) or create this single field on his own and just use it for himself. This would not be that easy if those 4 fields where wrapped in a single custom blog fieldtype (that would be the WordPress way of a plugin). Do you understand what I'm trying to say? ? Not trying to convice anybody here - just enjoying to get valuable input as this is in my head for quite a long time...

I don't think that this is a special case at all. Imagine a slider module that could help us to create an image slider for our websites. It could create the markup (maybe let the user choose the css framework) and it could also create the necessary fields in the admin and add those fields to the templates that should display a slider. I've had lots of those situations finding myself copying and pasting code snippets from one site to another. Finding a bug in one page, having to fix it in all my sites manually etc etc. Now, that's what I call messy ? If we had a proper API that made those tasks easy, I think we would get a lot more reusable modules just like the SEO module, because then it would be a lot easier to create such modules and push fixes, changes or updates. And upgrading existing projects would only be one click (or git pull). Agree! I've learned a lot from your modules. But I still think the API need one abstraction layer on top of that. See for example how hard it is to edit a field in template context: https://processwire.com/talk/topic/6656-change-field-description-in-context-via-api/ It should be somethink like this, imho: $api->editInTemplateContext('mytemplate', function($field) { $field->label = 'Custom label for mytemplate'; }); The migrations module offers some of those helpers. It's one step. But there is at least one more step missing...

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...

So you think MarkupSEO would be better as a single Fieldtype having all those inputs and storing it in one db table? I don't think so, but maybe I'm wrong, so I'm curious to hear your and other's thoughts. What about creating a blog module where you can add new blog posts that have a title, content, publish date, date, image gallery etc etc. - create a fieldtype for that or just use PW's core fields and put them together in one template, setting a parent template to allow only these kind of pages as children. What about creating a slider module? Using a repater with images and text fields for headlines. That's easy using core fields. But the problem is that we are always building custom solutions that we can not reuse in other projects. Because it's so easy to create fields/templates/pages in the admin GUI, but it's so hard to create then via code (compared to the GUI). Using Migrations is a first step in the right direction, but you cannot split those migrations up to several places (meaning: modules). IMHO that's a real problem. Exactly. At the moment! I wished there was a better way. Something like migrations for each separate module. I mean... Fields are the way to store all the user input in processwire, so I think it's a real problem that we cannot properly use that core features easily in our modules.

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

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

@jmartsch now you can:

RockFinder v1.1.0 now supports filters. This makes it possible to use custom access control (eg showing only certain rows on a RockGrid): https://github.com/BernhardBaumrock/RockFinder/commit/3e4daae0f283280672ab606a1eef1b16497f19fe https://github.com/BernhardBaumrock/RockFinder/blob/3e4daae0f283280672ab606a1eef1b16497f19fe/readme.md#filters--access-control Filters & Access Control You can filter the resulting rows by custom callbacks: // show only rows that have an id > 3 $finder = new RockFinder('id>0, limit=5', ['title', 'status']); $finder->filter(function($row) { return $row->id > 3; }); You can also use these filters for showing only editable pages by the current user. Be careful! This will load pages into memory and you will lose the performance benefits of RockFinder / direct SQL queries. $finder->filter(function($row) { $page = $this->wire->pages->get($row->id); return $page->editable(); }); One thing to mention is that you can apply these filters BEFORE or AFTER closures have been applied. If you apply them BEFORE executing the closures it might be a little more performant (because closures will not be executed for rows that have been removed by the filter), but you will not have access to columns that are populated via closures (like page path).

Sure, I'm not talking about giving public users access to SQL but executing the query directly via SQL (and not via some php code like regular $pages->find() operations do). Don't know how GraphQL works in this regard. That's what I was interested in. Because it would also be possible to use RockFinder as some kind of service endpoint quite easily: I guess I need to try GraphQL and hope to find some time for that soon...

True ? don't know about the benefits of using graphql over direct SQL (that's what RockFinder does) though, but would be happy to hear.

And you can use RockFinder as the probably most efficient way.

Hi @phoros and welcome to the forum, interesting read! Would be interested what your concerns have been. I love PW for many reasons, but I've also come across situations where I wished there was some kind of content-builder to give editors more flexibility than just different fields (where PW is awesome). There are several approaches for that already and I've built something like this several times already, but it still does not feel right, because you always have to start from scratch. Seeing all those fance marketing screencasts about wordpress click-click magic I got a little frustrated from time to time, because building such functionality in pw needs a lot of time and effort - which means lots of costs and a disadvantage in terms of business. So I'd be happy to hear some more details about the problems that gutenberg brings in. Thx

If you are developing modules I'd recommend changing .module to .module.php so every ide from every user will recognize it ?

Thx @MoritzLost! Could you please explain the benefit of using composer compared to packing things into a pw module?