kongondo

HI @Jim Bailie. Welcome to ProcessWire and the forums. I don't quite understand the question. ProcessWire does not output anything in the frontend unless you tell it to. Maybe if you could expound a little bit on your question? Otherwise, it's as simple as: if('your condition here') { // do this } else { // do that } As for Ajax..just to elaborate on @elabx's answer if($config->ajax) { // ajax request sent; output ajaxy response stuff and exit; $data = array('foo', 'bar'); header('Content-Type: application/json'); echo json_encode($data); exit;// or use PW halt() if it suits your needs } // echo normal non-ajax stuff

Let me know if you need help .

JavaScript, CSS and $this->wire('files')->render('your-file') in Runtime Markup code setting . 'your'file' has the PHP. See video demo below. Works on the fly, no need to save first + shows what's already saved. I do . See video demo. Another option is RM as suggested by @Sergio. See this quick demo. I can post the code later in RM's forum. Picture Options is a Select Options field. Options Illustration is a RuntimeMarkup Field.

Glad that part work. Hmm. Doesn't work on both OS?

I think it would work. $files->($zip, array|string $files)

Did you see $options in $files? The exclude (array)?

Is this a duplicator feature?

I haven't been following the zip conversation closely but don't ProcessWire's inbuilt functions not work? wireZipFile() has never failed me and more lately $files->zip(). I've just tried the following (example from the Docs) on my local Windows machine (EDIT: not a Windows Server though!) and remote linux machine and $files->zip() worked without errors (nested folders; PW 3.x): // Create zip of all files in directory $dir to file $zip $dir = $config->paths->cache . "my-files/"; $zip = $config->paths->cache . "my-file.zip"; $result = $files->zip($zip, $dir); echo "<h3>These files were added to the ZIP:</h3>"; foreach($result['files'] as $file) { echo "<li>" . $sanitizer->entities($file) . "</li>"; } if(count($result['errors'])) { echo "<h3>There were errors:</h3>"; foreach($result['errors'] as $error) { echo "<li>" . $sanitizer->entities($error) . "</li>"; } }

There has been a bit of a delay, I'm afraid. It might be another 3-4 weeks (with Easter around the corner), sorry. Yes . See this quick video demo. Users will be able to edit media as normal ProcessWire pages. You can upload more media to the page, sort the media, edit image media using the new and any future ProcessWire image functions (focus, crop, sepia, etc), add more fields to the media templates, e.g. text, integer, page fields, etc, (and be able to access these fields using Media Manager API), etc. Basically, you'll be able to do whatever you can do to any ProcessWire page. Yes. I'll tell you more via email.

Just to clarify, there is no such requirement in the blog module. Yeah. That's how it's done in the the blog demo template files. Note though, that this is also not a requirement.

I needed clean installs free from some modules and pages in the 2.x sites. I didn't want those carrying over into the new install and then uninstalling/deleting them.

Just cross-referencing: I've ported the export functionality into a module and class for exporting ProcessWire 2.x sites in a format compatible with importing into ProcessWire 3.x using PagesExport/Import.

I think its better if you started a new thread under general support. Please also add more details about the error. I can't see the error itself in your screenshot above, just a pointer to where it occurs. Thanks.

Pages Export This module is for specifically exporting ProcessWire 2.x sites for later importing into ProcessWire 3.x. Github: Project Page Modules Directory: https://modules.processwire.com/modules/process-pages-export/ Credits: Ryan Cramer Background As I make my modules ProcessWire 3.x-compatible only, I've had the need to re-create/mirror their ProcessWire 2.x test sites in respective ProcessWire 3.x sites. These ProcessWire 3.x sites (one for each module) were already in place and I didn't feel like re-doing them by exporting/importing site profiles. I also like working with JSON rather than other export formats. So, I decided to write a custom pages export/import script for moving the ProcessWire 2.x sites to their respective ProcessWire 3.x counterpart sites. I'd just finished the export side of things when I came across a post in the forums that reminded me that ProcessWire 3.x already boasts a pages export/import feature, although some of it is still in development. Great! I like its API (PagesExportImport.php) and GUI (ProcessPagesExportImport.module) so no need to re-invent the wheel. I still had the small problem of making sure my JSON export would be compatible with the JSON input that the ProcessWire 3.x import expects. No need to re-invent the wheel, again! I ditched my custom script and instead ported the export functionalities of ProcessWire 3.x Pages Export/Import for use in ProcessWire 2.2 - 2.7, specifically to help migrate older sites to ProcessWire 3.x. Compatibility The module and class have been tested and work in ProcessWire 2.2, 2.3, 2.4, 2,5, 2.6 and 2.7. The module is currently tagged as 'in development' until Pages Import feature of ProcessWire 3.x is released as stable. Nonetheless, I have not encountered any issues so far in either the export or the ProcessWire 3.x import. I think Ryan is waiting until he can support more complex field types before tagging the ProcessWire 3.x Pages Export/Import as production-ready. This is not a ProcessWire 3.x module and will never be. It has no such need . Just in case you forget and try to install it in a ProcessWire 3.x site, the module will throw a WireException(). I will also not be porting the ProcessWire 3.x import functionality for use in ProcessWire 2.x. That will defeat the purpose here; to move sites to ProcessWire 3.x and not the other way round. Supported Fields All non-complex fields such as integer, text, textarea, etc Page fields Repeaters File and Image fields I think these cover most needs. Note: not yet tested with Multilingual fields. Technical To ensure exports will be compatible with ProcessWire 3.x Pages Import, where necessary, the module borrows (and amends as needed) methods from ProcessWire 3.x for use in ProcessWire 2.x. For instance, ProcessWire 3.x Pages Export/Import uses the new(-ish) $file functions found in WireFileTools. Rather than copy and include such files, the module only borrowed and amended needed methods. These are listed below. PagesExport.php From /wire/core/Functions.php: wireInstanceOf(), wireClassName() and wireClassParents() From /wire/core/Fieldtype.php: getImportValueOptions() and getDatabaseSchema() From /wire/core/WireFileTools.php: zip(), chmod() and mkdir() From /wire/core/WireHttp.php: sendFile From /wire/modules/Fieldtype/FieldtypeFile.module: exportValue() and exportDescription() From /wire/modules/Fieldtype/FieldtypeImage.module: exportValue() From /wire/modules/Fieldtype/FieldtypePage.module: exportValue() and exportValuePage() From /wire/modules/Fieldtype/FieldtypeRepeater.module: exportValue() From /wire/core/Fieldtype/WireTempDir.php: create(), createName() and getTempDir() All the export methods from the /wire/core/PagesExportImport.php class ProcessPagesExport.module All the export methods from /wire/modules/process/ProcessPagesExportImport/ProcessPagesExportImport.module Newer methods such as $this->wire() will gracefully degrade to the older wire() function, ensuring smooth and uniform operation in ProcessWire 2.2 - 2.7. Use This module and class is for supersusers only and has only 1 aim; to export ProcessWire 2.x sites ready for importing into ProcessWire 3.x sites. You can either install (like any other module) and use the process module (ProcessPagesExport.module) or skip the install and just include and use the class (PagesExport.php) to export your sites. Both the module (Export GUI) and API require that you are logged in as a supersuser before you can use them. The PagesExport class has a gateway method and option not found in the original class (PagesExportImport). The method export() allows access to the three export methods in the original class, i.e. pagesToArray(), exportJSON() and exportZip(). See example usage below. GUI/Process Module On install, the module will create a new admin page Export Pages. Please note that unlike the original code, this page is created directly under /admin/ and not /admin/pages/. Click on Export Pages to start. Nothing much has changed from the original ProcessPagesExportImport. In older ProcessWire versions where InputfieldSelector was not available, the module will instead present you with a text input to specify a valid (for that version of ProcessWire!) selector for finding pages. The other two methods for adding pages (add pages manually or add by parent) are still available. Custom JS ensures older installs without showIf functionality still get the inputfield dependency treatment. API export($items, $options) PageArray $items: The PageArray to export. Array $options: In addition to the options in the original class that you can pass to pagesToArray(), there are two more options here. mode to specify the export type (array or json or zip) and fieldNamesExclude, to specify fields to exclude from the export. Note that the original class option fieldNames still works. It's for specifying the fields to include in the export. // API USAGE // get and include PagesExport class /* @note: you'll need to include the path differently if you are using the class directly without installing the Process module */ $path = $config->paths->ProcessPagesExport . 'PagesExport.php'; require_once($path); // create new instance of the class $siteExport = new PagesExport(); // find items to export /* a. export whole site! (minus admin and children) careful! in some cases, better to export in batches */ //$items = $pages->get('/')->find('has_parent!=2'); // export a batch of pages $items = $pages->find('template=basic-page|computer'); /* you could also use these methods directly #$data = $siteExport->pagesToArray($items); #$data = $siteExport->exportJSON($items); #$data = $siteExport->exportZIP($items); */ $options = array( // @kongondo addition: export to screen as 'array' or 'json' OR export to zip // zip will be saved in /site/assets/backups/PagesExport/ 'mode' => 'array',// array or json or ZIP // export only these field names, when specified 'fieldNames' => array('images', 'files', 'multi_pages'), // @kongondo addition: exclude fields from export. Here we exclude 'body' field 'fieldNamesExclude' => array('body'), ); // get the export $data = $siteExport->export($items, $options); if(is_array($data)) { echo '<pre> EXPORTED SITE USING pagesToArray '; print_r($data); echo '</pre>'; } // JSON export else echo $data; Screenshots See also the links to Ryan's blog posts above. ProcessWire 2.2 ProcessWire 2.4 ProcessWire 2.5 ProcessWire 2.7 Video Demo (Sorry, long and boring) Demo shows various exports from ProcessWire 2.x and their importing into ProcessWire 3.x. Remember the old Skyscrapers site profile? See how a whole Skyscrapers site gets exported from a ProcessWire 2.7.3 site and imported into a ProcessWire 3.x starting from here.

Thanks @adrian. I'll look at these when I upgrade the module to PW3.x-support only. I have no ETA though, I'm afraid.

Hi @elabx, Did you manage to sort this out?

Finding out the manual way.... Welcome to the forums @Kaseem

Excellent! I've been toying with the idea of shipping the Blog Module with one of this free blog templates but never got round to it. that's exactly what I've been told about my websites!

I don't know of a multiple checkbox field. Is date_sco a page field? If yes, then: if(count($page->date_sco)) { } // OR if($page->date_sco->count) { }

Thanks. My head is all over the place today . I checked the PHP docs just after I posted my question and edited my post .

I recently had to choose between the two and this swayed my preference: https://stackoverflow.com/questions/6604726/file-exists-or-is-readable I didn't find any other other pros/cons besides the potential 'false positives' mentioned in the SO link above. Btw, do you know if is_readable() caches too? Ta. Edit: In answer to my own question. Yes, is_readable results are also cached.

Unless you will be storing the result of an initial check (e.g. in a session or cache), you will have to check for the existence of the file. That aside, do you really need a hook for this? If I got you correctly, couldn't you do the check in the template file itself or that would mean repetitive code? If you did the check in init.php, you wouldn't need to have the same code check in different template files. I don't know if I am making sense, so on to an example. If you had this in init.php (assuming you are using delayed output). $templateName = $page->template->name; $customTemplateFile = $config->paths->templates . 'fields/content/' . $templateName . '.custom.php'; // if user is superuser (or user of your choice) AND we have a readable template file (e.g. home.custom.php) // ... we include it if($user->isSuperuser() && is_readable($customTemplateFile)) { include($customTemplateFile); } // else, include normal template file for this page else { include("./basic-page.php"); }

Moderator Note: I've merged your two topics

Alternatively, just use the 'default_title' option. Switch it to 1 and you are good to go (0 means show what has been saved in MB; 1 means show the actual ProcessWire page's title for that menu item).

Er, @DaveP, this IS that topic .