kongondo

What's the intention? Your 'title=Dev' suggests to me that you do not want the page to be viewable by non Devs? non-superusers? Why not just leave the page unpublished then? You (the superuser) will be able to view it, others won't. Alternatively, you can use permissions and/or roles. If the current user doesn't have the permission, PW won't allow them to see the page.

I've quickly had a look at the Hanna Code page and couldn't find any API to achieve what you are after. The only things I can think of are cookies or session. You can save the ID of Page B in a session or the values of Page B that you are after (modified, created, etc) $return = $attr["url"]; $id = (int) $return; $embeddedPage = $pages->get($id); echo $embeddedPage->body; $modified = $embeddedPage->modified; //echo date("l jS \of F Y h:i:s A", $modified); $session->set('my_page_id', $id); // $session->set('my_page_modified', $modified); You can then grab the value using $modifiedDate = $session->get('my_page_modified');

Not currently. You will be able to do this in the next version of Media Manager (v12) which will be out in the next couple of weeks. Media editing has been changed. Editors can now edit the media page directly, meaning, you can edit the image and other fields directly in the page where it lives using native ProcessWire features. ProcessWire now allows the editing of a file name by clicking on it. By editing the media page directly, you will be able to do this and lots of other stuff. See the gif below for an illustration.

What do your image settings look like? You might have a max of 1 but with a formatted value setting of array of items. It also depends whether you are in a module context or output formatting is turned on/off

I must be missing something then. Do you: Want to grab $embeddedPage and use it later on in your page or Want to echo $embeddedPage properies (body, created, etc) right within your Hanna Code? If #2, you are already doing it by echo $embeddedPage->body. E.g., the following works correctly for me (code in the Hanna Code itself) $return = $attr["url"]; $id = (int) $return; $embeddedPage = $pages->get($id); echo $embeddedPage->body; $modified = $embeddedPage->modified; echo date("l jS \of F Y h:i:s A", $modified); I have this Hanna Code Tag in Page A, where 1049 is the ID of Page B. [[test url=1049]] That outputs Page B's modified date. But this seems too easy. I have a feeling I'm still not getting you.

Yes, it is possible, either using MSN, your own recursive function (there's loads in the forum), or using Menu Builder. Could you point us to a link with example code? The ones I have seen have <ul> as well as the <div>. You seem to be saying that the <ul> is not required? If you are still stuck and wish to try something else, I can guide you how to build the menu using Menu Builder .

What does your hanna code look like?

I always get confused about this. Try accessing it using wire('page') and see if that helps. From the PHP Usage notes section on here http://modules.processwire.com/modules/process-hanna-code/

Maybe it is easier (even better?) to instead bootstrap ProcessWire inside your WP and use ProcessWire to create ProcessWire pages. https://processwire.com/api/include/

This has always been the case as far as I can remember. Similar to rootParent of home: $h = $pages->get(1); echo $h->rootParent->id;// outputs 1 You'd think home shouldn't have a root parent, but it does. I think both were intended, but let's see what @ryan says.

Just a couple of comments. If I understood correctly, you are creating favourites on the fly. There are a couple of issues with this approach Unless user_id is a multi-page field, it means a favourite item cannot be shared between several users Related to above, what if user A and user B both have item X as a favourite? The items, the ones users are comparing, are they pages in ProcessWire? If yes, than you are creating two parallel page trees with the same content. One, you have a list of items (Product A, Product B, Product C, etc whose parent is /products/). Users then favourite them, /favorites/product-a/, /favorites/product-c/, etc. You now have Product A and Product C in two places. in your new Page() code, you are not checking if that page already exists as a favourite. Depending on the ProcessWire version you are using, ProcessWire will silently create a duplicate of the favourite, just with a different name (i.e. they will share a title but have different names, latter ones with a timestamp suffix). Maybe you haven't shown the whole code, but in your listing, it is good to first check if the user is logged in. If you could confirm what the lists for comparisons are (i.e. are you scraping some other website, or using REST or are they pages in your ProcessWire website), our response could be more definite. Also confirm what type of field user_id is.

How does your code look like? Is the user logged in or did you try by getting the user and echoing their saved values? e.g. $u = $users->get('user-name'); If you save manually when editing the user in the PW backend, does it save? Do you have debug on? Any errors? Depends on the sort of persistence you want. If fav items need to be saved for a short time only, then, yes, cookies or even sessions would work. If a user clears their cookies for whatever reason, they'd need to start over. There's other issues to consider as well, for instance, if the user is on a shared computer. I'd go for saving favs as pages. It is more foolproof - e.g. easily grab and display a user's favs. It is also more flexible. Item is no longer available, easy to tell user 'item is no longer available', etc.

I am not sure I follow. A page, whether a child or not, has access to all the fields contained in the template that that page uses. So, if $entry is a child page, $entry can reference any field in the template it uses. If the selection option field is called categories, $entry->categories references the option field. If it is a single select option field, then you can just echo that out. If it is a multiple selection option field, you need to loop through it, i.e. foreach($entry->categories as $cat). I'm probably missing the obvious here, being late Saturday and all that .

It depends on how you've set up the backend. You say logic for favourites, so I assume a user can have more than one favourite. I am also assuming that users need to login (i.e., no guest users). Finally, I assume an item is a PW page. Two approaches I can think of. Save users to the fav item. I think this is what you are doing in your code above. I wouldn't take this approach though. I'm not sure it would scale very well. I'd do it the other way round (#2) Save favs to users. I explain below If your items are pages, it is easy to reference them in a page field. Create a page field that accepts multiple pages. Let's call it favs. Add the page field favs to the user template. I am assuming your users are normal users. This way, we only need to save the ID of the favourite item. Using that, we can get its title or whatever field it has at runtime to display to the user his/her favourite items. Here's some untested code (could throw up errors). // inputs for favourites; could be whatever input, as long as can take multiple items // <input type='hidden' name='add_fav[]' value='1234'> a listed item // <input type='hidden' name='add_fav[]' value='5678'> another listed item // add favourites for a LOGGED IN user // @note: using ProcessWire $input if(count($input->post->add_fav)) { foreach ($input->post->add_fav as $fav) { $user->favs->add((int)$fav); } $user->of(false); $user->save('favs'); } // fetch favourites for a LOGGED IN user $out = ''; if($user->favs->count) { $out .= '<ul>'; foreach($user->favs as $fav) { $out .= '<li>'. $fav->title .'</li>'; } $out .= '</ul>'; } echo $out; Do you have a need to use $_POST rather than ProcessWire's $input? Edit: If you have losts of listable items (i.e. the selectable pages in the user field favs, although the users will not be interacting with the field directly in the backend, you might want to use autocomplete as the input for the page field.

Thanks. I'd already tested these and no joy. Still doesn't work.

Yes, still needed. That'd be awesome @Zeka, thanks!

None of you cool kids use Windows ? Or you don't use multi-sites option #1?

Oops, that was my mistake. the radio input and select were sharing a name, product_id. I have renamed them to product_id_color and product_id_angle respectively. This does not solve your problem though. If you want to combine the values of product_id_color and product_id_angle, you need JavaScript. You can either create a hidden input product_id whose value is dynamically changed to be the combined values of product_id_color and product_id_angle or on form submit, do the combination then. This assumes you cannot do the combination server-side. That combined value could look like 1234_5678 where 1234 is the value of the color and 5678 is the value of the angle. Server-side, you split/explode the string at "_". I could write some JavaScript later (for the values combination) if you are struggling with that. On the server-side, how are you handling things? Where is the form being submitted? Are you using Padloper? What post input does your system expect, product_id? We can help better if we have this info. Or maybe you mentioned this already and I missed it?

setArray() http://processwire.com/api/ref/wire-array/set-array/ http://processwire.com/api/ref/wire-data/set-array/ You might want to use the WireData one if WireArray throws errors about does not accept ...etc type. $arr = array('color'=>'silver', 'make'=>'volvo', 'age'=> 2, 'seats'=> 5, 'style'=>'suv'); $wireData = new WireData(); $wireData->setArray($arr); echo $wireData->make;// volvo echo $wireData->age;// 2 As you can see, the $arr indexes/keys become the property names and values the values. So, you might want to use single words for the $arr keys

This is most likely because you had bad HTML in your markup. Your angles <select> does not have a name attribute; instead you put the name attribute in the <option>. See my code above with the refactored code.

Maybe the code can be cleaned up a little? E.g. no need for two loops. I've also cleaned up the HTML a little bit (e.g. id=color_page_id rather than id=page_id), given the select an ID so you can space it out as needed instead of using a <br>, etc . It also needs a name attribute. $colors = ''; $angles = ''; foreach ($page->variations as $p){ // add colors if ($p->color_choose->title){ $colors .= "<input class='{$p->color_choose->title}' type='radio' name='product_id_color' id='color_{$p->id}' value='{$p->id}'>" . "<label class='{$p->color_choose->title}' for='color_{$p->id}'></label>" . "</input>"; } // add angles if ($p->angle_choose->title) { $angles .= "<option value='{$ps->id}'>{$ps->angle_choose->title}</option>"; } } } $angles = "<select id='angles' name='product_id_angle'>{$angles}</select>"; // add colors and angles markup to $addcart $addcart .= $colors . $angles;

Now I understand you clearly. You are right, 30 inputs are not great, even with selects. I see several options all of which involve JavaScript for the friendly front-end side of things Together with the inputs you currently have above (your colour and angle inputs), add hidden markup, maybe a <ul> list with the values for each combination, e.g. <li data-colour='green' data-angle='90' data-some-value-for-this-combination='abc'>green-90</li>, etc. On click add to cart, if both colour and angle have selections, use JavaScript/jQuery to get the <li> whose data-colour == "selected colour" AND data-angle == "selected angle". You then update your cart depending on the selected combination, e.g. using its data-some-value-for-this-combination, which could be its ID. @note: if the some-value is a price, you only use it for visual feedback to the user. Prices should be determined server side Something similar to above except we send the selected combination server-side immediately using Ajax so that we return and display the value of "some-value-for-this-combination" I had another option but I have forgotten it in the course of typing, hehe! OK, server-side, you need somewhere to stay your combinations and their values. I don't know how you are storing this but it should be pretty straightforward to find your product using value of data-colour and data-angle. If you have the different colours and angles stored as pages, then the markup should ideally have the respective page IDs and send these back using Ajax. E.g., rather than green, you would have data-colour="1234" and data-angle="5468". Hope the above make sense.

You basically have two choices Convert the PageArray into a regular array OR Convert the social media array into a WireArray (e.g. each to be a WireData which you throw into one WireArray) #2 will give you the advantage of easily sorting by your custom date field. I am not sure though if a WireArray can be combined with a PageArray just like that (although the latter is from a WireArray, so, yeah, maybe it is possible). Edit: Depending on your operations and size of the PageArray, since Page objects can be big, to have the best of both worlds (1 and 2), you can use explode as per @Zeka's suggestion, but convert that into a WireArray. Then, convert your social media array into a WireArray and add it to the first WireArray. You can then do your sorting by the custom date field. I don't know how much this will cost you in server resources though. Just a thought...

$pages->find('selector')->explode() is all ProcessWire API

Yeah, although an echo would probably work better