adrian

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

All you need to do is use a selector to see if the email already exists. Do this inside the if($input->post->submit) { and if it exists, do an: $email->error("Sorry, this email address is already in our system"); The selector can use something like: $email_exists = $pages->find(selector); if(count($email_exists) > 0){ to determine is the email address is already in the system.

Not exactly sure if this is the same issue, but I have used this script (http://benalman.com/code/projects/php-simple-proxy/examples/simple/) in several cases and it works great. Here is a direct link to your web service output: http://benalman.com/code/projects/php-simple-proxy/ba-simple-proxy.php?url=http%3A%2F%2Fbenipeixcar.indinet.es%2Fservice-pages%2F%3Fparent%3D1013&full_headers=1&full_status=1 You should probably host the proxy file yourself though.

Are you in the page tree - see attached screenshot EDIT: What interrobang said

It's a little hard to follow exactly how you have your site structure, but you should be able to find the answer for your problem here: http://processwire.com/api/fieldtypes/images/ The very first example shows how to iterate through all images on a page: foreach($page->images as $image) { echo "<img src='$image->url'>"; } If you need to get the images from a child page then simply get the child page first using a selector: $childpage = $page->child(selector to get specific child); Then foreach through $childpage->images