adrian

Hi there! This module might be your easiest option: http://modules.processwire.com/modules/simple-contact-form/ There are other modules and you can also build a contact form manually, so let us know if this doesn't suit your needs and we can provide more info.

Thanks for reporting. I have fixed this. I was thinking about disabling the module from affecting any pages under the admin, but thought some users may store some settings type pages, so for the moment I have just excluded pages with the "language" template. Please let me know if you have any problems.

Those settings work for me, but only if ACF and HTML Purifier are also off.

@simplesequence - welcome to PW - sorry for the rough start, but looking at your screenshot I see that you are running v2.3. According to the modules directory, kongondo's blog module isn't compatible with this version. It requires 2.4+ PW's current stable version is 2.6.1. Is there any reason you are running 2.3?

Peter, Some things you'll probably need to add: area[!shape,!coords,!href,!target,alt] map[!name] img[alt,!src,width,height,border,usemap] Also, this imagemap plugin for CkEditor might be useful: http://www.martinezdelizarrondo.com/ckplugins/imagemaps.demo/

Not sure if this is related or not, but for my RestrictTabView module I conditionally added a hidden _pw_page_name field to the Content tab to deal with this: https://github.com/adrianbj/RestrictTabView/blob/master/RestrictTabView.module#L90 There is also this Issue that mentions the problems that can occur in certain configurations: https://github.com/ryancramerdesign/ProcessWire/issues/1048

There is an option for changing the "created" date via the API using quiet mode: $page->created = $timestamp $page->save(array('quiet' => true)); This only works for created though, not modified. This is what I use for modified - make sure you do this after the last $page->save() or it will be overwritten. $sql = "UPDATE `pages` SET `modified` = '".date('Y-m-d H:i:s', $timestamp)."' WHERE `id` = '".$page->id."';"; $update = wire('db')->query($sql);

My preference for app development is for ionic. Like onsen.io (thanks for that link - hadn't seen that one) it is based on Angular, which is an awesome option IMO. Here is a comparison thread: http://forum.ionicframework.com/t/pros-cons-vs-onsen-ui/8177 Here are some useful links about setting up and publishing with Ionic and Cordova (the open source codebase that phonegap runs on). http://ionicframework.com/docs/guide/publishing.html https://coderwall.com/p/vvkyra/getting-started-with-ionic If you're on Windows, Phonegap Build (build.phonegap.com) should get you through all the issues of building for iOS without a Mac.

Hi @holmescreek and welcome to the forums. What you need to do is define a separate role - perhaps called "deletor" and give it edit and delete permissions. Now remove the delete permission from the main editor role. Now for the pages that you want the delete option to appear on, give their template edit permission for the deletor role. Something like this:

Hi Peter, This was the first module I ever put together and I still haven't really finalized it - I have it working on a few sites, but it really needs some configuration options - what images field to use, what pages of the PDF to create images for, etc. You might be better off with this module by Richard Jedlička: https://processwire.com/talk/topic/6426-pdf-fieldtypeinputfield/ although since it is a separate fieldtype you might have a little trouble migrating your content from your existing files field. If that is an issue, perhaps just tweak the code in this module of mine to suit your needs, because it sounds like you don't want images for every page, just the cover. Let me know if there is anything I can do to help.

Can you provide the code for the entire module for us to see? Do you have debug mode on? Any errors?

The markup module that comes along with kongondo's blog module is just there as a helper - there is no requirement to use it. Just don't use it and write your own markup - either steal from the markup module, or from Ryan's blog profile as a starting point.

Hey kongondo - I have just started using this on a site for the first time - it is going to be awesome! The one thing I would like to be able to do though is have better control over the row/column selectors. What I need to do is be able to limit the matches to children of the current page because I will be using this field on several page trees on the site that have the same structure, so a template selector will grab all these pages, not just the one under the current parent. I think if the PW core supported 'page' as an argument that could be used for the parent selector I'd be OK. parent=page, template=rows_template Perhaps your module could have an extra config settings to limit to the current page? Or perhaps an option to use custom php code to find the pages - like you can when defining a page field. Is that something you'd be willing to support? Any other thoughts on how to make this work? Thanks again for your work on this! PS Another feature suggestion - any chance of adding a browser warning alert for the reset button? I know that nothing is actually lost until the page is saved, but I bet some users will think they have lost everything already and start typing again, not realizing they can simply reload the page. Maybe the button could also be named "Clear Data" or something more descriptive than "Reset". My thoughts continue I am not sure how to handle this, but I have a checkbox field on each of the pages that make up the columns - this is to determine whether the page should actually be included in the table. The thing I worry about is someone unintentionally unchecking this which will result in data loss the next time the page with the Matrix table field is edited and saved. Other than a warning in the description/notes of the checkbox field, I am not sure how to protect against this. Could you module perhaps warn when rows/column are about to be discarded - with an alert that actually says which ones are being deleted from the matrix table? Any other ideas? Also, what about an API method to create data - it would be nice to make it easier to create an import routine from an existing database.

Thanks SiNNuT - I really appreciate you letting me know that you're finding it so useful.! I hope you'll also like the next little enhancement Edit mode now has hidden and unpublished checkboxes:

Not much help, but I just tested your code (slightly modified so I can just paste into admin.php) and it is working fine here in the latest dev version of PW, so I think you must have something else going on. Can you test on a clean dev install to see if you can help to narrow down the issue?

There is no need to get/find the pages, just use count: $num = wire('pages')->count("parent=/case-references/");

Sorry for all the quick updates, but am using this to populate a huge site and finding new needs so implementing as I go. You can now change the template of each child page in the Edit mode. Because this change happens without warnings, it is controlled by the new "Allow template changes" setting in the module config. Of course the ability to change templates is also additionally controlled by the user's "page-template" permission. Note - you might potentially only want to enable "Allow template changes" while your site is in development and disable once it is live to avoid any disasters. TIP: If you want to change the template for all child pages at once and there are lots of pages, this could still be a little tedious. So instead, use the "Replace" mode, choose the "Child Template" at the top and click Save. This will delete and recreate all child pages with the selected template. This is super fast if the pages don't have any content yet (or child pages of their own), which can often be the case early in development when you are still figuring out which pages will have which templates!

Some cross-linking and gratuitous self promotion I have just implemented highly configurable CSV exporting (admin and API) into Batch Child Editor: https://processwire.com/talk/topic/6102-batch-child-editor/page-2#entry95855 It does lots of work for you, including supporting ProFields Textareas and Multiplier, along with outputting Page field title/name, rather than ID. Export settings can be configured by the developer and/or the site editors. It might be useful for others searching for CSV export and finding this thread.

Another major new feature! I have added an Export to CSV mode which generates a CSV file containing the fields for all child pages. It currently supports most field types, including: Text/Textarea/Integer/Date fields Page fields - exports the "Title" if available, or "Name" if not (eg user template), rather than just the page ID File/Images - exports the filenames Profields Textareas - automatically converts field into multiple columns - one for each subfield Profields Multiplier - separates values with a customizable separator - you can choose a line break if you want which is nice when opening the CSV in Excel. This same customizable separator is available for other multiple fields like Page fields, File/Image etc It does not support Profields Table, PageTable or Repeaters as these would get very messy. Note if you want to provide an export for specific Table fields, don't forget to check out: Table CSV Import/Export Fields to be exported can be predefined or customized by the user. Also includes an API export method: //export as CSV if csv_export=1 is in url if($input->get->csv_export==1){ $modules->get('ProcessChildrenCsvExport'); //load helper module //delimiter, enclosure, file extension, names in first row, multiple field separator, array of field names $page->exportCsv(',', '"', 'csv', true, "\r", array('title','images','textarea_test')); //$page->exportCsv() - this version uses the defaults from the module or page specific settings } // display content of template with link to same page with appended csv_export=1 else{ include("./head.inc"); echo "<a href='./?csv_export=1'>Export Table as CSV</a>"; //link to initiate export include("./foot.inc"); } Like the rest of this module, everything is configurable at various levels, so you can include this functionality as a separate tab, or part of the Children tab. You can predefine all settings so the user only has a simple Export button - whatever works best for you. Please let me know how this new functionality works out for you and if you have any suggestions for improvements.

Of course Seriously though, I find that in general it works really well, but I do need more testing from others to find these situations where it doesn't. Keep in mind that there might be an issue with recent versions of PW (https://processwire.com/talk/topic/8660-migrator/?p=92889) that I need to look into. The issue you mention might be related to this, however I do also need to work a bit on the behavior for migrating the content page tree for page fields - I need to check to see if that tree already exists before importing so it can update/replace it, rather than adding a new one. Interesting that you want to exclude field/template migration - what happens if the fields/templates for the pages you are trying to import don't already exist? I don't think it should be hard to make this an option though. If you'd like, please PM me your exported json or zip file so I can test - it might help me to discover some other scenario where it isn't working as expected. I really do want to get this stable and released sometime this year.

This issue is what Migrator (https://github.com/adrianbj/ProcessMigrator) aims to solve (although not for users just yet). It works very well in most scenarios - there are just a few situations that still need some tweaking. It works by converting page IDs to named json records, named assets folders etc so that they can be imported into a new site without causing clashed with existing page IDs. Unfortunately for your purposes of migrating user accounts, there are currently several checks to exclude pages under Admin (I wanted to prevent it messing with this stuff), but I do think they can probably be removed - carefully! Anyway, not a complete solution for you right now, but something for you to investigate. I haven't found much time to work on it of late, but I am still intending on finishing it up sometime soonish.

Because an autocomplete inputfield is connected to a page field, you are dealing with an array, so try this: $page->autocompleteField->add(7111);

You don't want the ProcessWire-master folder, just its contents. Many of those folders you see will be removed during installation. In particular, all the site- .... folders will be removed except the one you choose and it will be renamed to simply "site". EDIT: Too slow - @LostKobrakai typed while I was distracted with a phone call

Hi @Bill* and welcome to PW and the world of web development in general! In most shared hosting environments you'll want to unzip it to a folder called: public_html. Sometimes there might be a /var/www/ or yourusername/public_html or something like that. The key thing is that generally it should be at the root of your web folder structure. If in doubt you should ask your host, but if you can view a page that links to a default index.html file (or maybe home.html) if you unzip processwire where this file lives, you should be fine. Hope that helps.