adrian

PW uses bitwise operators for setting flags. It does the same thing for the page status field (ie hidden, unpublished, trash etc). You can see the various values for each flag at the top of this file: https://github.com/ryancramerdesign/ProcessWire/blob/a8024bb49785370aa2e3867bd683094663cfeabf/wire/core/Field.php The values are added together and stored in the flags field, which is why you saw a 5 = autojoin (1) + global (4) Hope that helps.

Hi desbest and welcome to PW! The plural version is the parent template and the singular is the template for the child pages which contain the actual posts and tags. This allows different rules for the parent and child templates. It allows you to say that any children of the tags page must use the tag template. Look at the page tree for Tags: Tags (tags template) CSS (tag template) Customization (tag template) Photography (tag template) Templates (tag template) Uninteresting (tag template) Videos This also allows for creation of a Tags PageField that allows for selecting these tags on other pages (eg from a post). It's all about structuring the content and defining what is allowed to be used where. Here is a great tutorial from kongondo about page structuring: http://processwire.com/talk/topic/3579-tutorial-approaches-to-categorising-site-content/ This video about page fieldtypes might also be useful: http://processwire.com/videos/page-fieldtype/ Hope that helps - let us know if you have any more specific questions.

The autojoin option is stored in the fields table as a flag. Most likely you'll see a '1' in the flag field for the relevant field. Change it to '0' and it will remove the autojoin. Keep in mind that I haven't tested autojoins with repeater fields - maybe autojoin and repeaters is not supported? Anyway, hopefully you can fix it with the DB change.

Getting stoked The latest version on github now supports migration of repeater field page content and fixes the problems with migrating page field content. That should take care of migrating the fields, templates, and page content for all the field types, not including page content for file and image fields as obviously these can't, or more accurately, shouldn't be included in a json file. Multi-language fields should migrate perfectly so long as you have the required language support modules and languages installed on the destination PW installation. Let me know if you have any troubles here - I did see some weird errors during early testing - I hope they are all fixed now. Please note: that most of my testing of late has been with the "Everything, including all data pages" option on export and import. I need to go back and test the other options soon, but I'll probably do that when I start implementing the series of checkboxes allowing you to select exactly which fields, templates, and pages to be exported and imported. Also, I have been testing with the latest dev version of PW (downloaded today). Not sure if anything is critical, but if you are getting errors, please try upgrading PW first.

Just noticed that if you uninstall language support, it doesn't also uninstall "Languages Support - Tabs". It gives a couple of php warnings/notices from the tabs module file. BTW, I am talking about the latest PW dev version where this is now a core module.

There should be no reason to worry about deleting old show pages. PW should be able to handle millions of pages (http://processwire.com/talk/topic/3111-a-modx-refugee-questions-on-features-of-processwire/?p=30901), but regarding storing your log information, that shouldn't matter anyway because it would only be available via the admin interface anyway. If you were really worried, you could store the log in a custom SQL table, and create a custom fieldtype so that each entry would be a single database row, but I think that is completely unnecessary in this case. After-all, you are only logging transactions and not all page views - correct? If you are having issues with the custom admin page module, you should after diogo on the module's support thread - I am sure he can get you going with it.

Glad it's now working for you. This is not really related to your problem and maybe you have take the route of using a text log file for a reason, but I was thinking that if you have admin users who might need to check to see if transactions were successful or not, it might be more friendly to store this information in a PW page tree with each transaction as a child page with a fields for things like page name, timestamp, user agent, ip address, success of transaction, transaction number, purchase price etc. You could then offer excel downloads of this data among other things. I did something similar and it works great with one of the PHP excel libraries available and it can be easily integrated into the PW admin without the need to create a model by using diogo's custom admin page module (http://modules.processwire.com/modules/process-admin-custom-pages/) Maybe I am getting too carried away with ideas for things you don't need

Another update - things are getting closer! I have just added support for migration of the selected values of page fields when migrating "everything, including all data pages". Only repeater field page data (the fields, templates etc are already working) to go, and then of course the inevitable bugs EDIT: Just found a bug in the page field data migration - hopefully solve this soon. Repeater data is working now though - not on github yet, but I will push that too once I have the page field issue sorted out.

In your php.ini file, look for the memory_limit setting and increase that as needed.

Hi ioio and welcome to the forums. You can edit anything under the site/templates folder without affecting the admin side of PW. Let us know how it works out with the head and foot files and if you have any more specific questions. Also, not that you don't even need to follow the structure of having a head and foot file. Many users prefer a main.inc file which contains the entire site structure and echos the content variables where appropriate and is included at the end of each template file. There are other possible approaches as well - really it just comes down to what works best for you and how you like to work and mentally visualize things.

I don't think this is possible, but just in case you are not aware, you can limit the available templates to makes things simpler. I pretty much never give the user the ability to choose the template by making sure that only one option is available by using the template access and family settings.

Ok another update this morning - I have added support for full migration of page fields - it now automatically handles creation of the selectable pages fields, templates, and the pages themselves. The one thing I haven't really figured out how to tackle is what parent to put these pages under. At the moment they end up under the same parent page that you choose when starting an import. This is probably not ideal, but otherwise it could result in the need to create a whole other lot of parent parents/templates/fields that you don't really need on the destination PW site. This way everything needed gets migrated but nothing more and you can easily move them into a new parent (like a tools parent) if needed. Anyone have any better ideas? You might need to run a test to see what I mean. Again, this will probably need lots of testing so thanks in advance - there is a lot going on to make this all work!

Raymond - this has been discussed, starting at this post: http://processwire.com/talk/topic/4650-new-processwire-admin-theme-on-dev-branch/?p=46259 Solution starts here: http://processwire.com/talk/topic/4650-new-processwire-admin-theme-on-dev-branch/?p=46380 and the next post.

Hi Ollie, Without looking at your code in too much detail, the first obvious problems are the single equals signs in the if($item->parent = statements. Try using == and let us know if that fixes things. Also, you'll probably need to do $item->parent->name

Well, now it's official - I've been outsmarted by a machine - if it can solve all Google reCAPTCHAs then it is one up on me. I am lucky to still have much better than 20/20 vision - I can't imagine how someone with failing eyesight manages with some of reCAPTCHA's concoctions! I hope this means that captchas will die a quick death!

Ok, I have pushed another version to Github. v0.0.8 fixes the fieldsettab issue that Ozwim reported and introduces support for migrating repeater fields. It handles the creation of everything required on the source PW installation for the new repeater fields to work. Next on the roadmap is full support for page fields - currently only the page field itself is migrated, but not the selectable pages fields and templates. Then it is on to migrating the page content for repeater and page fields I would really appreciate any help testing out this new version. EDIT: Just updated the readme on github to detail what does and doesn't work, along with a rough roadmap - please let me know if your testing shows that I have any working/not working mistakes - I am sure there are some

Hi Peter, This may not be an ideal approach, but you can save the page unpublished until the user actually clicks the save button. That way if they cancel/don't save, then it won't be published. You could also setup a lazycron to cleanup these canceled pages if need be.

I can't seem to make myself use this on the regular basis, but reversing things so you have: if('group' == $page->template) This works well, because if you forget the second = you get an error, rather than php just setting the variable.

I think you are looking for parent_id and template_id I make use of these in this module: https://github.com/adrianbj/ProcessPageFieldSelectCreator/blob/master/ProcessPageFieldSelectCreator.module#L377 To find these, just right click and inspect element - the id of the field without the "Inputfield_" is what you want to use. Hope that helps EDIT: You beat me to it

Try this code somewhere in one of the files that are included on every page: if($config->debug && $this->user->isSuperuser()) include($config->paths->adminTemplates . "debug.inc");

Ok, well I am still waiting to hear about the Pagefile::install hook issue , but in the meantime I have extended this module considerably. It now supports specifying multiple rules based on selected fields, templates, parent pages, and file extensions. This way you can infinitely configure the filename format exactly how you want. I'll add a post in the modules forum board once the hook issue is sorted, but for now, you can access the module at: https://github.com/adrianbj/CustomUploadNames I used Pete's work in the EmailToPage module as a starting point for the multiple rename rules in the module config. This mostly seems to be working really well, but unfortunately I can't seem to get ASM fields to initialize properly when adding another rule until it is saved and the page reloads. Any ideas? Attached is what the config settings looks like.

That doesn't look complete - is that potentially a frame within another frame?

It might help if you could post the HTML source of the this page (in an attached txt file) so we can see what divs are being produced to make this.

Hi Pete, Just playing with this module for the first time - looks fantastic - thank you. Just a couple of things: there are lots of undefined variable and undefined index notices on the module config page that would be nice to have cleaned up. You still have "live" in the js file. I like the approach that Wanze took with live vs on in the batcher module depending on the version of jquery. Also, the "Add another category" button seems to be missing - I am guessing this is a class issue with Ryan's new default admin theme that I am testing it with. Thanks a lot for looking into these.

That's not a valid selector. You could do: $pages->find("title=asd@asd.pl"); EDIT: Wanze beat me