Jump to content

bernhard

Members
 View Profile  See their activity

  • Posts

    6,314

  • Joined

  • Last visited

  • Days Won

    318

 Content Type 

Everything posted by bernhard

  1. bernhard
    Thx @netcarver sorry I've quoted @kongondo and linked you in the same sentence ? http://sse.baumrock.com/sse2.html --> the event is received every 10s which is wrong as far as I understood how SSE should work. I'd expect a console.log() happen each second and have one open stream as long as I click on "close the connection"
  2. bernhard
    Hi community, last week I've tried to get PHP SSE working. Unfortunately without success. When using laragon it works, but on my DDEV setup and also on my live server it does not. I think there is some kind of compression and/or proxying going on, but I don't know how to debug or disable that. @kongondo and @netcarver have mentioned SSE is "is so simple it is unbelievable at first." Maybe you can help me? This is what I've tried: <?php header("Cache-Control: no-cache"); header("Content-Type: text/event-stream"); $i = 0; while(++$i<=10) { echo "event: ping\n"; $curDate = date(DATE_ISO8601); echo 'data: {"time": "' . $curDate . '"}'; echo "\n\n"; file_put_contents(__DIR__."/dump.txt", "triggered@$curDate\n", FILE_APPEND); ob_end_flush(); flush(); if ( connection_aborted() ) break; sleep(1); } <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <meta http-equiv="X-UA-Compatible" content="IE=edge"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>Document</title> </head> <body> <script> const evtSource = new EventSource("sse.php", { withCredentials: true } ); evtSource.onmessage = function(event) { console.log(event.data); } </script> </body> </html> The file_put_contents works as expected, just the javascript does not get the messages from SSE: The eventstream is sent after 10 seconds at once and not on each event: Then the request is sent again and the same process starts from the beginning... You can try the example here: http://sse.baumrock.com/sse.html I'd be very happy if anybody could help me making this work ?
  3. bernhard
    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"? ?
  4. bernhard
    You might want to add an additional if($page->template != 'your-pagereference-template') return; inside the hook if you do not want to set all languages active globally on the site...
  5. bernhard
    Does it work if you place this hook in site/ready.php? <?php // set all languages active automatically $wire->addHookAfter('Pages::added', function($event) { $page = $event->arguments(0); foreach($this->wire->languages as $lang) { if($lang->isDefault()) continue; $page->set("status$lang", 1); } $page->save(); });
  6. bernhard
    Thx for that example. I understand now. <?php // migrate field content only if the address field exists if($rm->fields->get('address')) { // first we make sure the fields exist $rm->createField('foo', 'text'); $rm->createField('bar', 'text'); $rm->createField('baz', 'text'); // then we make sure they are added to xyz template $rm->addFieldsToTemplates(['foo','bar','baz'], 'xyz'); // then we migrate data foreach($pages->find('template=xyz,address!=') as $p) { $parts = ...; // split address into parts $p->of(false); $p->foo = $parts[0]; $p->bar = $parts[1]; $p->baz = $parts[2]; $p->save(); } // then we delete the obsolete field $rm->deleteField('address'); } // then we use the existing migration config for future use // so you can easily add other stuff (like whatsoever field) $rm->migrate([ 'fields' => [ 'foo' => [...], 'bar' => [...], 'baz' => [...], 'whatsoever' => [...], ], 'templates' => [ 'xyz' => [ 'fields' => ['foo', 'bar', 'baz'], ], 'whatsoever' => [ 'fields' => ['whatsoever'], ], ], ]); If you are inside a module that uses a migrate() method to migrate data this could easily been refactored to this: <?php class MyModule ... { public function migrate() { $rm = $this->wire->modules->get('RockMigrations'); $this->migrateAddressData(); $rm->migrate([ 'fields' => [ 'foo' => [...], 'bar' => [...], 'baz' => [...], 'whatsoever' => [...], ], 'templates' => [ 'xyz' => [ 'fields' => ['foo', 'bar', 'baz'], ], 'whatsoever' => [ 'fields' => ['whatsoever'], ], ], ]); } public function migrateAddressData() { // if the address field does not exist any more // we can exit early as we have nothing to do if(!$rm->fields->get('address')) return; // first we make sure the fields exist $rm->createField('foo', 'text'); $rm->createField('bar', 'text'); $rm->createField('baz', 'text'); // then we make sure they are added to xyz template $rm->addFieldsToTemplates(['foo','bar','baz'], 'xyz'); // then we migrate data foreach($pages->find('template=xyz,address!=') as $p) { $parts = ...; // split address into parts $p->of(false); $p->foo = $parts[0]; $p->bar = $parts[1]; $p->baz = $parts[2]; $p->save(); } // then we delete the obsolete field $rm->deleteField('address'); } } This is one of the situations that are not possible using YAML of course ? But the "migrateAddressData" could be done in PHP while the migrate() could migrate YAML data still.
  7. bernhard
    Exactly. It's even named like this: migrate($config) https://github.com/BernhardBaumrock/RockMigrations/blob/db4d300b4369863d41003f5c668b7ecaf2f19b5d/RockMigrations.module.php#L2693 Sorry, I don't understand. Note that I have no experience with multiplier fields. Maybe you can give me another example?
  8. bernhard
    Migration 21-11 (add foo field) <?php $rm->migrate([ 'fields' => [ 'foo' => [...], ], 'templates' => [ 'xyz' => [ 'fields' => ['foo'], ], ], ]); Migration 21-12 (add bar field) <?php $rm->migrate([ 'fields' => [ 'foo' => [...], 'bar' => [...], ], 'templates' => [ 'xyz' => [ 'fields' => ['foo', 'bar'], ], ], ]); Migration 22-01 (add baz field) <?php $rm->migrate([ 'fields' => [ 'foo' => [...], 'bar' => [...], 'baz' => [...], ], 'templates' => [ 'xyz' => [ 'fields' => ['foo', 'bar', 'baz'], ], ], ]); RockMigrations works in a way that no matter how often you run the migration the config will be applied and the system will result in the same config each time. I know this is a totally different concept than you are using in your migrations module but it has turned out to be extremely easy to use and it works well. In the example above it does not matter if you jump from 21-11 to 21-12 and then to 22-01 or if you go directly from 21-11 to 22-01. Or you could even start with 22-01 and nothing else before. That's easy as long as you add things to the system. Removing things is a little different, but it's also easy: 22-02 (remove baz field) <?php $rm->removeField('baz'); $rm->migrate([ 'fields' => [ 'foo' => [...], 'bar' => [...], ], 'templates' => [ 'xyz' => [ 'fields' => ['foo', 'bar'], ], ], ]); Reverting things it a totally different topic! 22-01 --> 21-11 would not really be possible using RockMigrations. Though you can think of 22-02 as a "revert migration" that does exactly what a reversion would do. But if one does not like that concept they could also use RockMigrations in a way your module works. In my experience this makes migrations just a lot more complex while adding things into a php array is cake. I've never had any problems over the last few years with my concept ?
  9. bernhard
    thx! I'm thinking about it. But I think not to the current version. RockMigrations has evolved over the last years and it's time to refactor and clean up and that would be a good opportunity. What I'd like to know of you guys is why everybody seems to be so excited about YAML? Is it about the YAML thing or is it about the recorder? I'm asking because YAML would really be a drawback IMHO. What I think would be much better is to have a regular PHP file that returns a simple array. That's almost the same as a YAML file but you can do additional things if you want or need. See this example: <?php namespace ProcessWire; /** @var RockMigrations $rm */ return [ 'fields' => [ 'foo' => [ 'type' => $wire->languages ? 'textlanguage' : 'text', ], ], 'templates' => [ 'demo' => [ 'tags' => RockMails::tags, 'fields-' => [ 'title', 'foo', ], ], ], ]; That migration file would add a "foo" field and depending on the system make this field single or multi-language. That would be just one example which would not be possible using YAML syntax. Another thing is using class constants. Possible in PHP (see RockMails::tags in the example above), not possible in YAML. I'm really curious what it is really about, thx.
  10. bernhard
    Well that's two different dumps... one is dumping the array and one is dumping an object that has an array inside the data property! d($config->paths); d($config->paths->data); Personally I think that behaviour is good ?
  11. bernhard
    yes ? ... ps: same for d()
  12. bernhard
    Ok strange because I tested it today myself and it just worked for 110 items, so I thought it works as expected?! ?‍♂️
  13. bernhard
    did dbd() not work for you?
  14. bernhard
    --disregard--
  15. bernhard
    bdb() or barDumpBig()
  16. bernhard
    Hi and welcome to the forum / PW ? Have a look at https://processwire.com/modules/tracy-debugger/ that makes your life a lot easier!
  17. bernhard
    I think I don't agree with you here. Could you please explain that in detail? I'm not sure I understand. What you are asking for is exactly what I'm showing in the video?!
  18. bernhard
    Side note @ryan it would be nice if you could add relevant keywords to the title of new news or blog posts. This makes it easier to find information when you are searching for it weeks or months later ("weekly update 14.1." is not nearly as helpful as "weekly update find raw parents, sanitizer float" in a search result) +1 for better version control support. I've not built RockMigrations just for fun ?
  19. bernhard
    Yes, the link does not work on my DDEV environment ?
  20. bernhard
    Hi @Richard Jedlička there's one slash too much on line 134 ? PS: If it is easy to implement a "save + reload" button would be nice to have in the modal ?
  21. bernhard
    Hey @horst why is that by design? I don't understand why we should not be allowed to upload webp directly if we want to display webp afterwards?
  22. bernhard
    You need to download it first...
  23. bernhard
    Thx @rjgamer It is shipped now with the core: https://processwire.com/blog/posts/pw-3.0.179/ Or you install and use AdminStyleRock which makes it possible to select the primary color via inputfield on latest dev:
  24. bernhard
    Did a quick test:
  25. bernhard
    TracyDebugger shows all the available options, so you don't have to remember them already. But you have to write them down manually at the moment. I guess it would be possible to create that yaml file on the fly. If tracy knows all the settings and can write them to the panel I'm quite sure it is possible to write them to a yaml file as well. Maybe @adrian can tell us something about that?
×
×
  • Create New...