Gadgetto

This is what I have so far (very early state, please do not pay attention to the column values) I have decided to use ProcessWire modules wherever possible. I also want to avoid dependency on third-party modules - there are so many out there which are abandoned or no longer supported. The grid in the screenshot is an MarkupAdminDataTable combined with parts of a PageLister. As this will be a live-view, where you can watch your mailings flying out, I'll refresh part of the columns via Ajax. As I said, we have already developed a very powerful multiprocessing sending engine for the mailing module. So we are good to go here. In general, I'd like to orient the Module as closely as possible to the ProcessWire look and feel and paradigm. The UIKit Admin Theme will be primarily supported.

You are merely reflecting on a single paragraph of my posting which was not meant seriously. IMHO, a free CMS is not really free just because it costs nothing. Especially a developer oriented CMS like ProcessWire, because here the users contribute to the project and put a lot of time and effort into the project to make it better, to extend it and to bring it forward. Bu as I can see from the answers here, I might be wrong with my opinion.

Reading the core, you can learn how something works but not why it's done in this way and what is the best way to use it.

That's easy to explain: a developer centric CMS (which ProcessWire is by definition) - should ... you guessed it - support developers as much as possible. Not only for front-end development but also for extending and customizing the CMS. Please don't misunderstand, ProcessWire is definitely worth the effort to get used to - no matter how complex it may be. I only fear that the platform will never come out of its shadowy existence if nothing changes in this direction. I'm only a beginner and can't really assess the status of the system yet, but I get this picture after working with it for about 2 months. The code examples from the module development documentation are rudimentary at best and don't even begin to show what ProcessWire can do. --- sarcasm on --- As a drastic comparison for you as a helicopter pilot, this would be as if you were put into the helicopter as a rookie and told you to fly off after you have just received a small brochure in your hand describing how to take a seat in the helicopter. All other things you should learn by only looking around and looking under the hood... --- /sarcasm off --- If it weren't for the excellent tutorials from you and some other developers, you wouldn't get very far. I guess Ryan is so deep in the system that he doesn't even recognize the problem of the missing documentation anymore. For him, as the inventor of the system, everything is a matter of course. I know that from myself... For a freelancer a change of CMS always means a big risk - this is the main reason for my rant.

Thanks anyway! Learning module development by reverse engineering because no other information or sources are available is usually a bad sign for a CMS. This could be a reason why ProcessWire is not more widespread.

Thanks a lot!

Never mind - found good description and sample code here: https://processwire.com/blog/posts/building-custom-admin-pages-with-process-modules/ Great: @bernhard! The ProcessWire docs definitely need some (a lot) more love regarding module development, samples and descriptions of core features...

Where can I find simple code samples and maybe explanation on how to use/create MarkupAdminDataTable? Thanks in advance, Martin

Under MODX my Newsletter Add-On manages all mailings in its own resource containers. This is comparable to a PW page, which serves as a container for subpages. My newsletter module GroupMailer will also provide an administration console where you can start, stop and generally manage mailings + allows you to watch the sending status. What would you recommend as an experienced PW user? How should the mailings be managed in the PW module? I want to follow the PW paradigms as much as possible and also offer the greatest possible flexibility. Here is a screenshot from the MODX version: Greetings, and a Happy New Year! Martin

[deleted]

Thanks a lot! Thats all for now! ?

Hey, great - that's exactly the information I needed! Thank you! 2 last questions: 1) What if I'd like to add fields after the template was saved and how can I add them to the same fieldgroup? 2) Is there always only one field group per template or will/can there be more than one?

Wow, I didn't expect such a response.I didn't mean to spark a principle discussion. To create clarity: I want to create a full featured Newsletter mailing system with subscription/unsubscription pages, profile edit pages, some backend pages for Newsletter creation, Newsletter handling (sending + CRUD + settings). So I'll definitely need to install fields, templates and pages. Thank you very much for all your tips and hints, but I still don't know what's the best way to install fields and add them to templates via API. Especially the Fieldgroup class gives me headaches: https://processwire.com/api/ref/fieldgroup/ If you have a look at @kongondos MenuBuilder module you can see how he uses a fieldgroup to add fields to a template: https://github.com/kongondo/MenuBuilder/blob/b06c8903fea51b197752b8f10bdd15191efe7ad4/ProcessMenuBuilder.module#L2878-L2917 Are Fieldgroups required for adding fields to templates? What are these for?

I'm definitely interested in developing such a module, but I'm afraid my knowledge of ProcessWire isn't nearly enough... ? But I would be happy to contribute my ideas. In general, I think it would be better if it were included in the ProcessWire API.

I want to create a full featured Newsletter mailing system with subscription/unsubscription pages, profile edit pages, some backend pages for Newsletter creation, Newsletter handling (sending + CRUD).

Hi @kongondo I don't think I'm confusing Fieldsets and Fieldgroups. My question was regarding 'fieldgroups' and how they interact with fields and templates when installing things via API. I found a code sample in your MenuBuilder module where you do the same: https://github.com/kongondo/MenuBuilder/blob/b06c8903fea51b197752b8f10bdd15191efe7ad4/ProcessMenuBuilder.module#L2878-L2917 The problem is, I don't really understand why this is needed and for what.

Hello, I'm just working on the installer for a bigger module which will need many fields + some templates. To make the installer reusable, I decided to provide the installer with a set of arrays which will hold the required resources (fields, templates, pages, permissions and so on). This is the set of arrays (not yet finished, some data just for testing): (separate file Resources.php to be included when needed) <?php namespace ProcessWire; $installer_fields = array( 'goodnews' => array( 'name' => 'gn_test', 'type' => 'FieldtypeText', 'label' => 'GoodNews Test Field', 'description' => 'Test description for the GoodNews Test Field.', 'maxlength' => 256, '_fieldgroup' => 'gn', '_template' => 'goodnews-mailing-container', ), ); $installer_templates = array( 'goodnews-mailing-container' => array( 'name' => 'goodnews-mailing-container', 'noChildren' => 0, ), 'goodnews-mailing' => array( 'name' => 'goodnews-mailing', 'noChildren' => 1, ), ); $installer_pages = array( 'goodnews' => array( 'name' => 'goodnews', 'title' => 'GoodNews', 'template' => 'admin', 'parent' => $this->pages->get($this->config->adminRootPageID), ), 'goodnews-mailing-container' => array( 'name' => 'goodnews-mailing-container', 'title' => 'GoodNews Mailings', 'template' => 'goodnews-mailing-container', 'parent' => $this->pages->get('/'), ), ); $installer_permissions = array( 'goodnews' => array( 'name' => 'goodnews', 'title' => $this->_('View GoodNews Admin Page'), ), 'goodnews-sender' => array( 'name' => 'goodnews-sender', 'title' => $this->_('Send GoodNews Mailings'), ), ); As you can see, each set of fields will hold a '_fieldgroup' and '_template' key/value pair. Currently I try to write the logic to install the templates and add the required fields - grouped by the fieldgroup - to their templates. This is my '__install' method so far: (unfinished in some parts) public function ___install() { require __DIR__ . '/install/Resources.php'; $fields = $this->wire('fields'); $templates = $this->wire('templates'); $pages = $this->wire('pages'); $permissions = $this->wire('permissions'); $modules = $this->wire('modules'); /* ====== Pre installation checks ====== */ // Check if one of the fields to be installed already exists foreach ($installer_fields as $installer_field) { $f = $fields->get($installer_field['name']); if ($f) { $out = sprintf($this->_("Installation aborted. The field to be installed already exists! Please be sure that you do not have a field with name '%s' before installing this module."), $installer_field['name']); throw new WireException($out); } } // Check if one of the templates to be installed already exists foreach ($installer_templates as $installer_templates) { $t = $templates->get($installer_template['name']); if ($t) { $out = sprintf($this->_("Installation aborted. The template to be installed already exists! Please be sure that you do not have a template with name '%s' before installing this module."), $installer_template['name']); throw new WireException($out); } } // Check if one of the pages to be installed already exists foreach ($installer_pages as $installer_page) { $p = $pages->get('template='.$installer_page['template'].', name='.$installer_page['name']); if ($p->id) { $out = sprintf($this->_("Installation aborted. The page to be installed already exists! Please be sure that you do not have a page with name '%s' before installing this module."), $installer_page['name']); throw new WireException($out); } } /* ====== Install fields ====== */ $fieldgroups = array(); foreach ($installer_fields as $installer_field) { $f = new Field(); $f->type = $modules->get($installer_field['type']); $f->name = $installer_field['name']; $f->label = $installer_field['label']; $f->description = $installer_field['description']; $f->maxlength = $installer_field['maxlength']; $f->save(); // Collect field-name in fieldgroups array if available (for later use to add to templates) if (!empty($installer_field['_fieldgroup'])) { $fieldgroups[$installer_field['_fieldgroup']] += $installer_field['name']; } } /* ====== Install templates ====== */ /* ====== Install pages ====== */ foreach ($installer_pages as $installer_page) { // Create new page $page = new Page(); $page->name = $installer_page['name']; $page->template = $installer_page['template']; $page->parent = $installer_page['parent']; $page->process = $this; $page->title = $installer_page['title']; // Save page $page->save(); // Tell the user we created this page $this->message('Created Page: '.$page->path); } /* ====== Install permissions ====== */ foreach ($installer_permissions as $installer_permission) { // Only install permission if it does not already exist $permission = $permissions->get('name='.$installer_permission['name']); if (!$permission->id) { $p = new Permission(); $p->name = $installer_permission['name']; $p->title = $installer_permission['title']; $p->save(); // Tell the user we created this permission $this->message('Created Permission: '.$installer_permission['name']); } } } The question is: How do Fields, Templates and Fieldgroups interact? What is the best way to install fields and then add them - grouped by fieldgroups - to the desired template? Is it even required to group fields when adding to templates? Greetings, Martin

The TracyDebugger method seems to be the easiest one! Thank you for the hint!

@kongondo wow, I didn’t expect a full tutorial in answer to my question! Great! This community is one of the best I’ve ever seen!

Hello, it would be interesting to hear how other developers setup their development environment for developing modules in ProcessWire. For me, the question arises because I come from the MODX world. Under MODX it makes sense to develop plugins outside the MODX core. This means that for each newly developed module, a project folder is created outside the MODX core (wherever the developer wants). The complete development takes place there. By means of certain directives, the module under development is linked to the MODX core. For MODX this looks as if the plugin is located directly in the /core/components folder. Beside others, this has the advantage that the plugin can easily be tested in several different MODX versions without creating multiple copies in parallel. How do you develop your modules in ProcessWire? Directly in the /site/modules directory? Is there a best practise? Greetings, Martin

This was the problem! It now works as expected. So each file (.module.php, .info.php and .config.php) need to be namespaced. Thanks all for your help!

OK --- this is new. ? Can't remember I saw other files than .module.php namespaced in other modules...

CookieManagementBanner is not a process module (which my module is). And yes, I namespaced the module file. Here is the complete package, maybe somebody could have a look and tell me what's wrong? ProcessGoodNews.zip

The problems go on: The module can now be installed and the config options are available, but if I go to the GoodNews page or try to uninstall the module, an error message is displayed: I took the code directly from Ryans GitHub repo: https://github.com/ryancramerdesign/Helloworld/blob/master/Helloworld.config.php and the documentation says: In order to make a string translatable in your template or module code, you just have to wrap the original string in a $this->_() or __() function call: $out = $this->_("Live long and prosper"); // syntax within a class $out = __("Live long and prosper!"); // syntax outside of a class If I change the translatable strings to _( it works. Using $config = array() in .config.php we are outside of a class or not? Is there a difference in using the $config = array() approach in process-modules?

I changed the .config.php file to uses the $config = array() approach and now it works. This is very strange. Thanks, @adrian