some questions… first: checking if field exists doesn't work

[froot]

OK thanks, yes better to anticipate the user mights change path or name of the processs page(s).

However, when you say you cannot delete a page without id, why would I select pages WITH an ID to delete them? The initial problem was that I uninstalled the module which left a null page behind that was still visible in the admin menu but not deletable. Clicking on it would return an error "unkown path" or what ever.

[teppo]

15 minutes ago, fruid said:

The initial problem was that I uninstalled the module which left a null page behind that was still visible in the admin menu but not deletable. Clicking on it would return an error "unkown path" or what ever.

What the error you posted says is basically that your code doesn't found a page matching the path you've provided. This is why it returns a NullPage object, which is kind of like saying "sorry, didn't find anything, here's a placeholder object for you instead". And since you can't remove a NullPage, that explains the error you saw.

Now, what you're describing here sounds like some kind of a bug, though it's a hard to pinpoint exactly without access to the code, site, and/or database. Couple of suggestions:

1. When this happens, I would first check if logging out and then in again removes that "page" from the menu. Admin menu is cached independently, so this could be the reason. Though I'm not sure why said cache wouldn't reset automatically.
2. If that doesn't help and there is indeed an actual page there, it would be interesting to know what kind of data it has in the "pages" table in the database. Another reason why this might happen would be if a page is somehow corrupted. A typical signal of that would be that it exists in the database, but has a strange value in the "status" column.

If you post your current code, I would be happy to take a closer look (at some point) in case there's some sort of issue there ?

[froot]

I have new questions…

Right now I have a separate Kiosk.config.php file that handles user provided settings on a settings page (accessible on the modules overview). I know for a fact that this is not mandatory, many modules have all in one page yet they still use a separate settings page. Anyways, let's keep in for now, it keeps things in order.

My question is though, how do I properly access these settings? At the moment I do

$kioskConfig = wire('modules')->getConfig('Kiosk');

inside the class. This seems verbose. Shouldn't something like

$kioskConfig = $this->getConfig()

work as well? (asking because it doesn't) Or would that indeed require to move the code from inside Kiosk.config.php over to the module's (main) class (I only use one class, I think that's normal).

I can access the user provided settings info with the verbose version above but I guess I should define those settings as module properties? Because what I'm doing now is store it in a variable and repeat that in each method which is most likely not the right way. And where and how do I define these user provided settings (and other default ones maybe)? Do I use init()? or __construct()? I guess is a matter of taste of preference. However, I can seem to get it right. I tried with something like…

public function init() {
$kioskConfig = wire('modules')->getConfig('Kiosk');
$this->whatever = $kioskConfig->whatever; // doesn't work
}

I guess there's one underlying question that I need answered, how to access the modules config properly?

[froot]

2 hours ago, teppo said:

If you post your current code, I would be happy to take a closer look (at some point) in case there's some sort of issue there ?

thanks @teppo Currently this is not an issue, but it seems to often come back when there's an other issue… 

What still is an acute issue though is the following code bit:

$suckers = wire('pages')->find('template=template_custom_orders');
foreach ($suckers as $s) :
	$s->delete();
endforeach;

It first throws an error like Can't delete Page 1234 because it has one or more children
But it deletes the children pages, NOT the parent page.
When I uninstall it a second time, I get no error and it uninstalls the parent page.

That's odd. My guess would be I need to save the parent page in between delete the children and deleting the parent? Seems wrong though…

[froot]

EDIT: I should of course add the page where I'm actually trying to delete the parent page ? That one actually throws the error(s).

It's very weird, otherwise installing/uninstalling works fine - so far…

On 8/13/2022 at 9:50 PM, teppo said:

	$module_id = wire('modules')->getModuleID($this); 
	$dashboard = wire('pages')->get('template=admin, process=' . $module_id);

This doesn't work at all BTW. I end up with an empty dashboard page and it has "no process".

[froot]

I posted the fruits of my labour and your contributions in the post below, thanks to y'all, looking forward to your feedback!

 

[froot]

https://github.com/dtjngl/kiosk/blob/master/Kiosk/Kiosk.module#L237

@teppo @bernhard can you help me find the bug? It won't delete the page in line 237 and 239 if it has children, because it has children, but I delete those children in lines 232–235

[bernhard]

$rockmigrations->deletePage("/yourpage");

https://github.com/baumrock/RockMigrations/blob/2db2e74407a663150dbc2f423662b287b59d7919/RockMigrations.module.php#L976

[teppo]

3 hours ago, fruid said:

https://github.com/dtjngl/kiosk/blob/master/Kiosk/Kiosk.module#L237

@teppo @bernhard can you help me find the bug? It won't delete the page in line 237 and 239 if it has children, because it has children, but I delete those children in lines 232–235

wire('pages')->get('template=template_custom_orders')->delete() uses $pages->get(), which means that it will include pages that are either in trash, or unpublished/hidden. Meanwhile this part...

    $tcos = pages('template=template_custom_order');
    foreach ($tcos as $tco) :
      $tco->delete();
    endforeach;

... will only find non-trashed public pages. One thing to check is that it matches every possible page:

    $tcos = pages('template=template_custom_order, include=all');
    foreach ($tcos as $tco) :
      $tco->delete();
    endforeach;

BUT that being said, there's potentially an even easier method:

    wire('pages')->get('template=template_custom_orders')->delete(true);

If you pass "true" to the delete method, it will automatically (attempt to) remove child pages.

[froot]

1 hour ago, teppo said:

    wire('pages')->get('template=template_custom_orders')->delete(true);

 

that seems to work just fine, thanks!

[froot]

2 hours ago, bernhard said:

$rockmigrations->deletePage("/yourpage");

so…

public static function getModuleinfo() {
	return [
		'installs' => 'RockMigrations',
	];
}

I'm sure this module rocks, pun intended. When will it be a core module?

[bernhard]

1 hour ago, fruid said:

I'm sure this module rocks, pun intended. When will it be a core module?

Likely never. I know how great it works and how much difference it can make. But it seems that there are very few people actually using it. Even though it's free and one of the best things I have built over the last few years. The reason why it is free is mostly because I thought many other module developers could benefit a lot from using it for their modules. We could have blog modules that create all the necessary fields and templates for example. I guess you'd be 10 times quicker using RockMigrations compared to a traditional API based setup.

I plan to create a video about it as soon as I can. Maybe that will open some eyes.

Maybe it will also show Ryan the benefit of the concepts and we get something similar for PW4 one day, who knows...

 

[froot]

26 minutes ago, bernhard said:

But it seems that there are very few people actually using it.

I think the issue is, like I mentioned before, that many devs don't want their module to rely on yet another third party module to function (install/uninstall) correctly. What if the module is discontinued some day or outdated?

What you could do, just an idea, is make the migrate module serve the same purposes it does already, but instead of offering methods, generate the code that would work with pure PW that developers can put in their module.
Also, not sure if that's possible or this or another module offers that already, allow for fields and template export. So what happens a lot to me at least is, I work on a site, create some fields and templates via GUI and when I'm happy I want these fields in another installation or better yet (from now on at least) included in a module. Then I would need to re-overthink what I did via GUI to accomplish the same thing via API. If you could just use RockMigrations, navigate to the field(s), template(s) or even page(s)? in question and click click bing bang boom it shows you the API-code you need for PW to install it in anywhere else.

[bernhard]

4 minutes ago, fruid said:

I think the issue is, like I mentioned before, that many devs don't want their module to rely on yet another third party module to function (install/uninstall) correctly. What if the module is discontinued some day or outdated?

Yes, I understand that. They have the free choice to do it the hard way if they feel more secure then and come up with all the same questions that I came up with while developing the module.

11 minutes ago, fruid said:

What you could do, just an idea, is make the migrate module serve the same purposes it does already, but instead of offering methods, generate the code that would work with pure PW that developers can put in their module.

Nice idea but simply not possible.

11 minutes ago, fruid said:

Also, not sure if that's possible or this or another module offers that already, allow for fields and template export. So what happens a lot to me at least is, I work on a site, create some fields and templates via GUI and when I'm happy I want these fields in another installation or better yet (from now on at least) included in a module. Then I would need to re-overthink what I did via GUI to accomplish the same thing via API. If you could just use RockMigrations, navigate to the field(s), template(s) or even page(s)? in question and click click bing bang boom it shows you the API-code you need for PW to install it in anywhere else.

There has been a lot of discussion about that. See https://processwire.com/talk/topic/26565-share-your-pw-dev-setups-tools/#comment-220383

What you describe is exactly where RockMigrations shines. I keep repeating myself. And people keep not using RockMigrations. That's ok, but I'll not go into details of your question again. I've explained often why something that you describe is not a good solution. It might be a little easier to use, but it does not make the solution better in the big picture.

 

[froot]

I have another question concerning fieldgroups.

The installation now seems to work flawlessly, the module installs fields and fieldgroups and template with these fieldgroups. When editing the template in the GUI, I get a different interface to what I am used to when the template was created in the GUI, see screenshot attached.

Does that raise any red flags? Why can't I add other fields to the template? Is that a security measure of some sort? What are other limitations apart from the obvious one?

 

[froot]

really curious about this one, I'm concerned that something is not well configured and will cause damage in the future. Why aren't the individual fields listed within a ASM-Select field as usual?

 

[bernhard]

I'd also be concerned. I've never seen that. No idea what you did..

[froot]

@ryan any idea?

It also says 

For your reference, this is a list of fields used by this template. This template gets it's fields from the 'fieldgroup_kiosk_order' template.

instead of 

Define the fields that are used by this template. You may also drag and drop fields to the desired order or create a new field.

Seems like this is actually a wanted behaviour in some scenario I can't fathom here.

[froot]

I changed the fieldgroup of the template in question, just to see, with a fieldgroup that I know works fine (one that I created via GUI). After saving, it still shows the fields as shown in the screenshot above. So I'm convinced it has to do with the template that I created itself, not the fieldgroup. So I did a print_r of the faulty template and another template that works as expected (again, created with the GUI) and the only things different I see are 

[data][editroles] = Array ([0] => 1101)
[data][createroles] = Array ([0] => 1101)
[ns] => ProcessWire

which is missing in the faulty template. And that kind of makes sense to me because I cannot edit the fields of this template so it must have to do with permissions/roles. I doubt it's the last one with the namespace (?). 

But now what, how do I add a role via API? Do I add it with its ID or the name? Wouldn't that change with every installation?

Thanks for help.

[froot]

another issue I'm having now is that the module keeps reinstalling itself when I open the frontend.

I uninstall the module, delete all related fields, templates and pages. Clear compiled files, refresh the modules (which is probably pointless), then open any site in the frontend and boom, the module is installed again along with all that I deleted manually. How can that be? It's not autoload or anything.

thanks for help 

[bernhard]

If anything tries to access your module than it will auto-install it. Maybe you have a $modules->get('YourModule') somewhere in your frontend?

[froot]

yes that is indeed the case, OK then it's not an issue, I just didn't know that it would do that. I can work around that then or use autoload somehow – thanks!

[bernhard]

You can do that:

if($modules->isInstalled('YourModule')) {
	$m = $modules->get('YourModule');
	echo $m->foo();
}

 

[froot]

19 hours ago, fruid said:

For your reference, this is a list of fields used by this template. This template gets it's fields from the 'fieldgroup_kiosk_order' template.

this remains a mystery. Also, I found another typo. Should be its and not it's ?

EDIT: never mind, the typo got fixed in a later version ? ? 

[froot]

OK after some reverse-engineering, for lack of a better word… no actually reverse-engineering actually nails it. I found out that the fieldgroup's name needs to match the template's name. Once this is ensured, it works, then you can edit/remove/add/shuffle fields, all the good stuff. You're welcome ?