SteveB

My local server was running 2.6.21. I installed the ProcessWireUpgrade and updated to 2.7.3 very smoothly. Everything seemed fine. Next, I had it download 3.0.8, it said my .htaccess and index.php were compatible. The "Upgrade completed" message appeared. I checked a couple pages and each time I get: Fatal error: Exception: Method ProcessWire::getArray does not exist or is not callable in this context (in /web/elastic/demo26b/wire/core/Wire.php line 347) #0 [internal function]: ProcessWire\Wire->___callUnknown('getArray', Array) #1 /web/elastic/demo26b/wire/core/Wire.php(303): call_user_func_array(Array, Array) #2 /web/elastic/demo26b/wire/core/WireHooks.php(555): ProcessWire\Wire->_callMethod('___callUnknown', Array) #3 /web/elastic/demo26b/wire/core/Wire.php(327): ProcessWire\WireHooks->runHooks(Object(ProcessWire\ProcessWire), 'callUnknown', Array) #4 /web/elastic/demo26b/wire/core/ProcessWire.php(471): ProcessWire\Wire->__call('callUnknown', Array) #5 /web/elastic/demo26b/wire/core/Wire.php(328): ProcessWire\ProcessWire->__call('callUnknown', Array) #6 /web/elastic/demo26b/wire/core/Wire.php(328): ProcessWire\ProcessWire->callUnknown('getArray', Array) #7 /web/elastic/demo26b/wire/core/ProcessWire.php(474): ProcessWire\Wire->__call('getArray', Array) #8 /web/elastic/demo26b/site/assets/cache/FileCompiler/site/mod in /web/elastic/demo26b/index.php on line 64 Some issue with the file compiler?? Reverting to 2.7.2 by swapping back in the old files worked fine. By the way nice job on the ProcessWireUpgrade module's messages and instructions.

Nice! I didn't know about button('refresh'). That works perfectly. Thanks so much for the module too. I'll be posting something about this "archive" pretty soon in Module/Plugin Development.

Yup, working for me too. The only wierdness left has to do with button color. Using the default admin theme it's green and turns sort of purple after being clicked to launch the modal. It stays that color after the modal is closed and that seems wrong.

The page has image field's thumbnail images which use modal and have those "pw-modal" classes and work just fine, so any necessary js and css are in place already. I'd seen that Adrian comment so I know it can be done. I'm new to jqueryUI so I don't understand the handling of the click event and at what point it does something (return false?) to stop the browser from processing the link as a link and going off to another page. There must be some condition which isn't being met. Could it be a matter of what the A tag is wrapped in? Answer: Don't use an A tag! Seems simple enough. Just do it all with the button, putting the url in a "data-href" attribute on the button. It's working now. Drifting off topic but any tips on how best to generate the boilerplate page markup for this iframe so that admin theme styling for an AdminDataTable works. I'm about halfway there.

How can I have the button open a url in a modal? I can't quite get it to work. The modal does appear but then the browser goes to the url. $url = 'http://example.com'; $out = '<a href="'.$url.'" class="pw-modal pw-modal-large" data-buttons="#non_rte_dialog_buttons button" data-autoclose="1" data-close="#non_rte_cancel">'; $out .= '<button type="button" name="button" class="ui-button ui-widget ui-corner-all ui-state-default">'; $out .= '<span class="ui-button-text">Image Archive</span></button>'; $out .= '</a>'; return "<div class='pfabLink'>".$out."</div>"; Thanks

Got it! Markup comes from AdminHelpTab->hookBuildForm() or ProcessAdminHelp->___execute() depending on where you're looking at the content. I made a couple small changes to use a different field and also to disallow editing from the help tab display, except for superuser.

I have a ckeditor field I'd re-use for this and my "body" field was going to be a plain text field, though I don't have to do it that way. When does the accordion markup get made anyway? I tried putting something like die('Yikes') in ProcessAdminHelp ___execute() but it had no impact. I'm still a bit murky on the life cycle of process module pages.

It looks fine, I just don't understand where the markup for the individual help pages comes from. The auto setup creates templates that have no template file.

I meant the render from the help tab. Hmmm.

What am I missing? I'm unable to change the formatting. Thought that was handled by module's ___execute function but I keep getting the same layout.

Horst: NuSphere PhpED 14.0 Professional for Windows (Build 14040)

I had used PHPed for many years and was happy with it though I mostly just used it as an editor. Good syntax highlighting and good find/replace. One day a couple months ago, as it was explained to me, hackers did something to their site which resulted in a few hundred customers licenses becoming invalid, locking us out of the application. It was a permanent license, only the access to updates expires. While waiting to hear back from them I became familiar with Sublime and have chosen to stick with that. This was a rare event and I Imagine they are better protected now but finding out it could be be disabled remotely really put me off.

Looks good. Would the side by side content areas responsively stack if, in a pinch, we had to do some admin work via small screened portable device?

This is about viewing large images with a frontend viewer that pans and zooms a view made from image tiles stored on the server. Like you're used to seeing with maps. The module is a work in progress and I'm fishing for advice and suggestions about integration etc. The viewer is OpenSeadragon, which works with lots of different tiling schemes. Examples at the link. Tiles go in folders within the assets/ folder. I'm keeping them in their own branch now (assets/zoom/{id}/{tag}/) but it doesn't have to be that way. The module (patterned after FieldtypeEvents - Thank You!) stores meta information about the tile sets and has a render method to make markup for your template. I have an image for this but the forum tells me: "You are not allowed to use that image extension on this community." It's .jpg Render them like this: $zees = $page->Zooms; if(!empty($zees)){ $spex->addScript($config->urls->templates.'scripts/openseadragon.js'); foreach($zees as $z){ $a = $z->renderZoom(); $spex->docReady($a['js']); echo $a['html']; } } Nothing magic about using spex there. I just happen to be using it. The javascript being handled there should run after the page is loaded. The html markup is just a couple of divs, one for buttons and one for the image, and possibly a label. You could do it in your template code but it seemed handy to build default markup into the module. I already have sets of tiles which were made for an old Zoomify viewer. I've slightly customized the tile loader to handle the different naming conventions so OpenSeaDragon can use them like dzi tile sets. Pretty much anything you need to do like that involves one small JS function which provides the URL to the image. So far, I can put tile files in assets, enter the meta info in the page editor, view the page and see the zooms. The markup has reasonable ids and classnames so you can style zooms individually or globally and multiple zooms on the same page function just fine. Next Steps: People will want to add/replace images. I'm thinking of using an ordinary images field to upload and store the originals and have a scheduled task do the tile making offline. Tiling takes more time and memory than I would want to use in a hook on save approach. I would use the image's tags field as a place for the user to put a name to be used both as a label and as a subfolder name for the tiles. Thanks

Great project idea. Would this allow me to use different settings for different templates? I'm making front end forms with the API but the different forms need their styles adjusted independently.

@GuruMeditation, I'd like to help out.

Had something like this once (not in PW) where I updated the integer sort field to be 100, 200, 300... Then to move item X to be just after item Y you simply give it Y's sort value plus an offset. Use offset of 1 the first time and increment it each time. A negative offset can be used for inserting before. You need a function to normalize the sort values when you are done or after a large number of moves but that's easy enough to do.

That's a lot of fields. How about an option to bundle groups of them into Textareas fields, or maybe put some in an external table. Just thinking out loud here, haven't thought any of this through.

There is a lot of good info but all from different points in history. Figuring out what's true today usually means extra reading (not a bad thing, but time consuming). Fortunately the code itself is well commented. When I look at the cheatsheet I'm always wondering if the info is current or a couple years old. Object properties like image->width (Soma's example) don't change much but other things do. New features turn up every week. If documentations like this had a PW version number on each content item (the version the author was writing about, or has later verified is consistent with the article) we'd know better what else to look at.

"To plant the acorn, and for PW to grow the tree." I could see using this to discuss work-in-progress demo sites with clients. Keeping things more on-topic than emails tend to be. Setup topics and links while coding, putting discrete links in the content. Conditionally rendered so you can turn them on and off by role/priv. Often these discussions clarify policy. Pin those for future reference. Other topics could be how-to info. "I would love to see the possibility to subscribe to a topic and get notified by email when an answer is posted" Also could have a notice come from the PW messaging system after you login.

You could setup users for the "in the know people" and require them to login at /processwire/login/ (default). if(!$user->isLoggedin()){ $this->session->redirect("http://example.com/maintenance.htm"); } Set them up with a role that has only view privilege and they can't hurt anything.

Welcome Tom, based on what you've shown us I think you'll like PW much more than WP. But I have to say I also think the type on thing is annoying. When eye candy delays reading of the content, the designer is putting themselves ahead of the content and that's just wrong. Sorry to be blunt but I feel strongly about this. More positively, the site's clean and consistent and squeezes down well. Oh, one very small thing; an extra closing p tag in the footer.

To that I would add... Links to relevant blog post or forum topic A brainy search engine like Elastic Search Comments from the community, snippets etc. with up/down voting (sort of like PHP docs) It should be built on Processwire! That way the community can more easily contribute to getting it done and it becomes a great demo.

So far so good. I've just finished a massive data import to a project I'm working on (it will replace the system it's importing from). Had an earlier 2.6 system going and just to be thorough and clean things up, cleared most of its content, exported a profile, Did a fresh install of 2.6.21 with that profile, checked it out a bit and then ran the lengthy import process. It now has 32074 pages and seems fine.

FYI, the same kind of thing can happen with hyphens.