bernhard

PS Maybe you can share more details about this here or in the pub? It's always good to know the competition and to know what problems client might face if they want to use WordPress... PPS: I tried to edit my post but the forum software decided to create a new one, sorry ?

I've had a similar issue and for me it was the problem that the endpoint was not reachable. The reason was that I moved the fluency page in the admin from the top level down into the setup tab. You can try to inspect the network tab of your devtools and see what response you get from the fluency api request. It should be JSON - for me it was HTML. I've talked to @FireWire about changing his implementation to url hooks to prevent this issue. Maybe it's something similar for you. Maybe you moved the page as well or maybe you have any other redirects going on from some hooks?

Thx for your interest. I'm sorry that it takes longer than expected. The module is ready to be used and it has been developed for something around 3 years. It works great and I think it is a great tool for developing websites. Anybody interested doesn't need to wait and can send me a PM and buy a copy right away. Unfortunately we don't have any infrastructure for selling commercial modules. So anybody who wants to sell modules needs to build one on its own. That is not trivial and takes time. And unfortunately there are other things that kick in from time to time (client work and life...). I do my best to release it soon ?

I just tried and everything seems to work as expected if you set the correct import path (see docs https://scssphp.github.io/scssphp/docs/ ). I've added an example to the readme. <?php // for development you can put this in site/ready.php /** @var Scss $scss */ $scss = $this->wire->modules->get('Scss'); // watch all files in /site/templates/scss $watchFiles = $files->find( $config->paths->templates . "scss", ['extensions' => 'scss'] ); // set the import path so that relative @import statements work $scss->compiler()->setImportPaths($config->paths->templates); // compile SCSS to CSS if any of the watched files changed $scss->compileIfChanged( // create this file with the content from the uikit docs: // https://getuikit.com/docs/sass#how-to-build input: $config->paths->templates . "scss/uikit.scss", watch: $watchFiles, output: $config->paths->templates . "scss/uikit.css", style: 'compressed', );

Why didn't you use the new methods that I implemented for you? Did anything not work?

What if you just add some code at the bottom of _main.php and check for the page id there? <?php if($page->id === 27) $site->track404(); ?> If Jumplinks kicks in, that should happen earlier I guess, so it should only track real 404 impressions?

Thx @wbmnfktr I'm limited to what the newsletter company provides I guess... I can use another editor, like this one: Would that be better to read?

Nice, thx for clarifying ? Yeah, looks like using the API is for free unless you hit any of their limits, which is really awesome with your awesome module!!

Just sent out the October Newsletter and at the moment we're holding at 49 subscribers, one being myself ? and basically stagnating since last month (+1). Not sure if the newsletter is helpful for anybody, but I try my best to provide interesting content. Here are some numbers from the first two issues: If anybody has some ideas, feedback or other input feel free ? The first two issues were basically written by ChatGPT with some minor manual tweaks. The input came from a RockShell script that scans all my repos and then creates a log and lists all commits. ChatGPT did a quite good job in converting these into some nice sentences. This months version I decided to put more manual work into it. There have been less commits and so it was possible to give it a more personal touch. Have a great month! PS: It's not too late ? https://www.baumrock.com/rock-monthly/ ?

It's already on the dev branch - could you please check if everything works for you? https://github.com/baumrock/RockMigrations/commit/a4b9be86fb321fd621661250b23b1f361a379a5c

Hey @FireWire, thanks for the fabulous update! I have a question regarding DeepL... I don't understand their pricing! For my website I think I'm fine with my free developer API account. I've translated several blocks of content and I've used only 1% of my limit. That's really great and has saved me so much time! That feature would be great for so many multilingual websites so I'm thinking about how I could sell that to clients. What plan would I need then? Would I let them use my developer key? Or would they need to register their own account? They would not be allowed to use the free dev plan I guess, so what would be the correct plan? There's only one for a single person starting from 9€ per Month, which is not so cheap. Especially for websites where you don't have lots of changes... Thx for your help (or anybody else who has an answer)!

There has been a lot of discussion here ? https://processwire.com/talk/topic/26792-headless-processwire-how-do-you-do-it/ I think this should work: /get-images(/{page})?(/{field})?/ ?

He made the PR but I was not able to merge it yet ?

Just had a look at the code and some cleanup would be nice for sure (though not necessary imho). How would that work? For example the method "addFieldToTemplate(...)". How would I move that method to another file without changing the api? I know it would be possible to add that method to $rockmigrations via API addHookMethod, but that makes it a lot more complicated to develop and to also support proper intellisense. Also I guess it would have more overhead.

Ah, I always read ProfileUtilities instead of ProfieldsUtilities ? Well anybody could just develop his/her own module based on RM Just create an autoload module that requires RockMigrations, then in the init() method one could do this: public function init() { $this->wire->rockmigrations->fooPlugin = $this; } And then anybody could use that plugin like this: $rockmigrations->fooPlugin->doSomething(); But I'm not sure how useful that would be compared to calling the module directly: $foo = $modules->get('fooPlugin'); $foo->doSomthing(); I know that feature, but I just don't know what benefits you are thinking of..

Hi Ivan, I really appreciate your input and I'm very happy to see your interest in RM growing. Though I have some concerns about your suggestion. Not saying that are bad suggestions, I just try to be realistic. First of all: I'm really, really happy with RM and how it works right now. There has been a lot of refactoring from RM1 to RM2 and that has brought a lot of improvements to the module. The API is in my opinion quite easy and stable to use and the concepts have proven to be working. Second: It's a free module. I think it's one of the best and most powerful modules out there for PW and it can bring a HUGE value to your everyday work, especially if you work in a team or want or need more professional workflows with zero-downtime deployments on multiple environments etc.; I decided to release it for free, because I think this should be part of the core. It should be something that every developer can use to create great modules. To use it as a foundation for, eg quickly and easily create a blog module that creates all the necessary fields and templates that you get a one-click blog setup for ProcessWire. That's simply not possible to do with site profiles and it's simply a pain to do with the regular API. Unfortunately that did not happen. Quite the contrary. People complained about it being too complicated (and didn't even use the module once). And no one ever used RM to create something useful for the community as far as I know. I'm not complaining - it is like it is, but that's the context for the question you are asking. That said, back to topic: I've been talking with @gebeer about refactoring quite some time ago: --bernhard-- In the long term, however, I thought it might make sense to split the API. Similar to how the wire core is split into its own classes. $rockmigration->fields->create('foofield'); $rockmigration->templates->addField('foofield', 'bartemplate', afterfield: 'title'); $rockmigration->migrate([ ... ]); That would really be a completely different API... That means a mega breaking change. I don't know if it's worth it...... --gebeer-- In the long run it's not wrong because it brings more structure into the API. But I think the API is well usable as it is. But I'm still not sure if it would be better. I really like the simple API that is accessible via $rm: Also splitting the API brings in other problems. Many methods do something with two things, eg "addFieldToTemplate" - would that be $rm->fields->addToTemplate("myfield", "mytemplate") or would that be $rm->templates->addField("mytemplate", "myfield") ? I don't understand ? If you have specific ideas I'd be more than happy to hear them and think about how we can improve the module and/or the code quality.

Yes ? The module is done and ready for production. Just the infrastructure to sell it is not, as we unfortunately have no dedicated place to sell commercial 3rd party modules in the PW ecosystem ? If you are interested just send me a PM and you'll get a horrible and outdated preview video ?

Your error message tells something different ? That means that the module tries to write to css/style.css which is obviously not a correct file path. This means that your IDE complains about the syntax, which could mean that your IDE uses a different PHP version than your project. If your IDE uses something like PHP7.4 then it will check your code with that interpreter and complain about PHP8 syntax. That does not mean that the code will not run though. But obviously it's something that's not ideal.

you didn't provide the full path as I showed you in the comment above

Should be this: $scss->compileIfChanged( input: $config->paths->templates . "scss/style.scss", watch: $watchFiles, output: '/path/to/css/style.css', // use path and add comma at the end style: 'compressed', // optional but recommended comma at the end );

You need PHP version 8+ I've updated the module with that requirement.

I didn't test includes or imports. As I've never worked with SCSS and LESS has always just worked for me I'd need input from others to make it work. I don't see a reason why RockFrontend should not also support SCSS. It would need some more work though than what I quickly did for this module on Tuesday, so it's not really a top priority ?

Hi @jeremie I'm always happy to help. If you don't know me you can get an idea at processwire.rocks and you can schedule a meeting at https://cal.com/baumrock/meet and then we'll do a 1:1 video meeting with screenshare in english or german ?

Hey Robin, thx for the tutorial! I just wanted to mention here, if anybody is reading this and looking for a solution, that RockMigrations has both features on board, as that is a very common need when working with PW from code. Page IDs can not be copied like in your example, but they can be shown in the page tree. Maybe I should change that. I like your solution. But on the other hand sometimes it's nice to just see the ID and with your solution you'd have to paste it somewhere just to see the id. On the other hand my solution pollutes the page tree. Maybe a combination would be ideal - a page tree that shows IDs on shift or alt or something and copies the ID on click. This is the very simple tweak that adds page ids to the page tree in RockMigrations: https://github.com/baumrock/RockMigrations/blob/main/tweaks/PageListShowIds.php Regarding the field names - in RockMigrations I had the problem that I not only needed the field's name but also it's possible values. Sometimes that's not as easy as just a 0/1. Sometimes there are string values or sometimes it is -1. I came up with adding a tooltip that shows the field name on hover plus the value of the hovered input element:

Don't forget that, when working with RockMigrations, you can still solve problems without RockMigrations ? So you have all the PW magic available, that means you could for example just use $files->copy() to copy files, or you could use exec("cp -r /foo /bar"); That all depends on your system and situation. RockMigrations just helps with an easy API for all the things that usually have to be done manually in the PW backend.