SteveB

Hey thanks for the support. Yes I've refreshed many times. Loading the module from init.php I can call $my_module->intervene() and get a reaction. Calling the module's init() from there does not get the function hooked though. It's not my first choice but I can get the functionality I want by modifying ProcessPageAdd.module this way: $this->form = $this->buildForm(); $my_module = wire('modules')->get('HookPageAdd'); //module that wont hook $my_module->init(); $this->form = $my_module->intervene(null, $this->form); The last three lines being my addition to replace the broken hook. The call to init() readies some configuration data. Then in the module I just added a second optional argument to pass the form through instead faking an event object. Calling it this way, everything works. I should be able to run this modified one as a site module. I've done that before. Nice feature of PW.. Still hoping to revert this back to normal do-it-with-a-hook usage someday. It's a mystery to me why it won't hook. The module will help manage what can be added where without having to and maintain otherwise identical templates just for the sake of having different allowed children. It has an alternative configurable way to determine allowable templates for adding pages based on the path of the parent page specified in the add request. You can even do a regex match to the original parent path and assign a substitute path. It auto generates a page name and rebuilds the step-1 page editing form with name and template in hidden fields showing only the Title field. Another module, HookAfterSave, finalizes things, sometimes giving the page a different name and parent such as an A to Z folder as parent and normal name string both based on title from the user.

Netcarver, Good idea to put die() in init. Made no difference. So now the question is why did my module not get loaded? But you're off track in the other comment. The buildForm() method is called. Aside from messages in the log from ProcessPageAdd before and after calling it (see last of the code snippets), the next thing I see on the screen is the form.

I'm not sure what else there is to check in order to find out why a hook I'm setting has no effect. The intent is to modify the form that is step 1 of adding a new page Just for test I made the function the hook should call die() but execution gets right to where the buildForm is run, continues after, and the form appears. It's clear my function isn't called. I've uninstalled (deleted the compiled file too just in case) and reinstalled the module. What else can I check? Code snippets: class HookPageAdd extends WireData implements Module, ConfigurableModule { public static function getModuleInfo() { return array( 'title' => 'HookPageAdd', 'version' => 1, 'summary' => 'Hook to intervene during adding of new pages.', 'singular' => true, 'autoload' => true ); } ..... public function init() { // init() is called when the module is loaded. $this->addHookAfter('ProcessPageAdd::buildForm', $this, 'intervene'); $this->enabledPaths = $this->data['enabledPaths']; } ..... public function intervene($event) { die(__FILE__.'@'.__LINE__.' '.__FUNCTION__); } ..... //Added messages before and after where ProcessPageAdd uses the function I'm hooking $this->wire('log')->message(__FILE__.'@'.__LINE__.' '.__FUNCTION__); //SB//////////////////////////////////////// $this->form = $this->buildForm(); $this->wire('log')->message(__FILE__.'@'.__LINE__.' '.__FUNCTION__); //SB//////////////////////////////////////// Using 3.0.10

Any ideas about how to get the one-step add Robin was asking about? Maybe add a setting in your module for name format. Greedy of me to ask but you seem to be a couple steps ahead of me on this.

In the end I did a wire('db')->query($qry). In order to get the three page ids and two sort strings I needed from the id of the mark_type. There were 6 joins. Then there was the issue of making pagination markup since I was no longer getting that for free by doing a normal page->find. Used $pages->find($selector)->count; with a very simple selector just to get the total number of pages being shown. Then made up this function (based on a 2013 Soma post) to use MarkupPagerNav directly to make the pagination. function pagination($page, $limit, $total){ $baseUrl = $page->url; if($seg = wire('input')->urlSegment(1)) $baseUrl .= $seg . '/'; $start = (wire('input')->pageNum - 1) * $limit; $pagerNav = new ProcessWire\PagerNav($total, $limit, wire('input')->pageNum); $pager = $pagerNav->getPager(); $last = count($pager) - 1; foreach($pager as $k=>$link) { $str = ''; if($k == 0) $str = 'MarkupPagerNavFirst MarkupPagerNavFirstNum'; elseif($k == $last - 1) $str = 'MarkupPagerNavLastNum'; elseif($k == $last) $str = 'MarkupPagerNavNext MarkupPagerNavLast'; if($link->pageNum == wire('input')->pageNum) $str = 'MarkupPagerNavOn ' . $str; $classStr = empty($str) ? '' : " class='{$str}'"; if($link->type == "separator") $item = '…'; else $item = "<a href='{$baseUrl}page{$link->pageNum}/'><span>$link->label</span></a>"; $pagerMarkup .= "\t<li{$classStr}>$item</li>\n"; } // output paginator markup return "<ul class='MarkupPagerNav'>\n" . $pagerMarkup . "</ul>"; } (using PW 3.0.10)

A page of the mark template always has a page of the pattern template as its parent. That pattern page has a page field which is either empty or, more often, points to a page of the maker template. pattern: has page field 'maker' to select a maker has children which are marks mark: is child of a pattern has page field 'mark_type' So if we were building a query we'd be needing to do some joins to get from the mark (chosen by it's mark type) to it's parent's page field (giving us a maker id) to the name of the maker. Maybe that's beyond what selector syntax can do. I could do it in the template file with MySQL and a bunch of joins.

I'm trying to select pages based on one of the page's page fields (easy) but want to sort results by the name of a page pointed to by a page field on the page's parent. We're dealing with four templates... maker: has a name mark_type: has a name pattern: has page field 'maker' to select a maker has children which are marks mark: is child of a pattern has page field 'mark_type' Select all the marks of a certain mark_type, sort by name of the parent's maker $pa = $pages->find("template=mark, mark_type={$markId}, sort=[parent.maker].name, limit={$limit}, start={$start}"; Nothing I've tried for the sort works. Is there way? In some case there will be as many as 1500 matches so I don't want to have to get them all and then reorganize them in order to show 25 on a paginated page.

Posting this in case anybody else has been tinkering with this module or if "updates out soon" mentioned a while back are getting closer. Thought I'd give this a try in 3.0.10 and adapt it to my needs. The only thing needed to get it working was to change some PHP short tags (<? ) in MarkupActivityLog.inc. I've added a config variable for selecting fields to ignore, using it in changesToJSON(). Figured I'd ignore any fields that are not supported yet and do something about them later. One thing that isn't working is the New vs Old display for rich text (CKEditor fieldtype). The information is there in the markup but clicking the tabs doesn't toggle their visibility. You always see the New data.

Another thing you can do is hook Pages::added (only called for new pages, not when re-saving existing ones) and in your hooked function set the page name to the page id, which is already part of the page at that point.

Here's what I did. /* if(strlen($this->input->get->include) && $this->input->get->include !== 'hidden') { if($this->input->get->include === 'all') { if(!$this->user->isSuperuser()) $this->errors[] = "The option 'include=all' is only allowed for administrators"; } else { $this->errors[] = "Unrecognized value for 'include'"; } } */ //SB replaces above which FileCompiler thinks is a including a file $ginc = $this->input->get->include; if(strlen($ginc) && $ginc !== 'hidden') { if($ginc === 'all') { if(!$this->user->isSuperuser()) $this->errors[] = "The option 'include=all' is only allowed for administrators"; } else { $this->errors[] = "Unrecognized value for 'include'"; } }

There are pluses and minuses to cleaning out resolved issues. That clutter is useful when you're stumped and can't find a clue in the forum. Github search will find something and whether it's an open issue or not it usually is informative. In a perfect world we might do things differently of course but this sort of thing (and my new best friend Tracy) helped me figure out some transition to V3 stuff recently.

Upgrading PHP from 5.4.29 to 5.6.18 solved the problem.

I'm curious what the PHP version is on the server where you are having trouble.

I keep coming back to the fact that the installer didn't complain about anything but a freshly installed "blank" profile immediately segfaults. I've not seen an explicit set of server requirements for PW 3 and it's too early to know the edge cases well, so I'll suppose it's possible that something about PHP 5.4.29 doesn't work with the new Namespaces and PSR2 techniques in PW 3. It's a flimsy theory though. On Monday I'll upgrade the PHP to 5.6 and see what happens.

I'm installing brand new 3.0.10 from this morning with a site profile. Server has PHP 5.4.29, MySQL 5.1.73 and there's a site on the same server running 2.7.3 just fine. Edit: Tried this with both 3.0.10 and 3.0.8 with identical results. Seems like some general 3.x requirement not being met by my server but the install script doesn't find anything to complain about. I tried this a couple different ways, first with a profile saved from a 3.0.8 site and then after removing everything, with the "blank" profile that comes with 3.0.10. In both cases after the step where you enter passwords I get a mostly blank screen with a "Connection Reset" message. The install did happen though. The database is populated. The first time I did it there was an error_log file containing this: [05-Mar-2016 10:35:52 America/New_York] PHP Warning: register_shutdown_function(): Invalid shutdown callback '' passed in /home/test/public_html/v3010/wire/core/ProcessWire.php on line 176 Here's that code: // If script is being called externally, add an extra shutdown function if(!$config->internal) register_shutdown_function(function() { if(error_get_last()) return; $process = $this->wire('process'); if($process == 'ProcessPageView') $process->finished(); }); $this->setStatus(self::statusBoot); } Any ideas? I tried commenting out that block of code but that didn't make any difference. Edit: It gets as far as this line in index.php and fails there: $wire = new ProcessWire($config); Edit: It's not the install process. I FTPd the site up there, copied the data to the database, had the same problem. Apache error log says Segmentation fault

Before PW my approach was to keep data of the content and data about the system in separate tables (and files). That helped a lot. Given PW's great API, migration scripts is the way to go. I'm not there yet but I've been doing massive data imports using scripts and API and am very pleased with how well that works. The challenge is keeping track of what you did while trying out different approaches and refining things. Probably makes sense sometimes to have Sandbox, Staging, Live. Do the messy creative work in the sandbox. Reproduce those changes deliberately and systematically on a fresh copy (Staging) using your scripts. Repeat as needed. Then (make a backup and) apply scripts to Live.

Just the other day export/import for templates and files partly worked but many settings such as allowable template and parent for page fields were missed and a few fields were not assigned to all of the templates they belong on. I tried Migrator once (not recently) and it scrambled the page tree badly. To be fair, both of these episodes happened on migration attempts between different PW versions. People bring up Migrator in topics like this but last time I looked I didn't see much detail on the forum about what's working and whether it's keeping up with changes in PW. Template and field export/import from 2.7.3 to 3.0.8 saved me a lot of time but didn't fully resolve the interdependencies of fields and templates referencing each other.

Quick question: Looking at module setttings for this 1.0.0 version in a new PW 3.0 setup there are only HiDPI/Retinafy Options. I don't see any image Sizer Options, as shown a few posts back. Is this normal? Are they somewhere else? Thanks.

Just wanted to say that's working for me as well. I'm familiar with the wire( ) syntax but have not noticed wire('all') and wire('*') before. Thanks. Edit: Starting to make some progress with PW3 now. This Namespace FAQ (php.net) is helpful.

Good thought but no luck. I was just reading up on the compiling and namespaces. Mostly in Ryan's blog posts. So far I'm still stuck at that same spot. Could try reverting to what I used to do before Spex but that would be a time consuming rewrite. Might be best to linger on 2.7.3 a while but wanted to make the jump now because I'm at a good spot for that otherwise. Wondering, do I have to put namespace markup in all the little files for partials and stuff that Spex uses?

Do I have to abandon Spex if I go to Processwire 3? It does not seem to work. Not for me right now anyway. See this other post.

Here's another clue. I'm using Spex with a fresh install of 3.0.8. spex.module has this: public function getTemplateVars($include_fuel=true) { return array_merge( $include_fuel ? fuel()->getArray() : array(), array('spex' => $this), array('slots' => $this->slots), $this->templateVars ); } Is that way of using "fuel" no longer supported? What should it be? Am I on the right track or is this a red herring. Error: Exception: Method ProcessWire::getArray does not exist or is not callable in this context (in /web/elastic/demo/wire/core/Wire.php line 347) #0 [internal function]: ProcessWire\Wire->___callUnknown('getArray', Array) #1 /web/elastic/demo/wire/core/Wire.php(303): call_user_func_array(Array, Array) #2 /web/elastic/demo/wire/core/WireHooks.php(555): ProcessWire\Wire->_callMethod('___callUnknown', Array) #3 /web/elastic/demo/wire/core/Wire.php(327): ProcessWire\WireHooks->runHooks(Object(ProcessWire\ProcessWire), 'callUnknown', Array) #4 /web/elastic/demo/wire/core/ProcessWire.php(471): ProcessWire\Wire->__call('callUnknown', Array) #5 /web/elastic/demo/wire/core/Wire.php(328): ProcessWire\ProcessWire->__call('callUnknown', Array) #6 /web/elastic/demo/wire/core/Wire.php(328): ProcessWire\ProcessWire->callUnknown('getArray', Array) #7 /web/elastic/demo/wire/core/ProcessWire.php(474): ProcessWire\Wire->__call('getArray', Array) #8 /web/elastic/demo/site/modules/Spex/Spex.module(250): This error message was shown because: site is in debug mode. ($config->debug = true; => /site/config.php). Error has been logged.

Line 713 typo: $_timespamp private static function _getCacheName($files, $prefix = 'css_', $ext = '.css') { // ------------------------------------------------------------------------ // Initialize timestamp variable. // ------------------------------------------------------------------------ $_timestamp = ''; // ------------------------------------------------------------------------ // Calculate timestamp of all files // ------------------------------------------------------------------------ foreach ($files as $file) { $_timestamp = ($_timespamp + $file['last_modified']); } // ------------------------------------------------------------------------ // Create a unique MD5 file name with the specified prefix. // ------------------------------------------------------------------------ return (self::$developmentMode !== true) ? $prefix.md5($_timestamp).$ext : $prefix.md5($_timestamp).'_dev'.$ext; }

ProcessAssetsBackups is a new module I've developed as an Image Archive. Why? When multiple people maintain content, sometimes updating older pages, eventually someone reports as "missing" an image which someone discarded a year ago. This archive tool explains what happened and provides the old image. Status: It's working (in 2.7.3) and provides the functionality I need for my current project but it could do more. Before I put it out in the world I'd like to know what people would like from such a module. It could archive other file based assets and do more in terms of Restore and Explore operations. In my test I've backed up about 1.5GB of images from a site with about 30,000 pages. Click a button in the page editor to see chronological listing of past and current images from the archive. Read the overview to see what we have so far. Overview: The module maintains a backup of Processwire file assets for images (not the variations, only files with one dot). The tree of archived files is positioned outside of the Processwire installation, partly for logistics of site maintenance and partly to avoid conflicts with Processwire's access control. Batching and cron are involved because of the quantity and ongoing nature of the work. To update the archive, image field table records are inspected in the order of their modified timestamps. After each batch of images the last timestamps are saved in module config so the updater knows where to resume. Cron should call this frequently. A small PHP script provides access to the archive. Cron uses it to run the updater like this: http://www.example.com/abService.php?cmd=update To get a report on available assets for a given page call it like this: http://www.example.com/abService.php?cmd=explore&id={$page->id}; In the backend a /processwire/setup/assets-backups/ page lets you set which image fields are to be backed up. On save it resets the timestamps in the module's config info so that everything is checked. More about the archive contents: When the updater finds a new image it saves that image and also saves a small json file containing the image field's record for that image. Having the field data opens up possibilities for additional features. These json files are named by the timestamp, field name and sort value (to sort in a useful way and be unique). In most cases the image file names are unaltered. The exception is when a new replacement image has the same name as an existing image but is a different size. In that case the existing copy is suffixed with the new image's timestamp (indicating time of retirement) before the new image is copied. Access to the archive files can optionally be restricted by an .htaccess file. That rewrites URLs, sending them to the abService.php script which is setup to return content only to users who are logged in and have certain roles. Others get a 404. The script can easily be edited to return only files with certain extensions (e.g. allow images but not json files). Making use of the archive: An "Image Archive" button can be added to edit pages for templates having images. This is done by adding a RuntimeMarkup field to the page and pasting in a few lines of code to open a abService.php url in a modal. Currently this display is simply a chronological list of the images with their timestamps and filenames. If you want to revert to an earlier image you can drag and drop it to a folder on your computer and then drag and drop it from there to an image field in a page editor. Any suggestions?

I did let it update those files.