bernhard

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!

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 https://github.com/baumrock/HumanDates

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.0 And 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::renderAssets Oh... 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::renderAssets Another 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::savedPageOrField I 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.

---deleted---

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::callUnknown You 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::finished This 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!

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 🙂

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] ..."

If $this->prefix is empty you set the type of the "title" field to "text", which would explain your issue!

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? 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.

Hey @Yipper thx for the report! 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.

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!

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 ...