bernhard

No, conditional hooks are great. I just tried to show that this: Pages(template=foo)::saved is wrong and this is the correct version: Pages::saved(template=foo) See https://processwire.com/talk/topic/18037-2-date-fields-how-to-ensure-the-second-date-is-higher/#comment-158164 and

Hey @ryan and others! Playing around with TinyMCE again as it is really a great editor! I wonder how I can make it to only allow bold and nothing else? --- update --- This works visually: { "menubar": false, "toolbar": "bold", "toolbar_sticky": false, "quickbars_selection_toolbar": "bold", "quickbars_insert_toolbar": "bold" } --- /update --- At first I thought it works because the toolbar shows only the "B" button, but the quickbars plugin shows too much options! Another thing that I noticed: I opened the devtools and changed <p>Das ist ein Test</p> to <h1>Das ist ein Test</h1> and after save it was still an <h1> which is... less than ideal. Does anybody know how I can prevent that from happening and how I can disallow everything but "B" in the quickbar?

Damn, I thought about gradient backgrounds the other day but totally forgot that today ? I've implemented the color blocks with SVG so I can't simply support gradients at the moment, but using DIV instead it will work: I'll refactor and add that tomorrow the other day! Then we have another distinction to other colorpickers ? ?

Yes, and to define them in code (which is a lot easier for automated deployments) and to get rid of any external JS library just for selecting a single color. That's exactly the use that I built it for ? Before: After: Not sure if there is any benefit here compared to creating two fields? What would be the exact use case?

Happy new year everyone! New year, new module 🙂 A super simple color picker for the ProcessWire backend that can not only pick colors but also custom HTML (so you can use it for picking gradients, for example). Docs and Download: https://www.baumrock.com/en/processwire/modules/rockcolorpicker/

I guess they are able to trash pages but just don't see the trash button on the page list? Modules > Core > ProcessPageList > Check the checkbox to allow non-superusers to use the trash button from the pagelist

Congrats for your first module! ? That license thing really sucks... in theory - wouldn't then also using ProCache violate their terms?? How many API requests per month are free, do you know that or have an estimate? 200$ every month... but what does that mean in terms of pageviews or api requests. Also that means that the pageload will drastically increase, no? Unless you use ProCache (which would be against their terms) or you use a JS-based solution that loads reviews after page load.

If you know what to do SSE is quite easy to implement and a great option. See https://processwire.com/talk/topic/26663-need-help-making-sse-work/ Though I wonder what that means from a performance / scalability point? What if we had 100 users viewing the website. With SSE that would mean 100 SSE streams. With polling that would mean 100 requests every X seconds. Does anybody have an idea (or resources) what is easier for the server to handle? How can I test that? It's a blackbox for me at the moment ?

I'd check if she is able to copy/paste here: https://www.tiny.cloud/docs/demo/full-featured/

Today I had to renew the certificate. Unfortunately that can't be done automatically as the challenge relies on DNS records that have to be created. But it's not a lot of work and only has to be done every 3 months, so it's fine. When renewing the cert I realised that the CA Authority was not properly setup. Now with the new cert everything is green and I get the correct status-code ? Thx for your help!

You can do the same in PW. You just don't get the page editor and have to build a GUI for editing that table on your own. Why not? Maybe you are just missing a tabular view like shown here? https://processwire.com/talk/topic/26663-need-help-making-sse-work/?do=findComment&comment=220918 For me: Not really ? Those things are always really hard to understand if you are not into the topic. So for me it would help a lot to get more details or specific examples. Or to get screenshots of how it is done at the moment. But I'm quite sure there's no easy peasy answer to your questions as it is a complex case ?

Yes, please! That's what I've been saying for a long time... Yes, please! That's the part that made me move away from AOS. I'm very happy without it btw - it hurt a little in the beginning but I'm not missing anything any more. For field/template edit links we have the great https://processwire.com/talk/topic/26537-adminhelperlinks-shortcut-links-to-edit-fields-and-template-directly-from-page-edit/ that has not caused a single issue in all of my pw instances. AOS on the other hand has cost me hours in finding bugs in my modules that turned out to be bugs in AOS. RockMigrations has the concept of "tweaks" where we can add micro-modules via single php files (https://github.com/baumrock/RockMigrations/tree/main/tweaks) and enable/disable them via GUI in the module's settings: Agreed, but don't forget that some features also need several hooks in place, so we need a combination of PHP/CSS/JS. I've also built https://github.com/baumrock/RockAdminTweaks some time ago which had the idea of making it possible to have all those little tweaks organised in a modular and manageable way. I don't see any reason why we would need support for 3 admin themes that all do the same and just look a little different. We have now the possibility to create custom styles of the backend without the need of creating a new theme (see https://github.com/baumrock/AdminStyleRock#wording-theme-vs-style ) I disagree ? Why do you think that or what exactly do you mean? But it's a little offtopic so if it's not easy to answer just ignore it. I agree ? Thx for making the list @dotnetic and pushing that topic forward!

That has two reasons: SEO --> bots that do not understand JS will see the plain old paginated site (so every content is accessible) efficiency --> ProcessWire already does the pagination out of the box, so I'd build on that rather than implementing my own logic

Interesting read: https://www.nngroup.com/articles/infinite-scrolling-tips/

I'd start with what we all love PW for: The API. So I'd ask myself: What would I want it to work (without thinking about the consequences and the work that has to be done to make it work like that). And I'd probably come up with something like this: $newspages = $pages->find("template=newsitem, limit=12"); foreach($newspages as $p) ... echo $newspages->renderPager(); echo $infiniteScroll->renderTag(); To make that work you'd need an $infiniteScroll module with a renderTag() method. That method would render a JS <script> tag that finds the previous sibling (https://gomakethings.com/how-to-get-the-next-and-previous-siblings-of-an-element-with-vanilla-js/#an-example) and detects what page we are on and once the script tag comes into view which next page it should request via ajax and inject into the DOM. Then you'd only have to add the InfiniteScroll.js file to your <head> and maybe make the renderTag() configurable (like how many pages should be loaded before showing a "load more" button or to make the "load more" button markup configurable as well: echo $infiniteScroll->renderTag([ 'pages' => 3, // auto-load 3 pages, then show the load-more button 'button' => "<button class='uk-button uk-button-small'>load more</button>" ]); That would be how I'd like to have it work. But I have to admit that I've never built an infinite scroll so I might be missing something obvious or important ? Good luck and have fun ?

What about this: I (Stefanowitsch) will create a cronjob module that fetches new reviews maybe once a week so hat you don't need to do an API request every single time someone visits the page. ??

I'd have to look into your issue in detail but as a quick solution (maybe neither the best nor the most beautiful ? ) have you thought of just replacing the whole markup with the desired one instead of appending something? Should be quite easy to do and should not really hurt I guess.

@thetuningspoon magicpages are super cool ? the only drawback is that they come with a small performance penalty as I need to load all available templates once on init and then attach the hooks or magic methods on applicable templates: https://github.com/baumrock/RockMigrations/blob/87541c899901f773bf62068a639f070f48a85453/MagicPages.module.php#L43-L51 The init() and ready() method (and the magic methods) are only called once for every template because I create one runtime page for each template on ProcessWire::init The magic methods on the other hand only trigger for the correct pageclass because I have an early exit in the hook if the pageclass does not match: https://github.com/baumrock/RockMigrations/blob/87541c899901f773bf62068a639f070f48a85453/MagicPages.module.php#L113-L119 You might also like this:

@thetuningspoon definitely a possible solution. Just wondering if you know about https://www.youtube.com/watch?v=eBOB8dZvRN4&t=517s and if so why you don't like/use that approach?

Congrats ? This should be possible like this: $website = $rm->createPage('Website', 'website', 'basic-page', 'home'); I wonder if it could make sense to have all these migration files in one single folder, eg /site/assets/RockMigrationsConfig/ This could then be called with a single $rm->migrateConfig("/site/assets/RockMigrationsConfig") call. It could take care of creating all fields and template first and then run the migrations that set all settings. Your code could then become something like this: //Modules $rm->installModule( "FieldtypeLeafletMapMarker", "https://github.com/madebymats/FieldtypeLeafletMapMarker/archive/PW3.zip" ); $rm->migrateConfig("/site/assets/RockMigrationsConfig"); $website = $rm->createPage('Website', 'website', 'basic-page', 'home'); $rm->createPage('Past Shows', 'past-shows', 'pastShows', $website); $rm->createPage('About Us', 'about-us', 'basic-page', $website); $rm->createPage('Contact', 'contact', 'location', $website); What do you think?

Hey @Kiwi Chris thx for your input, that's an interesting idea! I've often thought about how we could do something similar. The problem is to define what should happen automatically and what manually. The distinction is the key. Sometimes it might be good to have things happen automatically, sometimes the opposite would be preferable. That's why it's 100% manual at the moment. Defining a path to save the code could be an option I guess. The storage/save portion of the problem is trivial. Instead of showing the code in the backend we could easily store it somewhere. But how would you suggest using that file then? Copy&pasting code is easy: $rm->createField('foo', 'text', [ 'label' => 'my foo field', ]); How would that look like when having a code file? $rm->createField('foo', '/site/modules/MyModule/RockMigrations/fields/foo.json'); While that looks good on first sight I'm not sure it will really work. Maybe it could work for fields, but for templates it might not: $rm->createTemplate('foo', '/site/modules/MyModule/RockMigrations/templates/foo.json'); What if that file had a reference to a field that does not exist? One would have to make sure that this field exists before the createTemplate is called. Clear what I mean? When writing migrations manually these problems are likely less of an issue (I guess), because while writing that migrations code you should already realise if you are referring to something that is not yet created. I've also thought about a solution that copies all field and template setups to a dedicated place (like /site/assets/RockMigrations/fields/... or /templates/... ) and on migrate() it first creates all those fields and templates and then does another run that actually applies all settings. That's what the migrate() method does behind the scenes. Maybe it helps if you provide a very detailed step by step use case / workflow how you think that concept could work and how you think we could solve the problem of non-existing references.

Hey @ryan I've managed to find a way to get a minimal tinymce field using this very simple json: { "menubar": false, "toolbar": "bold", "toolbar_sticky": true } Result: This is very nice and what I want! The problem: I need to set the JSON globally for ALL tinymce fields: Would it be possible to add an option to set the defaults.json file on a field level? This would be extremely helpful (necessary) for module development where one wants to ship fields with a custom set of options. It's also a lot easier to create fields where the settings are defined in code (GIT!) rather than via gui. Another benefit would be that the core (or a module) could ship different versions of defaults (eg minimal.json, simple.json, default.json) that a field could use and extend on them rather than on global defaults. Thx!

I'm testing TinyMCE and it looks absolutely brilliant! I'll report my findings as they occur ? @ryan it seems you are still not on PHP8? Could you please have a look at DDEV for local development? Using DDEV you can simply switch PHP and DB versions and do "ddev restart". It's such a great tool, it has saved me so much time and headache since I installed it on my laptop one year ago! I've not had a single situation that ddev wasn't able to handle. Want to setup a new project? "ddev config" is all you need to do! You want to test something that sends emails? DDEV has mailhog on board and you can simply launch it via "ddev launch -m" You want to have local dev using HTTPS? ddev creates certificates for you! You want to create JPGs from PDFs on page save? You can add poppler-utils to your web-container config and have the same environment as on the remote server. You can even share your projects with clients using ngrok. You can share your project on the local network to test it on mobile devices. Want to import a db dump? You can import it simply by doing "ddev import-db -f site/assets/backups/database/db.sql".

Great stuff Ryan! Maybe you want to link to this blog post on the module's readme? https://processwire.com/modules/inputfield-tiny-mce/ OK I'm through the post and there's lots of great informations in it! Thx a lot! I'm wondering if there is an easy way of making a field have a minimal setup? The default.json with its merge features looks great for regular text fields. But what I often need is to have text fields that only allow the user to add two things: add line breaks and make some words bold. That's useful for my page builder where I have blocks for a very specific purpose (like inserting a multiline headline). Is there an easy way to setup such a field without having to manually remove all defaults? Another thing: really great stuff with the css styling feature!! What I wondered here is how we could add multilingual labels for our editor styles? Maybe something like this? (sorry on mobile) /* en = Red paragraph */ /* de = Roter Absatz /*

Hi @Kiwi Chris I've added a config setting to prevent migrations if you don't want them to be triggered automatically: $config->noMigrate = true; https://github.com/baumrock/RockMigrations/#running-migrations For adding this setting only to your local dev setup see https://processwire.com/talk/topic/18719-maintain-separate-configs-for-livedev-like-a-boss/