bernhard
-
Posts
6,251 -
Joined
-
Last visited
-
Days Won
312
Posts posted by bernhard
-
-
RockFrontend includes the HumanDates library that you can use as strftime alternative:
$rockfrontend->humandates('de_AT')->format('2025-01-01', 'd. MMMM y') // 1. Jänner 2025
-
Ok today I found out by coincidence that it shows up only when ALFRED is loaded on the page. I don't know yet why, but I'll save that note here for the time. If anyone has an idea let me know!
-
Hey @Jan Romero that's true, but it shows it in a totally different way. I wanted to have a list of all methods that I can hook into, in the order of execution! I don't know how tracy sorts the list of added hooks, but it's definitely not execution order.
On the other hand tracy debugger adds nice links to the hooks and shows some more information, like for RockFrontend:
after RockFrontend::addAlfredStyles() AdminStyleRock::addAlfredStyles() class method 100.0And that line does not show up in my hooks log:
cat hooks.txt | grep RockFrontend ProcessWire\RockFrontend::addLiveReload ProcessWire\RockFrontend::render ProcessWire\RockFrontend::loadLatte ProcessWire\RockFrontend::addLiveReload RockFrontend\StylesArray::renderAssets RockFrontend\ScriptsArray::renderAssetsOh... that actually makes sense, because I have not had an ALFRED call on that page yet, so obviously the hookable method does not get called! 😄 I added it and boom, there it is:
cat hooks.txt | grep RockFrontend ProcessWire\RockFrontend::addLiveReload ProcessWire\RockFrontend::render ProcessWire\RockFrontend::loadLatte ProcessWire\RockFrontend::getIcons ProcessWire\RockFrontend::addLiveReload ProcessWire\RockFrontend::addAlfredStyles RockFrontend\StylesArray::renderAssets RockFrontend\StylesArray::renderAssets RockFrontend\ScriptsArray::renderAssets RockFrontend\ScriptsArray::renderAssetsAnother one. I saved a page from the backend and the grep for "::save" looks like this:
cat hooks.txt | grep ::save ProcessWire\Pages::save ProcessWire\Pages::saveReady ProcessWire\Pages::savePageOrFieldReady ProcessWire\Pages::saved ProcessWire\Pages::savedPageOrFieldI think this is really neat!
Maybe @adrian has an idea how we could integrate this into Tracydebugger and maybe get the best of both worlds (tracy current implementation + my hacky one)? I think it would need a modification in the core, but that should not be a big deal for @ryan.
-
1
-
-
-
Ever wondered when certain hooks get executed? Which hooks got fired along the request?
Open /wire/core/WireHooks.php, find the method "runHooks" and paste this at the very top of this method:
$logfile = wire()->config->paths->root . 'hooks.txt'; $tooOld = is_file($logfile) && filemtime($logfile) < time() - 5; if ($tooOld) unlink($logfile); $logData = get_class($object) . "::$method\n"; file_put_contents($logfile, $logData, FILE_APPEND);
This will write a log of all hookable methods to hooks.txt and it will probably begin like this:
ProcessWire\FileCompiler::compile ProcessWire\FileCompiler::compile ProcessWire\FileCompiler::compile ProcessWire\FileCompiler::compile ProcessWire\Fields::load ProcessWire\Fieldgroups::load ProcessWire\Templates::load ProcessWire\Fieldgroup::setQuietly ProcessWire\Fieldgroup::callUnknown (maaaany more lines)And it will most likely end with "ProcessWire\ProcessWire::finished" 🙂
Now you can play around with this logfile and view different pages. For example when opening a page for editing you will have a portion of this in the log (ProcessPageEdit::buildForm...):
ProcessWire\ProcessPageEdit::breadcrumb ProcessWire\JqueryCore::use ProcessWire\JqueryUI::use ProcessWire\ProcessPageEdit::execute ProcessWire\HutPage::setEditor ProcessWire\ProcessPageEdit::buildForm ProcessWire\ProcessPageEdit::buildFormContent ProcessWire\Field::getInputfield ProcessWire\Field::getInputfield ProcessWire\Field::getInputfield ProcessWire\Field::getInputfield ProcessWire\Field::getInputfield ProcessWire\Field::getInputfield ProcessWire\Field::getInputfield ProcessWire\Field::changed ProcessWire\Field::changed ProcessWire\Field::getInputfield ProcessWire\Field::changed ProcessWire\Field::getInputfield ProcessWire\Field::getInputfield ProcessWire\Field::getInputfield ProcessWire\HutPage::viewable ProcessWire\Pages::find ProcessWire\PageFinder::find ProcessWire\PageFinder::getQuery ProcessWire\HutPage::addable ProcessWire\ProcessPageEdit::buildFormChildren ProcessWire\WireInputData::int ProcessWire\WireInputData::callUnknown ProcessWire\WireInputData::int ProcessWire\WireInputData::callUnknownYou can also use grep to find the hooks you are looking for, for example:
cat hooks.txt | grep ProcessWire:: ProcessWire\ProcessWire::init ProcessWire\ProcessWire::ready ProcessWire\ProcessWire::finished ProcessWire\ProcessWire::finishedThis has helped me today to find the correct spot to hook into. Maybe it also helps anyone else. Have fun!
PS: Don't forget to remove this once you are done with inspecting, of course!
-
3
-
1
-
-
6 minutes ago, gebeer said:
That is just a waste of time imo.
Yes and no. I have had several situations with auto-formatters where the output was not what I'd like to have, but it kept reformatting to its own wish. There was no way to change that other than turning off auto-formatting.
Latte has so many great features. I agree that it is a little pain to not have proper auto-formatting and intellisense, but I think the pro's outweigh the con's by far. But please report it to the folks of nette. You have my support and @Yipper had similar issues recently. And I think there are many others as well. Maybe we can initiate something 🙂
-
1
-
-
I also have no auto-formatter for latte + vscode, which is a shame. But I try to see that positive and take it as a reminder to keep my template files as simple as possible. Anything more complicated than $page->title is handed over to PHP where I have auto code formatting + intellisense.
-
Ok great, please change the name of this thread to "[solved] ..."
-
1
-
-
31 minutes ago, Yipper said:
'fields-' => [ // Optional: Hinzufügen von Feldern, z. B. für Farben oder Inhalte "{$this->prefix}title" => ['type' => 'text', 'label' => 'Titel'], "{$this->prefix}content" => ['type' => 'textarea', 'label' => 'Inhalt'], ],
If $this->prefix is empty you set the type of the "title" field to "text", which would explain your issue!
-
1
-
-
15 minutes ago, Yipper said:
removed the - on both logos.php and tried commenting out the whole migrate section there. strange this is, the message from above disappears, but the field is still set back to normal text field.
I'd not say it's strange. It makes sense. I just tried to confirm that the log you posted is not related to the issue you are seeing.
What I'd do:
Confirm that your change is coming from RockMigrations
- To do so check "Disable all migrations" in RockMigrations module settings.
- Then set your title field back to "textLanguage"
- Do a modules refresh, or even better run php site/modules/RockMigrations/migrate.php from the command line (you get more logs)
-
Is your title field still "textLanguage"?
-
yes --> seems like RockMigrations is the issue
- To confirm remove the tick on "Disable all migrations"
- Do a modules refresh (or run migrate.php)
-
Is the title field now "text"?
- Yes --> confirmed that RockMigrations is the issue
- No --> should not be possible IMHO
- no --> something else is changing the field type. maybe another module? or maybe some of your own code?
-
yes --> seems like RockMigrations is the issue
If you can confirm that RockMigrations is the issue you should have something like this somewhere in your codebase:
'type' => 'text', "type" => "text",
The problem is that it might exist in any variation, like "type" => 'text', with or without comma, etc.;
Let me know if you find something.
-
1
-
Hey @Yipper thx for the report!
3 minutes ago, Yipper said:Fields: Deleted field "title" data in 0 row(s) from 0 page(s) using template "rockpagebuilderblock-logos". [page-by-page] +2
This comes from the "fields-" (fields minus) key in Logos.php which tells RockMigrations to remove all fields that are not listed in the array. I'm not sure why that would cause the title field to change from textLanguage to text, though.
Can you try removing the minus and let me know how/if that changes behaviour?
-
Well... it has Pro's and Con's I guess. For example if you wanted those fields to be textarea (single Language), but then you install language support later that would mean RockMigrations will change the field's type, which might not be intended. But I guess you are right in this case that it's the more likely situation that those fields should be multilang when languages are enabled. I have updated the blocks to use the dynamic version.
-
1
-
-
Hi @Yipper thx for the info!
I have updated all example blocks like this:
public function migrate() { $rm = $this->rockmigrations(); $rm->migrate([ 'fields' => [ self::field_text => [ 'type' => 'textarea', // or textareaLanguage 'inputfieldClass' => 'InputfieldTinyMCE', ...
Will be part of the next release!
-
1
-
-
What about something like this?
$start = 0; $chunkSize = 100; $oldYear = false; while ($chunk = $pages->findIDs("sort=created,limit=$chunkSize,start=$start")) { if (count($chunk) < 1) break; $p = $pages->get($chunk[0]); $year = date('Y', $p->created); $y = $oldYear === $year ?: " ($year)" echo "#$p{$y}<br>"; $start += $chunkSize; $oldYear = $year; }
Result:
#1 (2023) #1148 #1265 ... #2269 (2024) #2395 #2496 #2598 ... -
4 hours ago, FireWire said:
@bernhard Had a chance to tinker with the module today and am really enjoying it. Outstanding work on the fast and easy front end cart system!
Glad you like it! 🙂 This was really a long way until I got there and now - finally - it feels really good and solid 🙂
5 hours ago, FireWire said:Long story short, it would be great to have a way for other people adapt payment providers without you having to type another line of code 😎
Absolutely! I just built it around mollie because I knew them already and I trust them and when I compared prices they were even a bit cheaper than Stripe. Plus being in the EU that's another bonus for me.
But I understand that Stripe (or any other service) might be preferable for others, so I'm super happy to add support for it to RockCommerce! Just write me a PM and let's do a meeting after Christmas?
-
1
-
-
Awesome! Thank you for all your great work!!
-
1
-
-
Hey @adrian thx for the great redirect info. I'm using it very often!
Would it be hard to link the "file" cell to open up the file in the configured IDE just like all the other links work?
Obviously not tremendously important but would be a lot nicer than finding the file and line in the IDE manually 🙂 Thx a lot!
-
1
-
-
Hey @Frank Vèssia thx for your questions!
19 hours ago, Frank Vèssia said:great module, I like the Alpine Front End solution.
Thx 🙂
19 hours ago, Frank Vèssia said:- any support for shipment cost with custom rules
That's already built in (or possible)! I have added this to the docs for you: https://www.baumrock.com/en/processwire/modules/rockcommerce/docs/shipping/
Does that help?
21 hours ago, Frank Vèssia said:- discount code
I've also added docs for this: https://www.baumrock.com/en/processwire/modules/rockcommerce/docs/coupons/
21 hours ago, Frank Vèssia said:- any way to retrive all abandoned carts?
I've also added a section about this to the cart docs!
21 hours ago, Frank Vèssia said:- I guess all the customer part is up to the developer, any plan to expand in this direction?
Like all the other mentioned puzzle pieces this can mean so many things. One might want to manage users via ProcessWire. One might want to sync users with a 3rd party tool. One might want to show custom dashboards to users on the frontend. One might want to show a dashboard in the PW backend...
I'm not sure how to proceed with this to be honest. RockGrid can be a great way to quickly create excel-like lists, which could also be great for managing RockCommerce users. But I'm not sure how much this would really belong to RockCommerce. It might be more related to RockGrid.
Then you might want to send out invoices. That could be done with RockPdf. But you might also want to make those invoices editable, and then RockPdf does not help you. Managing invoice items alone can be a pain. A simple solution could be to use repeaters, but you'll quickly realise that the UI is less than ideal. Prices do not update automatically, so you always need to save the page - to just name one problem.
I'd much more prefer having something like RockInvoice for that. With my initial version of RockCommerce that I'm using for my clients on my website baumrock.com has invoices built in. But then I wanted to use these invoicing capabilities also for my other clients that did not purchase modules from my store but ordered a website or website maintenance service.
So for the customer part the short answer is yes, I think I'll leave that up to the developer. The ProcessWire way... Unless anybody has good reasons and ideas to approach it differently?
But what you get out of the box when using RockCommerce is order management. At the moment this is just a list of pages in the page tree, but I plan to expand on this by adding a Dashboard that shows revenue stats and that shows a nice list (RockGrid again) of all the orders with hopefully helpful data (like who ordered, when, etc).
Any input or questions are welcome.
-
2
-
-
As of today we count 951 stars on Github. Would be great to hit 1k by the end of this year!
I'll suggest we all invite our PW-friends to star the repo if they haven't done yet! My next newsletter will be in 2025, but I'll add it there as well. Also @teppo you might want to mention this in your newsletter which would have a lot more impact than mine I guess 😄
-
3
-
1
-
-
Have you ever realised that DDEV only works when you are connected to the internet? No? Then all fine 😉
If you did, I have good news for you! DDEV does NOT require a working internet connection! You can, of course, use it for local development without being online - for example on a plane.
The only thing you need to know is that if you started the project via "ddev start" while being connected to the internet and then you go offline, then your browser will not find your project any more. All you have to do to solve that is to run a "ddev restart" 🙂
The reason for this is explained here: https://ddev.com/blog/ddev-name-resolution-wildcards/
-
2
-
-
Hey @FireWire thx for your report! Good news 🙂 This should be fixed in v1.4.3
-
1
-
1
-
-
Does anybody know a software where I can quickly write down estimates of project cost/duration like this:
Where I can add features/tasks with an estimate duration and where I can toggle the tree branches on/off and see the totals?
How are you doing this?
Thx!
-
1 hour ago, kaz said:
You're right, I meant recurring dates on mostly the same days of the week. That's why I thought of automating it. CSV import would be great if there exists a source for CSV calendar data? I couldn't find one.
I still don't understand, but I probably don't have to.
RockCalendar is great when you want to give the users the possibility to enter dates, especially enter recurring dates (you also need RockGrid for that), and have the option to modify single events (add exceptions, move single events out of the series, etc).
Building a UI for this is not easy and a lot of work, so RockCalendar should save you a lot of work and hassle.
On the frontend you can do whatever you want. All events that RockCalendar creates are just regular PW pages. Showing a list is even easier than showing a calendar, because all you need is a PW selector and a foreach. The only thing necessary for events is that they have a rockcalendar_date field, because only then RockCalendar can know when they take place and where to show them in a calendar on the backend (or how to sort them).
I don't know how you "thought of automating it" or what you'd automate, so I'm not sure how RockCalendar would fit here or if at all.
-
I've been working to improve the deployments feature. As a result I changed a small detail in v6.3.0 that might break your deployment pipeline.
If you are seeing this error:
QuoteCould not open input file: .../tmp-release-2024.../site/modules/RockMigrations/deploy.php
You can either update RockMigrations or, if that is not possible, make your workflow use the old version of the deployment:
Quoteuses: baumrock/RockMigrations/.github/workflows/deploy.yaml@v6.2.0
-
1
-
RockCommerce tax rates handling
in RockCommerce
Posted
Hi @gebeer thank you for your questions.
This is at the moment not possible. RockCommerce by default can only handle a global taxrate per user (to be more precise per cart), not per product.
Absolutely. Unfortunately I had to do quite a lot of refactoring before I launched and therefore some of the docs were outdated, so I decided to keep them as backup in the docs-old folder and move them over to the new folder as I find time to correct outdated informations. I have done that now for tax handling and things are clear now hopefully.
Thx! That's added!
That's already in the docs about the cart. I have added a note to the tax docs as well, thx.
As you can see in the old docs I thought about adding that, but I decided against it. The goal was to make the experience of setting up a simple shop as simple as possible. Obviously that comes with some limitations.
I think it would not be too hard to add support for different taxrates per product. But it would also not be trivial. Different taxrates per product means the VAT of the cart is not anymore a simple "net times taxrate" calculation. It moves that calculation to each product and then the cart needs to collect all taxes and then maybe even list them on the cart summary like so:
items net: 120,00€
items vat: 21,00€
- 10% of 50€ = 5€
- 20% of 50€ = 10€
- 30% of 20€ = 6€
The goal is to keep RockCommerce as simple as possible by default. Similar to product variations that have to be enabled manually we could also add an option to allow taxes on a product level rather than on a cart level.
If you have that need (or anybody else) let's get in touch via PM!