Leaderboard

@bernhard YAML is preferable because it's declarative instead of imperative. This has a couple of side-benefits, like cleaner diff views in git, no formatting issues or different styles and no 'noise' in your commits (all only relevant if you have a git-based workflow with pull requests). But the big thing is that it makes it impossible to create environment-specific configuration, which is exactly what you don't want. If you embrace that the configuration is the source of truth for the entire site state (excluding content), you won't need this anyway. Take your example where you switch a field based on whether the languages module is installed - I would flag this in a PR and consider it an antipattern. Whether a site is multi-language or not should be part of the configuration. If it isn't there's no way to guarantee that the code which works in staging will also work in production, so at that point you're doing all the work for controlled deployments and version control but not getting the benefits. Another downside of PHP is that it's onedirectional by default. With YAML, if a deployment fails, you can just roll back to the earlier version and apply the configuration of that version. With PHP, this may work if the PHP migration is just one single $rm->migrate call with an array of configuration (so basically it is a declarative config). But you have no guarantees that it will, and if you have any logic in your migration that depends on the previous state of the site to migrate to a new state, this migration is irreversible. Migrations do have their place - if you really need to perform some logic, like moving content from one field or format to another. But besides that, declarative configuration files are preferable.

yeeha!! ? <?php /** * Center Buttons * @return Buttons */ public function getButtonsCenter() { $buttons = parent::getButtonsCenter(); $buttons->add([ 'name' => 'markClaimed', 'icon' => 'check', 'tooltip' => 'Mark selected items as claimed', 'hidden' => '!selected', 'appendMarkup' => '<div id=markClaimedConfirm hidden>...</div>', 'callback' => [ 'name' => 'sendIDs', 'confirmmarkup' => '#markClaimedConfirm', 'loading' => 'Saving items...', 'reload' => true, 'execute' => function($input, self $grid) { $ids = $this->wire->sanitizer->intArray($input->ids); $note = $this->wire->sanitizer->text($input->note); foreach($this->wire->pages->findMany(["id" => $ids]) as $p) { $p->setAndSave(Effort::field_claimed, 1); $p->setAndSave(Effort::field_claimedwith, $note); $grid->sse("Saved page $p"); sleep(1); // just for the screencast } $grid->sseDone(); return ['success' => true]; }, ], ]); return $buttons; }

A user in another forum found a solution!!! <?php header("Cache-Control: no-cache"); header("Content-Type: text/event-stream"); $i = 0; while(true) { $i++; echo "data: value of i = $i\n\n"; echo str_pad('',8186)."\n"; flush(); if(connection_aborted()) break; sleep(1); } Reading the manual about flush() finally broucht me to the correct settings for my setup: <?php header("Cache-Control: no-cache"); header("Content-Type: text/event-stream"); @apache_setenv('no-gzip', 1); @ini_set('zlib.output_compression', 0); @ini_set('implicit_flush', 1); ob_implicit_flush(1); $i = 0; while(true) { $i++; echo "data: value of i = $i\n\n"; flush(); if(connection_aborted()) break; sleep(1); } I've tried several settings before regarding gzip, but nothing worked. For me the ob_implicit_flush(1) made the difference ? https://www.php.net/manual/de/function.flush.php

Hi @alexm. Pete is currently helping me with this. Hopefully this week, we'll have a 'pre-sales' forum that anyone can access. We'll use that for issues, wish list, etc. Ideally, we could have done issues in GitHub but Padloper is not an open project. Both pagination and lazy-loading have not yet been implemented. They are high on my todo list, especially the latter.

@kongondo where is best to submit a list of things I find. These aren't necessary issues, so didn't know if you want them submitted to Github as that's the frontend shop. One I have in mind is that I have a product with 711 variations (ridics I know) and I know we've discussed this before with your Variations module, which is integrated into Padloper 2 in a new form. But i'm wondering if you kept the pagination feature as my variations all show as one huge list.

Thanks @Guy Incognito I have merged your PR. I have switched to using SeoMaestro, but to be honest I am not particularly happy with either of these modules - both have their issues for my way of working / thinking. It will be interesting to see what RockSEO brings to the table.

Well hello, today is the day I would like to introduce Flowti, my biggest Project I have worked on for the last 2 1/2 Years and the reason I am developing Symprowire, too. So, what is it all about you may ask. Flowti is my daily driver to Plan, Document and Execute Projects Flowti is my tool to work on concepts and ideas Flowti is my tool to present Work Flowti is my tool to organize and support Product Management Work Flowti is my digitalization Framework To give you a glimpse about what Flowti is already capable of I attached some screenshots for you to study ? To make this one short, I plan to fully Open Source Flowti this year after Symprowire reaches v1.0 and will use this post as a way to show progress. Cheers, Luis

I came to this thread by coincidence: It was very popular back then. But I've never heard of anybody using dynamic roles over the last few years. Is anybody using it and want to share the "why" and "how"? ?

Ok I did some more testing and found out that using str_pad is the most reliable solution. At least in the environments I tested (laragon, DDEV, ubuntu+apache). So I can't say anything about ob_implicit_flush()

You're misquoting me, @bernhard :) Could you try this... <script> var evtSource = new EventSource("sse.php") evtSource.addEventListener('ping', function(event) { var data = JSON.parse(event.data) console.log(data) }, false) </script>

Sounds good - I might actually be tempted to go back to this module - I do prefer the inheritance flexibility of it.

Thanks ?. I will check out RockSEO. The thing that has kept us on MarkupSEO to date is the simplicity for implementation and also for clients. Combined with the changes you’ve made previously it’s pretty effective at doing what it needs to. I’ll have a think if there’s anything else that can be done to improve it further.

Hi all, Not sure if if everyone has jumped to SeoMaestro these days but I'm still fond of MarkupSeo and it's still live in many of our sites so I've made a few small but important tweaks based on real world usage. @adrian I've just made a pull request with these changes to your fixes branch in case others find these changes useful: Stopped canonical links from being able to inherit from parent pages: Inherited canonical links could cause problems with search engine indexing whereby you're inadvertently telling Google your new page is the same as another purely because you (or a client) missed the canonical field. So I think it is better for the default to be current page URL if the field is left blank rather than inherit the parent. Implemented handling of relative URLs in the canonical field: You can now use relative URLs in the canonical field for internal links. They will still render on the front end as SEO-friendly absolute URLs, but this way it is easier if you use different domains for testing or if you need to change the site domain. (https://github.com/mrjcgoodwin/MarkupSEO/tree/various-fixes-enhancements)

fwiw, I often use Google search like this: $field->attr site:.processwire.com i.e. https://www.google.ch/search?q=%24field-%3Eattr+site%3A.processwire.com&oq=%24field-%3Eattr+site%3A.processwire.com

Depending on your needs...http://kongondo.github.io/ProcessWireAPIGen/ E.g. method attr()

Not necessarily the answer you are looking for, but searching on Github is often very enlightening: https://github.com/ryancramerdesign/ProcessWire/search?utf8=%E2%9C%93&q=%22%24field-%3Eattr%22

roles.on speed u sholud.call it adderole