Leaderboard

We've made a lot of progress on our generator. We're now using Gulp to automate everything, but still, it ties in strongly with our PW Boilerplate. You'll likely find a lot of useful things in our generator that you can take over. Some useful things: automatically downloads the latest PW automatically gets a few PW Modules we use in all projectsMarkupSimpleNavigation ProcessRedirects MarkupSitemapXML install npm and all the dependencies in the Gulpfile initialises bower The generated Gulpfile has a bunch of useful utilities: browsersync sass and coffee compilation asset revisioning for production cache busting (like fingerprinting in Rails apps) rsync utilities Instead of bash scripts being run, we've opted for a small Node app for better cross OS support. Feel free to fork it, and add and remove as you see fit.

Hi all, today I stumbled upon yeoman and went searching for a PW generator. Larry Botha mentioned in a side not in his thread about MVC template approach that he has put a yeoman generator for PW together. I test installed it and it is working great. Pretty fascinating how quick we can setup a PW project with yeoman. This definitely can be a great timesaver. Larry's generator sets up a pretty opinionated PW install with his MVC structured fixate template and KSS etc. It would be great if we could have an unopinionated version that gives us a clean PW install. We could add options to the generator for installing a choice of boilerplate templates like the blank template, Foundation, Bootstrap, Blog etc. Just wanted to get your opinion on this. If any of you are interested, we could pull something together. Cheers Gerhard

justb3a's great ModuleDownloadCommand has just hit the develop branch! Next, I'll try to incorporate Nico's module generator, and then both new Commands will be released as 0.4.0 @horst: Thanks for sharing your approach! Since the Readme and this topic's start post is getting bigger and bigger I'll set up a dedicated microsite for wireshell doc and best practices like these.

Another new option added to the dev branch! The old "Overwrite" edit mode is now called "Replace" and there is a new Overwrite mode that updates the content of fields of existing pages. An example use case would be to allow editors to periodically upload a CSV file to update certain fields in all child pages while leaving other fields intact. To make this happen you would utilize the Field Pairings option so their import would only edit the specified fields.

Macrura and I have put together a more definitive version of the editable page field which I will post to the module directory as soon as I get a chance. I agree, however, that a "page table meets page field" field is a must down the line. I have a scenario with a client right now where this would be the only ideal solution. The scenario: Client adds a company page with details about the company. Each company can have several contacts associated with it, such as a primary contact and an administrative contact. The user should be able to see some information about each contact at a glance (like a PageTable), and needs to be able to select a contact that already exists (like a Page field) but needs to be able to create and populate new contacts and have them automatically selected (like a PageTable).

That's not exactly true. Repeaters do support dependencies, but only for field=value. You have to set 'useDependencies' => false in your config.php — and that can have undesired consequences. I haven't tried this, but instead of setting that in the config file, it might be possible to set it on a per-template basis using a hook.

Added registration with confirmation email and activation link I've mainly followed this thread https://processwire.com/talk/topic/4066-activate-user-account-via-email/ The user who registers is created with the unpublished status: $new_user->addStatus( Page::statusUnpublished ); and when she/he clicks on the confirmation link received via email the status turns published: $activate_userid = $this->sanitizer->text( $this->input->get->userid ); $activate_hash = $this->sanitizer->text( $this->input->get->hash ); $this_user = $this->wire('pages')->find( "template=user,id=$activate_userid, include=all" )->first(); if ( is_object( $this_user ) && isset( $this_user->id ) ) { if ( strcmp( $this_user->activation_key, $activate_hash ) == 0 && $this_user->is( Page::statusUnpublished ) ) { echo __( "Thank you! Your account has been activated!" ); $activate_user = $this_user; $activate_user->of(false); $activate_user->activation_key = "0"; $activate_user->removeStatus( Page::statusUnpublished ); $activate_user->save(); } } In the attached pic the configuration page which allows to specify email's fields. As a side note, I've initially tried to get the user with his username: $this->wire( 'users' )->find( "name=$activate_username, include=unpublished" ); but the returned object was really complex and completely protected, so I've changed the behaviour using the user's id.

@jordanlev, I have read the last couple of posts you've written about your experience with ProcessWire in respect of your 'custom/complex' application and I do understand some of your frustration. However, I think some of your assertions may convey the idea that somehow PW corners you to do things in a certain way. Or that ProcessWire is a one-size-fits-all for all kinds of needs. For instance, PW is not and has never claimed to be an e-commerce application. Whilst you can certainly build and e-commerce site with PW (or even a product - there's one in the mix actually) your end product depends on how you code your application. I am not in any way questioning your coding skills; just trying to point out that PW is mainly a tool....what you do with that tool is really up to you. However, for some jobs, you are better of using tools better suited to those jobs, e.g. foxy cart, etc for e-commerce sites. Secondly, the adage that everything is a page does not mean that you should always take that approach. Again, there are examples here in the forum. You can use custom tables, designed just the way you want. Although using pages gives you access to the PW API, you are not tied to using them. And here is another strength of PW...you can use custom tables with ease, and either use custom CRUD code or PW $database and $db to access them (though with some limitations) and you are good to go. Not many CMS will allow you to do this...at least not with ease Thirdly, I disagree with the notion that PW is not up to the job when it comes to custom applications. There's a couple of examples of custom apps built using PW right here in the forums. I don't agree that its only good in terms of the 'templating and the front-end portion of the site'. So this statement "ProcessWire had nothing to offer me on the "custom dashboard application" side of things." is not exactly true. PW allows you to build your own custom dashboards by not getting in your way. Yes, it may not offer a turn-key experience (although there are one or two dashboard modules) but it allows you to build your own without bothering you. Fourthly, PW does not demand that you use its inbuilt 'input' modules or as you put it 'a rather clunky editing interface' when building custom apps/modules with it. In fact, that's one of the strengths of PW. You can build your custom apps using custom code or extend other libraries and PW will happily let you. The 'input modules' are used internally by PW but are also there for convenience if you need to use them, but you are certainly not tied to using them. Build your complex forms by hand or another library? PW doesn't care nor will it get in your way. Anyway, if I misread your posts, I apologise. However, you've made the same assertions twice or thrice and I thought they needed clarification/qualification especially for newbies. Hope I haven't derailed the original discussion

Here I go again not reading things properly....I was obviously talking about something different....Thanks for the correction @LostKobrakai

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.

Funny, just yesterday I startet looking into yeoman, because I wanted to automate initializations of my projects in a more stable manner. Sure I have some shell scripts, aliases and functions set up to help me with that but, shell scripting is hell (at least for me, althoug I use zsh). Especially when it comes stuff other than copying and renaming files. Working with strings, numbers or templating ... yuk. I have not yet looked at Larry's generator in detail, but sure we can lear from it. I have yet to create my first real generator but I'd love to participate. I suggest that we collect ideas, what and how things should be done by the generator, and you @gebeer collect them in your original post. Off the top of my head I think it would be cool if module installations/or at least module downloading could be integrated somehow. Either by asking for the module name, and the generator then searches through the modules repo, or via config file. Can we event put that info in the package.json? I do think so. module installations renaming of the example files like htaccess and so on modifiying the htaccess via questions, that would require the htacces file to be in template form, so that directives can be included or excluded downloading of pw, asking for dev or master

This module facilitates quick batch creation (titles only or CSV import for other fields), editing, sorting, deletion, and CSV export of all children under a given page. You can even provide an alternate parent page which allows for editing of an external page tree. http://modules.processwire.com/modules/batch-child-editor/ https://github.com/adrianbj/BatchChildEditor The interface can be added to the Children Tab, or in a new dedicated tab, or placed inline with other fields in the Content tab. Various modes allow you to: Lister - Embeds a customized Lister interface. Installation of ListerPro will allow inline ajax editing of displayed fields. Edit - This allows you to rename existing child pages and add new child pages. It is non-destructive and so could be used on child pages that have their own children or other content fields (not just title). It includes the ability to quickly sort and delete pages and change page templates. Also allows full editing of each page via a modal dialog by clicking on the page name link. This is my preferred default setup - see how it replaces the default Children/Subpages with an easily addable/editable/sortable/renamable/deletable list. Note that the edit links open each child page in a modal for quick editing of all fields. Add - adds newly entered page titles as child pages to the list of existing siblings. You could create a list of pages in Word or whatever and just paste them in here and viola! This screenshot shows the editor in its own tab (name is configurable) and shows some of the CSV creation options. Update and Replace modes look fairly similar but show existing page titles. Update - Updates the titles (and any other fields if you enter CSV data) for the existing pages and adds any additionally entered pages. Replace - Works similarly to Add, but replaces all the existing children. There are checks that prevent this method working if there are any child pages with their own children or other content fields that are not empty. This check can be disabled in the module config settings, but please be very careful with this. Export to CSV - Generates a CSV file containing the fields for all child pages. Fields to be exported can to fixed or customizable by the user. Also includes an API export method. Populating fields on new pages In Add, Update, and Replace modes you can enter CSV formatted rows to populate all text/numeric fields, making for an extremely quick way of creating new pages and populating their content fields. Predefined Field Pairings Like the field connections setup from Ryan's CSV Importer, but defined ahead of time so the dev controls what columns from the CSV pair with which PW fields. This is especially powerful in Update mode giving editors the ability to periodically import a CSV file to update only certain fields on a entire set of child pages. These pairings also allow for importing fieldtypes with subfields - verified to work for Profields Textareas and MapMarker fields, but I think should work for most others as well - let me know if you find any that don't work. Access permission This module requires a new permission: "batch-child-editor". This permission is created automatically on install and is added to the superuser role, but it is up to the developer to add the permission to other roles as required. Config Settings This module is HIGHLY configurable down to setting up custom descriptions and notes for your editors. You define one config globally for the site and then optionally you can define completely custom configurations for each page tree parent on your site. There are too many settings to bother showing here - you really just need to look through all the options and play around with them!

Hi, first of all I'd like to thank you all, and in particular Ryan, for this great project which is ProcessWire. I'm using ProcessWire for the first time and frankly I'm finding it quite good, despite my lack of experience. Anyway, I created this post to introduce you the following module, on which we are working, and I'd like to share it with the community which could benefit from it and maybe improve it. You can find the module here: https://bitbucket.org/mauro_mascia/processwire-social-login/ Basically, it adds the ability to allow a social login (using the HybridAuth library - https://github.com/hybridauth/hybridauth) as well as a standard login, user profile and registration. The module is clearly not complete and it is at its first stage of maturity and I hope you can forgive me if I have not fully complied with the PW best practices

Nice catch, but no

My occam’s razor guess would be that PW couldn’t have anything to do with this at all, since it’s all server side, while Chrome only gets to see the final product. So it would have to be some local caching that Chrome does on its own. This admittedly dated SO thread shows a couple of settings that may be of interest: http://stackoverflow.com/questions/5690269/disabling-chrome-cache-for-website-development

Nice Great job! Some parts are not that ugly. After all, adding a new skin is a minor thing compared to the whole development.

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.

i would definitely check with the hoster and see if they are blocking bing; i would also follow @cstevensjr advice and try the sitemap;also try and see if you can specifically set the search domain as www version

seems pretty cool. The backend tabs and listings are custom code or based on some existing modules ? could you give me some beginner advices ? I try to code something similar for my own usage and at the same time learn a lot of ne processwire and code skills

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

@mr-fan has already mentioned this, but to clarify, the Field Pairings option is something that is configured on a page by page basis. You set these for the parent page and then all the children that are created from the import follow the defined rules. So I think this allows for the different CSV schemas you are talking about. I thought about doing it per template, but I actually thought that per page was more flexible and natural because afterall this modules is all about creating and the editing child pages of the current parent. I guess this might be a problem if your parent page's template allows for more than one child template. I don't think I have ever allowed this on any of my PW sites, but I am sure some of you do. This module allows the editor to choose the template for new child pages (if the template family settings allow multiple templates or there are no restrictions at all), so if the demand is there, I should be able to implement something along these lines, but please test the current setup first to see if it already suits your needs.

Hey Horst, I tried to save my thumbnail settings and got this error: Session: Table 'xxx.field_sliderImage' doesn't exist SELECT pages_id,count(pages_id) FROM field_sliderImage GROUP BY pages_id ORDER BY pages_id So I looked into your code and found this one in FieldtypeCroppableImage.module:339: $TABLE = 'field_' . $field->name; // TODO: name to lowercase To answer your question: Probably. Currently working with a hoster who's obviously case sensitive. I saw the table name was field_sliderimage (all lowercase) and edited your code to this: $TABLE = 'field_' . strtolower($field->name); // TODO: name to lowercase N: Yes! ;-) And yep, it worked! noodles

Now to think up the most biased comparison in favor of PW re: time to set up

Current behavior is that you can set general setting for different templates and set own settings on a per page basis. This module is getting the absolute best solution to handle import CSV data to pages. Even it could be easy prepared to be used by clients without to much headache about posible damage... I wanna thank you adrian - this evolution of the module is a really big one!

Well I think I solved it today using text-overflow property: http://jsfiddle.net/gryzzly/cbppL/

Do you have a template file for the page, eg: templatename.php in the templates directory? Edit by Nico: Templates directory is /site/templates/ You can learn more about templates here: https://processwire.com/docs/tutorials/hello-worlds/page2

Major feature enhancements currently available on dev branch - https://github.com/adrianbj/BatchChildEditor/tree/dev The new config settings rely on the new "OR" options for inputfield dependencies, so this new version requires the dev branch of PW. Please test carefully and let me know if you have any problems or suggestions! Thanks to ideas, testing and feedback from @mr-fan this module now supports the following new features which mostly focus on enhanced, customized CSV importing for page creation: Custom configurations on a page by page basis (on the Settings tab) - you can set up a default config in the module settings, but override these for any parent page. Ability to set up custom titles, descriptions, and notes so the interface can be tailored to the exact needs of your editors with page/template specific examples. Option to have editing tools in a new tab, rather than in the Children Tab. Alternatively, you can now replace the current Children/Subpages list in the Children tab. CSV upload and link to external URL, in addition to the existing textarea manual / paste entry. Ability to predefine "field pairings". This means that editors can upload/link to CSV files that may contain more fields than you want to import, or there are fields in your template that are not included in the CSV. Think of it as a predefined version of the "Connect the Fields" functionality in Ryan's "Import Pages from CSV Files" module. This makes complex imports foolproof for non-tech site editors. I think in most cases this could now replace the need for custom scripts for editor friendly, regular CSV importing. Despite the added options, it should be just as simple to setup as before if you don't need any of the extra features. Here are some screenshots to give you an idea. Shows a very simple, restricted CSV upload setup with custom title, description, and notes fields. Note that it is in a custom labeled new tab, rather than under the Children tab. All the new parent page specific config settings. Note in particular the "Field Pairings" section where you define CSV column numbers to match PW field names. The only thing I am having some issues with is persistence of some error messages - if you have setup some options that conflict or otherwise cause a specific error to be sent, you may need to save the settings a couple of extra times to make the message go away - not sure if this is a PW bug or what at the moment, but it shouldn't affect functionality.

...and in the documentation as well: http://processwire.com/api/selectors/#or-groups Edit: sorry, this is a different matter; ignore my post...

since 2.5.24 OR-dependencies are possible: https://processwire.com/blog/posts/processwire-core-updates-2.5.24/#field-dependencies-upgrades

Finally I have had time to download it. Its simply fantastic and a lot of fun! Regarding the windows users I share how I have set it up. Its only a bit slightly different than the very good explanation here from @marcus and @Mike_Anthony. I have done installation step 1 and 2, but not step 3. Instead of adding something to my path I simply created a single wireshell.bat file that I put somewhere into my already existing system path. I also have no PHP directory accessible through the system path, because I use minimum 5 different PHP versions (3 for CLI and 2 with the local Apache). If there were one in the system path this can lead to weird behavior of PHP, at least with the old PHP 4 that I need for older CLI tasks. My wireshell.bat looks like @ECHO OFF SET phpexe=C:\bin\php-54\php.exe SET phpparams=-c C:\bin\php-54\wireshell\ SET wireshell=%appdata%\Composer\vendor\wireshell\wireshell\wireshell TITLE WIRESHELL :: %CD% "%phpexe%" %phpparams% "%wireshell%" %* TITLE %CD% With the phpparam -c I have specified a directory where the php interpreter has to pickup its php.ini. I have one setup that is different than I need with other CLI scripts. I also could have linked to the php directory what is running under apache. But unfortunately I switch this between php 5.3.8 and 5.4.x for modules testing currently. (and composer and wireshell needs minimum 5.4.0) That with setting the title in the cli windows is nice if you have running several tasks. When hovering over the stacked icons on the taskbar, you can see which one is in "WIRESHELL mode" and which one is finished.

Ok here we are - fixed version number. Thanks cstevensjr, done. @BernhardB - don't worry APP ID/Secret are fakes

yes, the helloworld tutorial is a good starting point! thereafter you can easily setup a kind of "sub-template-system" (how you call it) like this: this is the "default intermediate edition" profile - just install this on your dev-environment and read the files _main.php, _init.php and basic-page.php and you will understand how easy it is to setup very flexible and custom things with processwire! also welcome to the forum ps: actually you would only have to append "<?php" on top of _init.php and all your template files - everything else is ready to use!

Go to the "More Reply Options" button (which is to the right of the Post button)

I've just started a new project and decided to test/use Wireshell. After I had successfully created a new project I missed the opportunity to download modules. You've received a new pull request. Maybe you have some time to test (and hopefully implement) it.

Hi all, I've just pushed a new fully responsive site profile to Github: Unsemantic Site Profile for Processwire 2.3 After having tried seven zillion responsive grid systems, boilerplates, frameworks etc. I finally opted for Unsemantic Grid System. Mainly because it supports IE7, is lightweight and includes Compass/SASS. I've designed the profile as a starting point for development according to my needs. This includes almost no styling, an easy-to-use solution for placeholder images and three teaser boxes on the front page. In addition, I converted the .sass files that come with Unsemantic to .scss because I like the syntax better. Glad if you give it a try and find it an improvement for your workflow. You can see a preview here. Download from Github: https://github.com/christophlieck/UnsemanticSiteProfile

Not hard at all - fun, as I'm dealing with amazing tools (ProcessWire, Symfony, Composer packages) and learn a lot on the way

On Windows, it installs to C:\Users\<user>\AppData\Roaming\Composer\vendor\wireshell\wireshell\ ... Not sure what the best way of making this global is, other than making a batch file look specifically in that directory. I must admit: I'm not a composer fundi, but I get the basics... Update: In fact, if I run wireshell directly from the above directory (using php wireshell), it doesn't run because it's looking for vendor/autoload.php in that directory too. If I run the nasty php vendor/wireshell/wireshell/wireshell from the C:\Users\<user>\AppData\Roaming\Composer directory, it works. Phew, quite messy. But, like I said, I'm no fundi - there must be a better way to do this.

Big update! Version 0.3.0 comes with: a new "NewCommand" provided by HariKT! Big thanks again. This contribution should lead to a better workflow with Wireshell since it opens up the possibility to install PW via command line in a convenient way A command for creating fields A command for assigning fields to existing templates A generic backup command (DB dump) Commands for en/disabling modules (downloading them via Wireshell is still on my bucket list) A little command outputting the currently installed ProcessWire version An unified approach to naming commands and classes: entity:verb, so for example user:create I dropped the "(Experimental)" from the topic's title Read more about the available new commands and their options in the readme. If you have an older version of Wireshell installed, make sure you "$ composer update" it in order to get the new dependencies. And we're on packagist now: https://packagist.org/packages/wireshell/wireshell

u message cumes frm.sessions dir. but i delete /site/assets/sessions/ and ,it remake.it no error mabe u /site/assets no writtable ? i testted w/vershion 2.5.21 for.my grndmoms nudist marchingband.site mabe u need.upgrade ?

Below is some full working code for a process module that manages pages of a specific template. To install it, create a new folder in your site's "site/modules" directory called "ProcessCustomPageAdmin", then inside that new directory create a file called "ProcessCustomPageAdmin.module" and paste the code below into that file. Then install from your site's admin back-end (you'll need to "refresh" the directory to get PW to recognize it, just like with all new modules you try to install manually). A few things to note: The "create" and "delete" actions respond to GET requests, which is possibly dangerous. The "create" action is probably ok because this is behind your admin backend so you don't have to worry about webcrawlers accidentally hitting the pages. But depending on how important the data in the pages is, you might want to make it respond to a POST request only and put up some kind of confirmation. I was trying to keep things as simple and focused on your question as possible so I didn't include any of that stuff. There is no functionality to sort the pages. You need to output your own markup for the list view if you want to achieve this and then wire up your own "sort" action and set up JQueryUI sortable on the list display... way outside the scope of this forum topic here. You'll want to output this snippet of CSS on that page to hide the id that gets outputted for the CKEditor to function. Create a "ProcessCustomPageAdmin.css" file in your module directory and PW will automatically load it for you.​#Inputfield_PageIDIndicator { display: none; } Last but not least, you need to change the $template_name and $parent_page_selector variables in the module class to suit your needs. Best of luck! <?php class ProcessCustomPageAdmin extends Process { public static function getModuleInfo() { return array( 'title' => 'Custom Page Admin', 'summary' => 'Dashboard interface for managing pages', 'version' => '100', 'author' => 'Your Name Here', 'permission' => 'page-edit', 'page' => array( 'name' => 'custom-page-admin', 'title' => 'Custom Page Admin', ), ); } private $template_name = 'your-template-name'; private $parent_page_selector = 'template=parent-page-template'; //determines where new pages are added under (can be any page selector) public function execute() { $table = $this->modules->get('MarkupAdminDataTable'); $table->setEncodeEntities(false); $table->setSortable(false); $pages = $this->pages->find("template={$this->template_name}, sort=sort"); foreach ($pages as $page) { $table->row(array( htmlspecialchars($page->title), "[<a href=\"{$this->page->url}/edit?id={$page->id}\">Edit</a>]", "[<a href=\"{$this->page->url}/delete?id={$page->id}\">Delete</a>]", )); } $table->action(array('Create New Page' => "{$this->page->url}/create")); return $table->render(); } public function executeCreate() { $page = new Page(); $page->template = $this->template_name; $page->parent = $this->pages->get($this->parent_page_selector); $page->title = 'Untitled Page'; //note that we don't need to set a name because it is autogenerated (as per the parent template settings) $page->save(); $this->session->redirect($this->page->url . '/edit?id=' . $page->id); } public function executeEdit() { if ($this->config->ajax) { return $this->modules->get('ProcessPageEdit')->execute(); //ajax-y form widgets (e.g. image uploader) need to be handled by the real ProcessPageEdit module (but for some reason they look to the form action for their ajax url instead of always going to /[admin]/page/edit) } $page = $this->getPageById($this->input->get->id); $action = "{$this->page->url}/edit?id={$page->id}"; $form = $this->buildPageEditForm($action, $page); if ($this->processPageEditForm($form, $page)) { $this->setPageNameFromTitle($page); $this->session->message('Page saved.'); $this->session->redirect($this->page->url); } Wire::setFuel('processHeadline', $page->title); return $form->render(); } public function executeDelete() { $page = $this->getPageById($this->input->get->id); $page->delete(); $this->session->message('Page deleted'); $this->session->redirect($this->page->url); } /*** HELPER FUNCTIONS ***/ private function getPageById($id) { $id = (int)$id; if (empty($id)) { throw new Wire404Exception('Missing or invalid page id'); } $page = $this->pages->get($id); if (!$page || ($page->template != $this->template_name)) { throw new Wire404Exception('Unknown page (it may have been recently deleted or had its template changed)'); } return $page; } //pass in empty string for cancel_button_url to not include one private function buildPageEditForm($form_action, $page, $include_save_button = true, $cancel_button_url = '') { //code inspired by: https://gist.github.com/somatonic/5011926 $modules = wire('modules'); $form = $modules->get("InputfieldForm"); $form->method = 'post'; $form->action = $form_action; foreach($page->getInputfields() as $input_field) { $form->add($input_field); } if ($include_save_button) { $form->add($modules->get("InputfieldSubmit") ->set('name', 'submit') ->set('value', 'Save') ); } if (!empty($cancel_button_url)) { $form->add($modules->get("InputfieldButton") ->set('name', 'cancel') ->set('value', 'Cancel') ->set('href', $cancel_button_url) ->set('icon', 'times-circle') ->set('class', 'ui-button ui-widget ui-corner-all ui-priority-secondary') //gives it a faded look ); } //IMAGE UPLOADER WIDGET NEEDS THIS TO FUNCTION PROPERLY (note that the "name" is only so we can hide this via CSS... but the only thing the image uploader needs is the p tag): $form->add($modules->get("InputfieldMarkup")->set('name', 'PageIDIndicator')->set('value', "<p id='PageIDIndicator'>{$page->id}</p>")); //CKEDITOR IMAGE BUTTON NEEDS THIS TO FUNCTION PROPERLY: $form->add($modules->get("InputfieldHidden")->set('name', 'id')->set('value', $page->id)); return $form; } private function processPageEditForm(&$form, $page) { //code inspired by: https://gist.github.com/somatonic/5011926 $input = wire('input'); if (!$input->post->submit) { return false; } $form->processInput($input->post); if ($form->getErrors()) { //pass true to clear the errors return false; } $page->setOutputFormatting(false); foreach($form as $field) { $page->set($field->name, $field->value); } $page->save(); return true; } private function setPageNameFromTitle($page, $append_number = null) { $name = wire('sanitizer')->pageName($page->title); if (!is_null($append_number)) { $name .= '-' . (int)$append_number; //yes, we want to explicitly cast to int and then implicitly cast back to string (via concatenation) } if ($name == $page->name) { return; //avoid the page finding itself as a dup in the query below } else if (wire('pages')->count("parent=$page->parent, name=$name")) { $append_number = (int)$append_number + 1; $this->setPageNameFromTitle($page, $append_number); } else { $page->set('name', $name)->save(); } } }

Great, then I can try to help you. I'm certainly interested in the steps 4-7, that you described in your OP. It would help even more if you could add the timers around the different phases of your process, like this: $timer = "newsletter_debug"; Debug::timer($timer."1"); // Phase 1 code Debug::saveTimer($timer."1", "Phase 1"); Debug::timer($timer."2"); // Phase 2 code Debug::saveTimer($timer."2", "Phase 2"); Debug::timer($timer."3"); // Phase 3 code Debug::saveTimer($timer."3", "Phase 3"); Debug::timer($timer."4"); // Phase 4 code Debug::saveTimer($timer."4", "Phase 4"); If you can enable debug-mode, then you could copy the timers directly from your admin site. If not, then you could just save them to disk. You can do this with file_put_contents(wire('config')->paths->logs."/timers.txt", var_export(Debug::getSavedTimers(),true), FILE_APPEND); Then just surf to your logs -folder (site/assets/logs) and post us the contents of the timers.txt -file.

If anyone is interested, this is a realtime commenting system I'm implementing using it. It's very alpha and I'm not sure if I'll ever to publish it as a module, but it was very easy to implement. The comments are posted using AJAX and the simple api router I use calls a function to post the comment. This function in turn creates a Pusher event in PHP and sends the data to Pusher, which sends it back to the client (this is all push). There are a few lines of javascript waiting for the event to trigger, which in turn renders the comment that was send back from the server through Pusher. I'm using all native PW fields and templates for this, this allows me to have caching enabled on the server. Each time a comment is posted, the discussion is re-cached, so if someone loads a page, it should get most of what's supposed to be there, then any updates are done client-side.

I might have something baking regarding user groups and simplified access management.