Internal Server Error and "repeater"

[Captain Coffee]

Good evening!

I did my first attempt with processwire. Everything worked fine. 

But after defining and inserting a "repeater" into a page i cannot access my site anymore. I only get the "500 Internal Server Error".

The debug mode throw this out. Any ideas?

Thanks an greetings from germany

Martin

Fatal error: Exception: Method Page::editable does not exist or is not callable in this context (in xxx/wire/core/Wire.php line 232) 

#0 [internal function]: Wire->__call('editable', Array) 

#1 xxx/wire/modules/Fieldtype/FieldtypeRepeater/FieldtypeRepeater.module(485): Page->editable('repeat_me') 

#2 xxx/wire/core/Wire.php(271): FieldtypeRepeater->___wakeupValue(Object(Page), Object(Field), Array) 

#3 xxx/wire/core/Wire.php(229): Wire->runHooks(Array, Array) 

#4 [internal function]: Wire->__call('wakeupValue', Array) 

#5 xxx/wire/core/Page.php(442): FieldtypeRepeater->wakeupValue('wakeupValue', Array) 

#6 xxx/wire/core/Page.php(1337): Page->setFieldValue(Object(Page), Object(Field), Array) 

#7 xxx/wire/core/Page.php(130 in xxx/index.php on line 214

[ryan]

It sounds like it can't find the $page->editable(); function, which is a function added by an autoload module called PagePermissions.module. This is an unusual error message and not one posted before. It makes me think there may be something up with the PHP version, MySQL version or PHP opcode cache. Can you post what versions you are running of ProcessWire, PHP, MySQL and anything else about the server environment? (maybe a phpinfo() link if you want to PM to me)

[Captain Coffee]

Hallo Ryan,

on my Server are running this versions:

PHP Version 5.2.12

MySQL 5.1.66

 

Thanks, Martin

[DaveP]

I have come across something similar, when I installed the PagePermissions module, then sometime later just deleted the page_editable field because I couldn't remember it being used for anything. Uninstalling the module fixed everything (of course).

Just as an afterthought, is there a way for module-created fields to be locked against deletion to help oafs like me?

[diogo]

I was thinking of this when Pete created the install routines for my module http://processwire.com/talk/topic/3474-admin-custom-pages-module/?p=37140

Since we have field tags now, the modules that create fields could give them a tag with the name of the module and another tag that would be for all modules. The important here would be that all the modules use the same tag for the second case (let's say "modules"), and follow same logic for the first case (maybe the name of the module class...)

I suspect that this would be the right way to create two field tags, one "modules" and one "module-admin-custom-pages".

$field = new Field();
$field->type = $this->modules->get("FieldtypeTextarea");
$field->name = 'ACP_scripts_and_styles';
...
// create the field tags (the "-" before "modules" makes it collapsed in the admin)
$field->tags = "-modules module-admin-custom-pages";
$field->save();

edit: my suspicion was right. It works. I will add this to the module as soon as we decide on a common tag for all modules. What do you guys think?

[Soma]

If a field is used in a template you cant delete it anyway..

I don't think using tags would help that and I dont understand what davep problem has to do with op.

[apeisa]

You can also set fields as system fields that cannot be removed at all (only by modules uninstall). Not saying that is a good idea.

[diogo]

Not saying that is a good idea.

I think it isn't... and I'm not sure if uninstalling the module should delete the field. Or maybe it can ask if, and then delete.

I guess Soma is right, and we are hijacking the thread with this...

[DaveP]

I don't think using tags would help that and I dont understand what davep problem has to do with op.

I was speculating that the OP might have done the same as myself - not recognised the field inserted by the PagePermissions module as being relevant (I had assumed it was something that had been my experiment and I had forgotten about it) and had deleted it from the template. Then, because the module is still installed it errored in a very similar way to the OP. (Which appears to be the case from the OP and Ryan's comment.)

[ryan]

I was speculating that the OP might have done the same as myself - not recognised the field inserted by the PagePermissions module as being relevant (I had assumed it was something that had been my experiment and I had forgotten about it) and had deleted it from the template. Then, because the module is still installed it errored in a very similar way to the OP. (Which appears to be the case from the OP and Ryan's comment.)

This is what the system status for fields, templates and pages are designed for. For instance, the Language Support modules create system fields, templates and pages to ensure they can't be deleted. 

System fields can't easily be deleted even at the API level. It's intentionally difficult, requiring you to set it to an override value before it'll remove them. As a result, simply uninstalling a module will not cause system fields to be deleted, unless the module is specifically deleting them in it's uninstall() method. Since we're talking about fields here, here's how to make a field a system field:

$field->flags = Field::flagSystem | Field::flagPermanent; 

flagSystem means that the field can't be deleted or have it's name changed. flagPermanent means that the field can't be removed from any templates where it is assigned. They can be combined like above (which is usually the case), or used individually. 

It's not possible to delete system fields from the admin, but it is from the API. If you need to delete a system field at the API level, you have to assign an override flag to it first, otherwise it'll throw an exception when you try to set a non-system status to it (which prevents the deletion). This is a form of "are you sure?" from the API side.

$field->flags = Field::flagSystemOverride;
$field->flags = 0;

After that, a field that had a system/permanent status can be deleted.