kongondo

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

I don't understand this. What input is this? The module works like this: A. Define Field/Inputfield Create and edit a Field of type Variations In the field settings, create the custom inputs that will be needed for each product variation irrespective of its attributes. For instance, price, quantity, sku, etc. Currently, you can only do this in the field settings which means non-superusers cannot create custom inputs. This will change in future releases Save B. Define Attributes (and their values) and Build Variations Create attributes and their values. These are independent of each other and of products. Meaning, you can reuse, e.g. Size attribute with other attributes, e.g. Colour Each attribute has one or more values. E.g. the attribute Size can have Small, Medium, Large, etc. The attribute Colour can have Blue, Orange, Yellow, etc values. You then build variations. E.g., build the variations for a Product called "ProcessWire T-shirt" You give the variations (definition basically) a name You then add attributes you want, e.g. Color and Size. However, not all the values of these attributes will be available automatically. So, you need the next step You then select the values of the attributes you want. For instance, for size, you might want all the available sizes, so you add them all For Color, let's say you only want two colours, so you add Yellow and Blue Save and link that variation to your product page and you are done. You get a table with a combination of all of your available Sizes and Colours for the given product (un-editable) as well as input for the custom inputs you created in A., i.e. Price, Quantity, SKU etc. Each individual variation (i.e. one row in your table of variations) has its own ID. Just simple 1,2,3,4 etc. In our example, a row would consist of color,size, price, quantity,SKU. The price, quantity and SKU are inputs where you specify the respective values in relation to that particular variation. Frontend implementation is up to you. You use the available combinations as returned to you by the Inputfield to build the markup for product selection. You will need custom JS to send values back to the server. Have a look at the documentation here. You have access to each combination/variation ID as follows: $out = ""; $variations = $page->variations;// returns a VariationsArray which is a WireArray derived object foreach($variations as $variation) { $out .= "<input type='hidden' value='{$variation->id}'>" .// variation/combination ID "<p>Colour: {$variation->colour}</p>" . "<p>Size: {$variation->size}</p>" . "<p>Price: {$variation->price}</p>"; } echo $out;

No. You enter your own values for every single variation. For instance, you can enter price, SKU, quantity for the following combinations of the same thing Blue, Small Blue, Large Etc Variations can contain two or more attributes, e.g. Blue (colour), Small (size), Short Sleeves (arms), Plain (style)

I've not heard of plans to automate the process, so, for each new install, you will have to set the configuration.

It is a new ProcessWire 3 requirement, I think from version 3.0.5x

@jmartsch, Please clarify where this code should go to avoid any confusion, thanks.

Welcome to the ProcessWire and the forums @fermion You don't need to touch that file. Please see this post for the solution. You might want to read the whole thread for context

It's all in the documentation here . Please also read the last couple of post above yours. Since your site uses various languages, you need to pass render() either the ID of your menu, its Page object or an array of menu items. As per the post above yours, this limitation will be resolved in an upcoming update.

That should make your work a bit easier then. Note that currently, multi-instance requires that your PW installations are local (i.e. on the same server) and accessible on the file system. https://processwire.com/blog/posts/multi-instance-pw3/ The difficulty in your case is editing the template files responsible for pulling data from the central site. Say the data from the central site will be pulled by home.php template files in your sub-domain sites, you will have 100+ home.php files to edit (hopefully once). On the flip side, it means you have per/site control about the data from the central site you want a sub-domain site to pull in.

OK, let's try debug this. The code works for me, so maybe I didn't understand your setup. That's what I have in my code. There are two possible pages that can be referenced. (1). mannequin-modele with ID 1024 OR (2) autre-artiste with ID 1025. Of course, these are the IDs I used in my example and need to be edited as per your needs. I'll try to post an animated GIF/video of my test setup to see if it matches yours. This bit I don't get. First, I thought the child pages are edited manually in the backend. A choice is made, the page is published which triggers the Hook to move them to their new parent and change their template. Is that not the case? What form is this? What sort of code does it contain? Is it being sent from the frontend? Secondly, are you saying you are posting the form to ready.php? How are you doing that? I am not sure ProcessWire will allow you to do that. Incidentally, are we talking about the same ready.php found (or created) under /site/ready.php ? Without question, yes . I'm happy to have a look if the site is online if I could get a temporary access.

I would have placed my bet on memory then, but you say there are no errors? $config->debug is true?

No error thrown? I haven't checked but guessing maybe a limit on the number of joins SQL allows? (The field Title is auto-joined).

On queries: Execution Times (see Ryan's comments in that thread) findMany() https://processwire.com/api/ref/pages/find-many/

Just created a new post. This takes into account your updated OP. Since you are in a multi-lingual setup, I've decided to use IDs rather than names. Less user-friendly, but with inline comments, you should be fine. In /site/ready.php $pages->addHookAfter('save', function($event) { // get the page object saved $page = $event->argumentsByName('page'); // only on pages with the temporary template or their parent has the temporary template if($page->template !='directory_page_temporary' || $page->parent->template != 'directory_listing_temporary') { $this->message('page has wrong template'); return; } // if page still unpublished return if($page->is(Page::statusUnpublished)) { $this->message('page still unpublished'); return; } // no choix made yet, return. qui_1 is a page field of single type if (!$page->qui_1){ $this->error('You need to make a choix!');// OR show message instead //$this->message('You need to make a choix!'); return; } // good to go; assign new parent and template # determine new parent and new template $p = ''; $t = ''; // choix: mannequin-modele (this choix page has ID 1024; easier to check by ID in multi-lingual site) if($page->qui_1->id == 1024) { $p = 1021;// new parent is mannequins-modeles and has ID 1021 $t = 'directory_page_mm'; } // choix: autre-artiste (this choix page has ID 1025; easier to check by ID in multi-lingual site) elseif($page->qui_1->id == 1025) { $p = 1022;// new parent is autres-artistes and has ID 1022 $t = 'directory_page_autre_artiste'; } # save if($p && $t) { $page->parent = $p; $page->template = $t; $page->save(); $this->message('page template and parent changed'); } else { // some error } });

I am trying out multi-instance support in a multi-site setup (option #1, multiple databases) on a Windows Machine (but using a LAMP stack). I am getting a Fatal error in ProcessWire.php #line 877, Failed opening required '/F:/vhosts/sandpit.dev/wire/config.php' (include_path='.;C:\php\pear') in F:\vhosts\sandpit.dev\wire\core\ProcessWire.php on line 877 I am using the following API $path = "F:/vhosts/sandpit.dev/site-mediamanager/"; // OR // $path = "F:\\vhosts\\sandpit.dev\\site-mediamanager\\"; $url = "http://mediamanager.sandpit.local/"; $site = new ProcessWire($path, $url); Here is Line #877 require("$rootPath/$wireDir/config.php"); In my code, $path is an absolute path on the windows machine. In the above example, I want ProcessWire to find the /site-mediamanager/config.php, which is a multi-site running off one Wire powered through the main /site/. As you can see in the error, ProcessWire is adding an extra forward slash to the path, i.e. '/F:/vhosts/sandpit.dev/wire/config.php' instead of 'F:/vhosts/sandpit.dev/wire/config.php' which obviously fails. I have traced the origin to line #784 in ProcessWire.php $rootPath = '/' . implode('/', $parts); // remove siteDir from rootPath The pre-pended / causes the error. Remove that and multi-instance works fine in my environment. Before I report this as a bug, has anyone ran into this issue? Alternatively, could someone on a Windows machine please test the multi-instance feature for me? Maybe even someone using an absolute path on any machine? Preferably test in a multi-site setup (option #1). If this is a bug, it would be nice if it gets fixed before the imminent master release. PW version 3.0.85 (but also tested on the latest dev version). Thanks.

I also don't quite follow. I'm not sure what pw-panel is so I'll comment on pw-modal. When you open a pw-modal, the contents of that modal are opened in an iframe as has been pointed out to you. This means, you have the parent window (the one that opened the modal) and the iframe. The iframe can open another iframe too, but let's not go there :-). Using JavaScript, the modal and parent windows can talk to each other in our case, because they share an origin. I am assuming, you are opening a page in your Process Module in the modal. E.g., you are in some Inputfield (editing a page), click on some link with pw-modal class whose url is /your-process-module-name/some-page/. The modal will display the contents of /some-page/. Of more importance to you, I am guessing, is detecting ajax requests WHILST in /some-page/. Is that it? Remember, whether opened normally or in a modal window, /some-page/ will load all the assets of your Process Module. So, you should be able to fire Ajax calls from YourModule.js AND you are able to use YourModule.js to communicate with (e.g. ParentPage.js) or update markup on the parent page that opened the modal. Is this what you are after? Sorry, I went on a bit much there, but just trying to get the gist of your question. I may be way off base here, but we'll see .

***308***

Just wondering. All Fieldtypes need to have a column 'data' in their database table. This is defined in their getDatabaseSchema(). If you look at this method in the parent field type class, wire/core/Fieldtype.php, it has this comment each Fieldtype should override this in particular (with respect to the data column). I notice that this module does not define data in its schema but I would have thought that shouldn't be a problem since it first calls the parent's parent::getDatabaseSchema() (which has data defined) and builds on that. Just thinking out loud.

Hmm, the Author Field is blank..(in the module's page).