adrian

Brent - sorry, I didn't read that you were only doing an InputField at the moment. From my understanding of things, a new FieldType is likely your only option. Actually, I wonder if you can have a separate field that stores the selector. Maybe that hidden field you are using is an actual PW field, or you take the content of your existing hidden field and copy it to an actual PW field (visibility set to hidden) on page save. Then on form render it is grabbed and populates the selector text field. Something like that anyway. Not sure how well this would work - seems like it should be possible, but maybe someone else will chime in with a better idea, or flame this one

Hi sshaw, Thanks for your enthusiasm on this. I am still trying to figure out what I think is the best approach here. Here are the functionalities on my list that I would like to see: Code snippet repository that anyone can contribute to Snippets can be "installed/updated" on your site with one click An admin interface that handles running these snippets in different ways, so no need to copy/paste code anywhere. On-demand code execution - for admin type tasks, such as Ryan's clean-files.php script mentioned above Triggered by a specific PW hook Injected into specific template files Embedded into an RTE the way the Hanna Code works As I mentioned above, I think this could really remove the need for module creation in many cases. I wonder if this needs to be a new module, or if extending Hanna Code would work best. PS Just read your last post properly - sounds like we are on the same wavelength here I am definitely happy to take the lead on this, although I'd really like to get some input from the PW gurus on this - in particular Ryan, what do you think about the idea of using Hanna Code as a base for this. I don't want to bloat it with things some users won't want, but I also don't want to have a completely separate module to store snippets that can't be embedded like Hanna does. Maybe the new module could just hook into the Hanna snippets DB table. Any thoughts?

Sounds interesting. You should be able to save the selector by defining a new database field for your fieldtype (in addition to the standard "data" field). This approach is used in a few fieldtype modules, like: http://modules.processwire.com/modules/fieldtype-phone/ http://modules.processwire.com/modules/fieldtype-dimension/ http://modules.processwire.com/modules/fieldtype-map-marker/ Have a look at the getDatabaseSchema and updateDatabaseSchema functions in those modules, along with their dabatase tables and you should get the idea. Hope that helps. Also, this is just a quasi-related module that I'd reference here for the sake of it: http://modules.processwire.com/modules/fieldtype-pages-selector-query/

Hey Ryan - thanks for getting back to me - I think the module will be really cool once I get this figured out! I just tested on a brand new PW dev installation and I still can't Pagefile::install to work. This is my hook (line 74 of my module) which doesn't work: $this->addHookBefore('Pagefile::install', $this, 'customRenameUploads'); As soon as I make setFilename hookable and use the following hook instead, it works perfectly: $this->addHookBefore('Pagefile::setFilename', $this, 'customRenameUploads'); Maybe I am missing something obvious This comment - "I mention this because it's not uncommon when doing data conversion jobs to put the file right in the destination directory before adding it to ProcessWire's data." has me thinking. I am not really sure what you mean by data conversion jobs, but I am just using PW upload dialog to get the images into the system and I am calling "addHookBefore" so I would think it should happen before the file is copied into the assets destination folder. I have attached a version of the module with the install version of the hook, which is the only difference to the version on github, execpt for a error_log call to see if the function is actually being called at all from the hook. Thanks for looking into it. ProcessCustomUploadNames.module ProcessCustomUploadNames.js.txt

Try this: <?php echo $page->find("name=projects")->url ?> or you can use the path of the page, eg. if it is at the root of you site you can do: <?php echo $page->find("/projects/")->url ?> Also, be sure to install the selector test module - will help you figure out the right selector more easily: http://modules.processwire.com/modules/process-selector-test/ EDIT: Be sure to take nik's advice below about get vs find!

I know it might seem confusing and unintuitive at first, but this is the PW way and I am certain you'll be convinced of the value of the approach in time. Here is some more reading on page fields: http://wiki.processwire.com/index.php/Page_Field Have a read of this thread from here on: http://processwire.com/talk/topic/201-fieldtype-select-aka-drop-down/?p=13637 We have all struggled with what seems overly complicated, but it really does work and it works well! Page fields reference child pages, but they are used as a way to allow the user to select from these items (pages) using select, multiselect, radio etc. Try not to think of pages as just being pages - they are used for everything in PW. Maybe someone else will chime in and be better able to explain how it all works, but I would say just dive in and try it - it will soon make sense once you have tried it.

Take a look at this video for an explanation of how page fields work: http://processwire.com/videos/page-fieldtype/ They can be a little tedious to set up, but they are so very powerful compared to the way most CMSs handle storing content for select/radio etc fields that they are more than worth the effort. That module I pointed you to can make the entire process much quicker though - give it a try

In the admin or a front-end form? In the admin you need to use the page fieldtype and then on the details tab choose single and on the input tab choose Radios in the input field type section. The page field select creator module can make this setup much easier: http://modules.processwire.com/modules/process-page-field-select-creator/ If you are after the radio buttons in a front end form instead, let us know and we'll show you through that.

I would say that lots of us are running the dev version for production websites. Key thing is to check that all the functionality you need is working fine, especially any multi-language features as there have been some recent changes there. If it all works as expected, go for it

Well you can modify the _init.php and _out.php files to have a conditional check. Something like on the first line of each: if(!$useWrappers) return; Then in your template file do: $useWrappers = false; Or something along those lines - whatever fits best with your workflow.

I think I see your point now - maybe if you can explain exactly what you need the hook to do it might be easier to figure out the best approach.

You can add hooks in the template files themselves. Here is a great post about hooks by teppo: http://www.flamingruby.com/blog/using-hooks-to-alter-default-behavior-of-processwire/

Here's a cool approach from WillyC: http://processwire.com/talk/topic/1799-routes-and-rewriting-urls/?p=16708 Or you could add a line to your htaccess file (as devcow shows), or if this is a change from what the parent page used to be called this module would do the trick, but you need to have it installed before the change in the name of the page, http://modules.processwire.com/modules/page-path-history/ I guess you could change the name back, install the module, and then change the name again. It's an awesome module to have installed right from the start of development! EDIT: If you go with the htaccess route, you might find something like this useful so that all posts are taken care of: RewriteRule ^news/(.*)$ /blog/$1 [L,NC,R=301]

Peter, I am not sure if http://www.synbioproject.org/sbmap/marker/3210/ is an actual PW page or not, but there is certainly no reason that you couldn't use a PW page to generate the code on that page. There are so many ways you could go about this - really up to you and how you have the content structured. You could set up a parent marker page and marker.php template and allow URL segments and use the ID in the segment as the variable to grab the content from other parts of your page tree. Would that approach work well for you, or do you already have the content that you want in the InfoWindow already set up in child pages? It is possible that Ryan is using URL segments in a sbmap.php template file with the first segment to determine markers and the second to get the ID of item and use those to generate a selector to get the content from somewhere else in the page tree.

Are right - sorry I didn't read your initial post properly. I am still not quite sure where you are exactly having the trouble. Is it figuring out how to generate a URL like: http://www.synbioproject.org/sbmap/marker/3210/ in PW, or how to populate it's output with the correct content, or how to set the marker.rcID to the right value? Tell us more an we'll get you sorted

Hi Peter, Something like this would work: foreach($page->children as $location){ echo "\n\t\tRCDMap.addMarker('{$location->title}', {$location->geo_address->lat}, {$location->geo_address->lng});"; } I haven't filled in all the elements for the marker, but hopefully that should give you the idea. Note that the geo_address comes from using the PW map marker fieldtype module.

It is easy to get content from other pages in PW, but the actual method will depend on your needs. This is one example that allows you to echo out the body fields from all the child pages that match a given selector. foreach($page->children(selector_to_get_specific_children) as $content_for_page){ echo "<p>$content_for_page->body</p>"; } You could also loop through any other pages you want be using a selector like this: foreach($pages->find(selector_to_get_pages) as .... Does that make sense?

Great looking site! I especially love the responsive design changes. The thumbnail hovering doesn't seem to have any issues for me - OSX Chrome 30.0.1599.101 The only thing I find a little confusing is the "In English". It makes me thing the site is always actually in english. I think if it were just worded as "English" it would be more logical. I also wonder if perhaps the selected language should be the one highlighted in orange, although not totally sure on this as the logic of the alternate language looking like a button (in orange) also makes sense

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