LostKobrakai

If it makes sense for each snippet to work on it's own, independent of the others, then having modules for each one could make sense. But if most of them are just few-liners I would most likely go with a single central module, where the single snippets can be enabled/disabled in the options.

Please keep in mind, that the trash is only visible to superusers. Therefore normal users can't move any pages to the trash. The trash is implemented as security measurement, so that users can't permanently destroy content. They just have the option to delete a page, but normally no knowledge about the trash. Under this circumstances it's understandable that there may be quirks with moving a page to the trash and that the delete tab on the edit page responds to deletable() and not trashable(). The deletable() permission really is the function you're looking for.

For such advanced usecases there's always the possibility to version control the json export for templates/fields. The problem of database schema changes is more a problem of relational databases and not the cms itself.

The PageList does initiate trashing via ajax, therefore the missing message. Also your hook does not throw any error or return false, therefore the ajax call can't determine, that you don't want the page to be trashed. The more failsave way of preventing trashing would be by hooking Page::deleteable, as this is checked everywhere throughout ProcessWire no matter from where it's called.

You could try to put it in the CKEditor folder under /wire/… just to see if it works. Forgive me the stupid question, but why would you want to get rid of the trailing slash?

In the last few weeks I've notices some request (e.g. here and here) to be able to get pages based on if they are selected in page fields of other pages. I think adding a method for this would be a nice addition to ProcessWire, as it's often the case that the pages itself are options we just want to get, if they are used somewhere. Currently the task "Get all tags used by some blogposts" has to be done manually like this: $tags = $pages->find("template=tags"); foreach($tags as $tag){ // Filter unavailable if(! $pages->count("template=posts, tags=$tag") ) continue; // Do stuff with it } Now it would be nice to have something like this, where we don't need to have a selector for tags (this is done by the pagefield already). // Find all pages, which are selected in the "tags" field of the selected posts $available_tags = $pages->findSelectedPages("template=posts", "tags"); I'm not that big a MySQL guy, but I can imagine this not only improving readability, but also reducing database calls.

Problem is, even the include unpublished is only testing the pages requested, means if the tag is unpublished or not. You can't get only tags used by published pages with a find selector. $posts = $pages->find("template=posts"); // no unpublished ones $tags = new PageArray(); foreach($posts as $post){ $tags->import($post->tags); } $tags = $tags->unique(); Note that this does not scale well with growing number of posts. The more scalable way would be hooking Pages::save and Pages::delete and unpublish tags if no other visible page is using it anymore / republish them if they are used again. Edit: And again missed the other variant $tags = $pages->find("tags"); foreach($tags as $tag){ if($pages->count("template=post, tags=$tag")) continue; // Found at least one possible post }

The user editing the image needs to have "page-view" permission for the page, where the image resides.

You can use hooks to modify the return value of ProcessPageEdit::buildForm, which generates the button. This will help you get started with the form generating api: https://processwire.com/talk/topic/2089-create-simple-forms-using-api/.

I wouldn't necessarily think the query is wrong (can't compare as your superuser account didn't work) but rather the return value is not expected. The markup of the edit page shows up inside of the table.

That I can't answer. I think it's a bug, as it seems kinda useless to return the edit page itself instead of anything useful to be added to the table.

The issue is that the ajax response from "?id=1026&InputfieldPageTableField=pagetable&InputfieldPageTableAdd=1036" does not return the expected . It's responding with what seems like the body of the user edit page.

Just look at the core Process modules and see what they are doing and how it's implemented. ProcessPageEdit for example is a really great resource, even if it's kinda overwhelming in the beginning.

Thanks for the clarification. It just looked like a global configuration from the screenshots. Will install the module later today.

So I do have to give this a test after all. My current client is working with a master excel list, which is imported to pw and I've used Ryan's importer by now. But the ability to predefine the column to field connection is really nice and easy reimporting to update even more. Would it be possible to have different CSV "schemas"? Maybe later even in a per template notion.

That does not work as you would like. But there's no real difference between hard coding in the config.php or hard coding in the settings of a options field. It may be not as easy to edit if you,ve already some texteditor open, but thats it.

Check for the id of the page. It won't have one before the page is saved.

Oh never mind, that was the part I missed

Just found another thing, which could be improved. Automatically add "implements ConfigurableModule" if one selects "include configuration page". Or do I miss something here? Also want to say thank you here. It's really nice to have this and finally get my head around the json and external configuration settings It's a real timesaver as I'm working on lots of modules currently.

I just created a module with the generator and had the problem, that neither WireData nor Wire do have a init() function, therefore parent::init() failed.

Sadly that's not right. OR groups are still not supported for inputfield dependencies. Also the docs are here, where by now it's still stating, that or-operators do not work: https://processwire.com/api/selectors/inputfield-dependencies/#limitations @MuchDev Keep in mind, that inputfield dependencies do not work inside of repeaters. You can hide the whole repeater field, but you can't use them inside of repeater "templates" and you can't show/hide anything based on values inside of repeater items. There were some efforts by Soma to make them work, but I'm not sure about the state and reliability of it.

Maybe not perfectly related, but it's also using urlSegments to have pages live under a different parent: https://processwire.com/talk/topic/7548-dual-url-structure-for-categorized-content/. It's a little more verbose than Nico's example.

Numbers preceded by a 0 are parsed by php as octal numbers (base 8). var_dump(013); // outputs int(11), because it's 1*8 + 3

If you don't care about the urls showing the name of the wrapping page, than it's not that difficult. $page->parents("template!=news-container"); And in the news-container.php: $session->redirect($page->parent->url);