bernhard

Thx to @Robin S I realized that GitHub now also offers unlimited private Repos for free. In some discussion about it I found another interesting alternative (if you don't want to host private code on external servers): https://gitea.io/en-us/

OK great for PW, bad for solving your problem ? Then I'm out of ideas, sorry ?

This statement seems like you didn't get what I tried to say. Means that you have maybe selected page 1018 in the page-reference-field "planet_reference" of page 1018. That means the planet_reference of 1018 points to page 1018 (itself) and could maybe end in an endless loop? No idea if that is possible and it would throw such an error. I think PW should be clever enough to prevent such errors. If not, that would be worth an issue report!

Sure! Thx ? I missed the memo it seems. Which ones are these? I'm talking about a new Grid module (or a Chart module or the like) that needs some javascript events to work: I think it would be nice to have some kind of base module that we can easily extend to our custom needs, but that does have some standards built in for things that can get complicated when building your own fieldtypes. I'm talking of all those tedious edge-case scenarios that make our lifes hard, like charts not updating it's size when resizing the window, grids not getting initialised when the field is loaded via AJAX, fields breaking when they are in a tab that is not shown on the initial page load. I think it would make sense to have some tested and reliable standard javascript events for all those situations. Or maybe I'm wishing something here that is not really possible? ?

I think even if that was the case it should not end in such an error, but I don't have time to test it right now and maybe others will have better ideas ?

Is planet_reference of page 1018 pointing to itself? BTW: Use dump() or the shorthand d() better than echo in the console ?

Hi @Manuel and welcome to PW and the forum ? I don't see anything strange here. Could you paste the whole code? Are you sure you don't have any endless loop somewhere? I'd also recommend that you install TracyDebugger - you can try snippets like the one posted above easily in the console: https://adrianbj.github.io/TracyDebugger/#/debug-bar?id=console

Hi @Robin S I've just tried your example, because I'm always using ProcessPageEdit::buildForm for such things. In my case your hook fires twice on a regular page edit and three times on an multilang field with two languages... Any reason why you are using Field::getInputfield and not ProcessPageEdit::buildForm like in this example that I've just posted:

$wire->addHookAfter('ProcessPageEdit::buildForm', function($event) { $page = $event->object->getPage(); if($page->template != 'home') return; // example if($page->isUnpublished()) return; $form = $event->arguments(0); $field = $form->getChildByName('title'); // example $field->collapsed = Inputfield::collapsedNoLocked; }); ?

Well... me neither. I'd also prefer to have one common and stable solution, so if you are now willing to accept those changes (I also read the thread again and was confused by my own explanations sometimes. One point was misleading (that I was requesting to place the files in the module's folder which would break on every update, of course) and it's always a little hard to have such conversations via internen + non-native language ? ) I'll try to send a PR for your module as soon as I start working on the related modules!

Hi @Sarnoc and welcome to the forum, It does not sound like you'll need any hooks or custom SQL to get what you are trying ? This page is your best friend: https://processwire.com/docs/selectors/ I think your setup is good as it is! I'd not recommend using repeaters for that. Pages are in general more flexible and better/easier to maintain in the long run in my opinion. I also wonder why the find operation does not work... IMHO it should. I guess your pages have a different NAME (not title)... Using TracyDebugger you can easily and quickly try such things: "poc" is a page reference field. And the referenced field has title="Jakob Enigl Pagetitle" and name="Jakob Enigl Pagename" That's why the first line does NOT work and the other lines do work. The first dump looks for the pagename (no subfield specified) and I guess it does work because the string is sanitized to a pagename (see last dump). When building your queries with user input or dynamic values it's sometimes easier and more readable to build your selectors as arrays:

Are you talking about the frontend or the backend? I don't understand your whole setup, I guess ? Where do you store your initial date (the one that is the reference to count the days to the date of the entry)? Is it like this? 2019/04/01 Foo Bar 2019/04/02 - Day 1 2019/04/05 - Day 4 2019/04/09 - Day 8 2019/04/02 Bar Foo 2019/04/05 - Day 3 2019/04/09 - Day 7

Hi @elabx, thx for asking ? Well, one (crucial) thing would be the javascript events. Maybe that could be added to kongondo's module, that's why I was asking for his opinion. Besides that I don't like how his module works (I'm picky, I know). We had some discussion about it (https://processwire.com/talk/topic/10804-module-runtimemarkup-fieldtype-inputfield/?do=findComment&comment=148083). And it was simply easier to have things under my control than modifying his version with custom hooks. But yeah.. It might not be necessary to have another module for this ?

I vote against a site profile approach... ? I guess I'm biased (I simply don't like site profiles at all), but how should any of the mentioned ideas work as a site profile? How would your customers get updates? What if they needed customizations? What if they want to integrate it in an existing project? Besides, I wonder if there is a market for commercial modules at all. Since Friday, the event booking suggestion got 15 votes. If 10% purchased such a software, that would mean 1.5 purchases... But maybe someone that has already released commercial modules could provide some insights. I think what PW would need is a good way to handle exactly what you mentioned above as your challenges: That's what @LostKobrakai has (kind of) tackled some time ago with his Migrations module and what I have started to tackle with my version of it. I think a proper way to handle such things would be the best addition to PW. This would also make it possible to have a proper workflow for staging/dev setups that have been discussed over and over again here in the forum.

Intelephense works great most of the time... Nevertheless sometimes I don't get proper results, see this example: Any ideas why I don't get "InputfieldForm" (and several others)? Edit: Ok, I changed the filename from InputfieldForm.module to InputfieldForm.module.php and it works. Does anybody have an idea how to make Intelephense index .module files? I already have a user settings for file associations linking .module to .php; That works for code colorization but not for the intellisense ?

Hi @MrSnoozles you are right - RockGrid is intended to load all data to the client at once. Doing this via paginated ajax calls would have a lot of side effects and is not planned. For example if you have column statistics showing the sum of all rows, that would not be possible when data was paginated (and not fully loaded into the grid). Also sorting would work totally different. aggrid supports this feature, but it would need a LOT more work to also support this in RockGrid. Not only for development of RockGrid but also for development of every single field/grid. When I have complex queries then I usually display only a subset of the data, for example all entries of year XXXX. You can see some performance tests here:

Thx kixe, I know that library, but I wonder where you have used it and what for ?

What do you need iframe resizer for?

Not another Markup Fieldtype ? https://github.com/BernhardBaumrock/FieldtypeRockMarkup What do you think of a Fieldtype that does nothing else then rendering runtime markup from files that you provide in the settings or at runtime? In addition to that, I'd like the field to trigger javascript events to be usable for other fieldtype modules (like a charts module or a grid module). Javascript events would be necessary on field load (ajax/non-ajax), on collapse of the field, on click of a tab. When working with charts and RockGrid this has sometimes become a pain and I've implemented (sometimes dirty) fixes for that in different modules in different ways. I think it would make sense to have a solid base for such kind of modules (fieldtypes) that use some kind of standard events for standard situations. I'm especially interested in your opinions @Beluga because of the upcoming RockTabulator module and @kongondo because of your existing module. I think there are already similar modules by @Robin S and @kixe ? Thx for your input ?

Great points @wbmnfktr! Thanks for pointing me to ploi.io @Mikie - looks like a good alternative to runcloud ? I'm using my own VPS's at reliable hosting companies in AUT/DE as for the reasons @wbmnfktr mentioned. Personally I don't do any installations on 3rd party hosting providers any more. For me it was always a pain at some point. For example one hoster just didn't have SSH access and there was no option to transfer the whole site at once. Transferring the whole site via FTP would have taken hours... that's really not worth the saving of 5€/month compared to having all on my VPSs and full control over everything and being efficient and fast. I've never had problems with my clients paying 5-10€/month for hosting on my server, when I tell them that setting up the website on their servers costs extra money and is a lot less efficient and more expensive in everyday operation. And that's not a lie! But it depends on your business... If you only do simple websites with no extra needs and maybe even no updates for several years, then it might be easier and better to choose a standard hosting provider that does everything for you (including invoicing, which can be tedious). 5-10€/month is for sure not worth doing everything on your own if you don't need any advanced features (like ssh, git support, etc).

Thx for clarifying. I don't like the idea of code generators. Maybe because I'm not familiar with them. But I could think of some kind of central migrations queue system. Modules could "register" their migrations in a central place and make sure the order of execution is in a way that there are no conflicts. For example a migration could define requires => ['otherModule' => '0.0.3'] This could then run the migration in "myModule", execute "otherModule" until v0.0.3 and continue with executing "myModule" migrations afterwards. At the moment this is a little theoretical, because I usually do small iterations, push them to production and for the next iteration I have to identical states to start from. That's easy to handle. Sometimes I even do changes by hand, if that is no problem (eg the change does not affect the live system - like changing a typo in some textfield or the like). Also running a migration twice is usually not a problem at all. My api is designed in a way that, for example, if you create a field in your migration and the field already exists, it will just return that field. I'm not sure about this one. At the moment it feels like this is not the best idea, but I'm sure I've had a reason to do it this way ? It's alpha... things might change. I released it to get some feedback and input. And so far it did a great job on several updates across several sites ?

I'm so lazy ? That's why I created RockModuleCreator some time ago... I didn't want to copy files, rename them, rename the class, lookup icon names etc... Not a lot to say... Simply upload your skeleton to github or similar, add placeholder tags like `#author#` or `#date#` and create modules quickly and easily. I'm happy to accept PRs if anyone wants to take this further... https://github.com/BernhardBaumrock/RockModuleCreator Available skeletons: https://github.com/BernhardBaumrock/RockMigrationsDemo https://github.com/BernhardBaumrock/RockProcessHello

This is the thread for the old version of RockMigrations wich is deprecated now and has been renamed to RockMigrations1 Here is the latest version of RockMigrations: -- Old post from 2019 -- https://github.com/baumrock/RockMigrations1 Quickstart First make sure you have backups of your database!! Install RockMigrations Create this ready.php <?php /** @var RockMigrations1 $rm */ $rm = $this->wire('modules')->get('RockMigrations1'); $rm->migrate([ 'fields' => [ 'myfield' => ['type' => 'text'], ], 'templates' => [ 'mytemplate' => [], ], ]); Open your PW Backend and you'll see the new field and new template! Now add the new field to the template: <?php /** @var RockMigrations1 $rm */ $rm = $this->wire('modules')->get('RockMigrations1'); $rm->migrate([ 'fields' => [ 'myfield' => ['type' => 'text'], ], 'templates' => [ 'mytemplate' => [ 'fields' => [ 'title', 'myfield', ], ], ], ]); Reload your backend and inspect the template: Now let's add a label for our new field and make title+myfield 50% width: <?php /** @var RockMigrations1 $rm */ $rm = $this->wire('modules')->get('RockMigrations1'); $rm->migrate([ 'fields' => [ 'myfield' => [ 'type' => 'text', 'label' => 'My Field Label', ], ], 'templates' => [ 'mytemplate' => [ 'fields' => [ 'title' => ['columnWidth' => 50], 'myfield' => ['columnWidth' => 50], ], ], ], ]); That's all the magic! You can easily lookup all necessary properties in Tracy Debugger: Let us add a Textformatter as an example! Add the textformatter via the PW backend (not via RM), save the field and inspect via Tracy: Now add this data to your migration: <?php /** @var RockMigrations1 $rm */ $rm = $this->wire('modules')->get('RockMigrations1'); $rm->migrate([ 'fields' => [ 'myfield' => [ 'type' => 'text', 'label' => 'My Field Label', 'textformatters' => [ 'TextformatterEntities', ], ], ], 'templates' => [ 'mytemplate' => [ 'fields' => [ 'title' => ['columnWidth' => 50], 'myfield' => ['columnWidth' => 50], ], ], ], ]); Ok maybe you noticed that migrations are now running on every request which may slow down your site a lot! RM2 will have a feature to automatically detect changes and fire migrations automatically. RM1 does not have this feature, but I've used a technique in all my projects that fires migrations on every modules refresh. Simply wrap the migration in a fireOnRefresh method call: <?php /** @var RockMigrations1 $rm */ $rm = $this->wire('modules')->get('RockMigrations1'); $rm->fireOnRefresh(function() use($rm) { $rm->migrate([ 'fields' => [ 'myfield' => [ 'type' => 'text', 'label' => 'My Field Label', 'textformatters' => [ 'TextformatterEntities', ], ], ], 'templates' => [ 'mytemplate' => [ 'fields' => [ 'title' => ['columnWidth' => 50], 'myfield' => ['columnWidth' => 50], ], ], ], ]); }); How to remove things you created before you may ask? Use the declarative syntax: <?php /** @var RockMigrations1 $rm */ $rm = $this->wire('modules')->get('RockMigrations1'); $rm->fireOnRefresh(function() use($rm) { $rm->deleteField('myfield'); $rm->deleteTemplate('mytemplate'); }); Refresh your backend and everything is as it was before! PS: Make sure you have proper Intellisense support in your IDE to get instant help:

wow, thx, totally missed/forgot that one! ?

Well, just take a video with your phone ?