adrian

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

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.