Soma

Thanks Ryan! Glad you like it. Wow thanks, did you read my mind? I was about to look for this particular function to see if there's a way to map those. Thanks for pointing out! I'll quickly put it in and update the repo. Edit: Just updated the fieldtype, tested and pushed to github. Now we can use range.min, range.max in selectors!

This behavior has been integrated in current nightly build of PW 2.2. It can be configured via WireTabs module settings. StayOnTab (Module for Processwire2+) This new module remembers the active tab you are on and opens it after saving, or reloading page. https://github.com/somatonic/StayOnTab This is still in progress. Just wanted to share and recieve some feedback.

Or ? $elem->value = 1036;

Or you can even use it to set states. For example use it like an option 1,2,3 This would be possible, but then why have a slider? This also would require to implement some validation through js or the module. I suggest, if you have large numbers you can put it in the near and use arrow keys to get to the value you want. EDIT: Just found that there seems to be a bug with the left range handle not able to move with keyboard arrow keys. I found out that the current jquery 1.6.2 core included in PW is the reason. I copied in latest jquery 1.7.1 and it starts working.

Yes this is using jQuery UI skinning. Thanks!

I've reworked the whole module to use integer fields and it works a little different now. Best of it is, it now works in selectors and uses real integers. I have updated the repo on github just now and also the first post to reflect the changes. If you installed it already you should first uninstall it before updating.

Thanks slkwrm for the feedback. Greatly appreciated. 1. Sorry I forgot in the hurry to remove the site link at bottom. 2. I overseen to update topnav.inc, though that won't translate topmenu per se. You'll have to do a translateion for /site/templates-admin/default.php yourself. 3. see 2. 4. Seems that's caused by the messed box model, I've set a padding to input fields, that will cause it to be acutally bigger than 100%, and map marker css sets the inputs to 100%. I've implemented the new css3 box-sizing and it fixes the issue, though only for modern browsers. But it's ok I think and not a "big" issue. 5. I've made it a tiny little bit smaller Thanks, I've updated the repo on github.

Well I realized it still isn't as good as I wanted. It has still a text field for storing data. And the fact that it can used as one value and two value range makes it hard to implement with only 1 integer table field. I'm not sure how it would be possible to have 2 integer fields on a fieldtype. So this current version doesn't work with selectors. Would it be possible to have selector like "range[0]>100, range[1]<120" ? I don't understand how selectors works exactly. Simplest would be for doing ranges is having two single value slider with real integer field type. But I think it's not as ideal. So i'm kinda stuck here and little overwhelmed with how this else could be implemented better. Edit: I think I'm on a path that works. Even with page selectors. I'm doing a little more testing and experimenting. Actually I'm diving a little more int PW's implementation of fieldtypes and how it works. So it works now like "range.data>100, range.data2<120", and output is array like before $page->range["data"]. Will hopefully get it working soon and update the repo.

I recently updated the theme to support latest PW admin changes. Like site link, language and some minor changes. I've put the "Site" link simply into the top main menu at front. That's where it makes the most sense to me and it's the one with the least resistance and cleanest (not another element to decide where it should go and something to maintain) https://github.com/s...theme-pw2/tree/

Thanks guys! Glad you like it. Thanks for the idea. Not sure where this could be useful though. But something with a "code" field would be possible. I'm more thinking something to be able to do floats. This could be done with formatter function too. So you could specify digits precision and have 0-1000 would really mean 0-10.00 - but operations like this could be done on output too. Also there's still some other settings that might be useful but these are more visual than functional. I'll add 1-2 more for type max,min for regular slider.

I dont' think this would be a big deal. By that I mean to support it, it would just be the opposite of the one we got already. Though I could get confused when using both. But certainly something to consider.

I don't really get it. Notice class has something to do with flash session data?

Before we can repeat, we can slide! ProcessWire2+ RangeSlider Fieldtype This fieldtype let's you create slider input fields in the admin using the built in jQuery UI Slider. You can use it as a regular single value slider, or enable "Range" setting under details of the field edit screen, which gives you two number. In the front-end templates you can use the field as follows: If used as single value slider echo $page->fieldname If ranged slider is enabled echo $page->fieldname->min echo $page->fieldname->max Use in selectors strings With a regular single value slider $pages->find("range=120"); If range slider is enabled $pages->find("range.min>=100, range.max<120"); It comes with various settings. ------------------------------------------------------------------- - range enable - width of slider (%) - default value - min value - max value - step - prefix for displayed value(s) - suffix for displayed value(s) Download ------------------------------------------------------------------- You can download the Module from Github. https://github.com/s...nic/RangeSlider How to install ------------------------------------------------------------------- 1. Download and place the RangeSlider folder in: /site/modules/ 2. In the admin control panel, go to Modules. At the bottom/top of the screen, click the "Check for New Modules" button. 3. Now scroll to the RangeSlider Fieldtype module and click "Install". 4. Create a new Field with the new "RangeSlider" Fieldtype. Once saved you can configure the fieldtype, with various options under "Details" tab. I have made some testing, and installed on different PW installs. But if you find any issue, I'd like to hear. Have fun!

What diogo said pretty much sums it up. It's quite simple and works. In many projects I work directly/remote on the server, most of the time it's a subdomain like dev.domain.com, once ready to go live it's just a matter of transfering or switching dns. There's no "best" way, its always individual to the one developing. I also have a setup on projects, where I can transfer files and DB using shell and rsync from live to dev install and vis versa. It can be handy if you want to do major tasks on the site and don't want to break live site.

How about a slider you could configure to go from 1-3 Maybe different types of input slider with ranges would make a cool new inputfieldtype like my colorpicker. I will consider maybe doing one soon.

Your welcome, yeah some more search options would be great. Yes, that would be a great addition and fun to do module. I don't know when I will have time, but would like to participate. I would also first have to try and look at the current shop module and maybe start with something simple first and extend further step by step.

Thanks apeisa, you rock! I haven't got the time to take a lock at new version. I'll at weekend. I got a little snippet you might find useful, and consider implement it. public function ___executeSearch() { $this->fuel->breadcrumbs->add(new Breadcrumb('../', 'Orders')); $this->setFuel('processHeadline', $this->_("Order search result")); $id = (int) $this->input->post->searchquery; $result = new PageArray(); $result = $this->pages->find("template=sc-order, id=$id, include=all"); $result->import($this->pages->find("template=sc-order, sc_payid=$id, include=all")); $out = ''; if(count($result) > 0) { $out .= "<h2>" . sprintf( _n("found %d order", "found %d orders", count($result)), count($result) ) . "</h2>"; $out .= "<ul>"; foreach($result as $order) { $date = date($this->config->mydateFormat,$order->created); $out .= "<li><a href='../edit/?id={$order->id}'>#$order->id, #$order->sc_payid, $order->title, $date</a></li>"; } $out .= "</ul>"; } else { $out .= '<p>'.$this->_("No orders found").'</p>'; } return $out; } // i didn't use PW field style, but simple form markup on top of order overview $out .= "<form action='./search/' method='post'>"; $out .= "<label>Payment ID: </label><input type='text' name='searchquery'/> "; $out .= "<input type='submit' name='submit' value='suchen'/>"; $out .= "</form>";

Edit: oh hi and welcome gcplan, glad you found us! I think you'll have no problems to make a custom integer fieldtype/inputfieldtype module, that would check for a certain range and output an error when saved. It's possible to create field setting you would be able with 2 integer fields to enter a upper-lower bound. You could even implement jquery script to check on runtime before saving. Jut have a look at how the PW integer,float,text fieldtype/inputfieldtypes are done. I think you'll have no problem if you're fluent in php. PW makes it very easy to do what ever you like in that regard.

AAA, BBB BUUUMMMM my head explodes. What? I don't get it.

Cool apeisa, just was thinking about this after writing the post. The translatable default text in templates could be used as keys like. Then having an _front-end_ english pack installed would do the trick. Acceptable solution I think.

I'm currently using translation in my front-end and I was thinking about the matter and how it really works. So if I decide to go and change a single letter or word in the default text code in a template, all translation originating from this phrase will get obsolete and need to be translated/entered again. Since it isn't key based translation, I'm not sure again, if it's still a good/the best choice when doing heavy multiple language site development. I feel it could get frustrating, when once all languages are in place and you spot a typo or decide to change the word or phrase, all languages need to be updated again as well even if it isn't needed. What are your thoughts about this particular problem?

Thanks apeisa! Glad you found it.

Wasn't there a related issue where it turned out it had to do with some strange php security module, that wouldn't allow certain/multiple post vars. I'm not sure and couldn't find it.

Yes, that's certainly a good new way to do variations. Then it would be a little different dealing with the product id, as with child pages it's easy. So the id in the cart saved will match that variation. That sounds great! Yes the dependency of the orders management module on certain fields will make it a little harder to make it flexible, but it may could be handled as "custom-fields". Then those are only informational and there could be some sort of standard output of those on order detail page. Also what I have implemented is a little search field to search for a payment,order id. Just as an simple process function. I think it also would be cool to have a per year or month, day filter in the overview. Just as example. You're right. We should wait until things are more settled. It's also easier to see as you move along. I'm sure it will be great! I don't want to bother or interupt. I think once you got the most basic version finished, it will be a lot easier for me or others to help coding and extending if needed.

Really nice to see this taking shape, thanks apeisa! I'm currently looking into your new version and at what I've done to your previous version. Also looking at what I've done with the current shop I'm still working on. It got delayed because of missing content, images etc. There's a couple things I'm thinking about the different parts and how they could be extended or made flexible/configurable in some parts. Module Cart Looks good and somehow still the needed basic functionality. I'm asking if it would be possible to include variations ( simple child-pages approach ) into the cart model? This would only require to change the following functions: - getTotalSumFromItems() - renderCart() // though I've done the cart rendering in a template I created "sc-cart". In my version I just done it like this: // see if variant page has price field // if not choose from parent product page if($product->sc_prize) $total_price = $item->qty * $product->sc_price; else $total_price = $item->qty * $product->parent()->sc_price; ... Maybe I could make a fork and try to implement those myself? What you think? Also I see something for "shipping costs" is needed in the cart rendering, and of course in the order management. What have you planed on this? Maybe it would in some cases be useful to have some discount based on the total cost, and no shipping costs after a minimum of total costs too. Those are thing commonly need in shops as I see it. Checkout Module As with the previous version, I see you still only basic fields for the order form. I think it would require some more in most cases. - Having a gender is questionable but definately something to consider. Event it not needed at the end it would be there. - I would see having a "prename" "lastname" instead of full name - Instead of address having a textarea, I think it would be better to have "address" for street, "zip", "city" and "country" separate Regarding the order template and complete order, I think there will be some more fields needed. - 1 field for the "payment_id" as some payment services generate a payid in addition to the order_id, that comes from the shop. - Depending on the payment service, there's possibly some more fields that could be useful, like payment card type used, last 4 digits of card, if the order wasn't successfull theres error codes provided. I have no idea as of now how this would be doable in the current model. I think some sort of basic set of fields that would serves for all payment types would make sense? Or would it be possible to make configurable to add custom fields to the order, so it would be dynamicly handled depending on a config and saved into a text field serialized? I have hard time seeing through this. Also how do you plan doing the validation on the order form? I currently have the whole shipping-address-completeorder-to-payment process handled in 1 template with custom validation class. In my current shop, once the process is complete I save order using shop API with status "not-complete". Also in same template it handles the return from the payment service, changing the state of the order to "complete". But because the payment method I use is on demand, with authorisation for the payment, I need to have a status "payed" once it's payed and "processed" once it's shipped and done. --- Basicly I'm trying to get a clearer view of what module should provide what function. How could hook-able functions being useful here and for what? Also I really would like to bring in my experience from the current shop I'm doing, which seems to have little different requirements than yours. And see if it could be done without touching the module codes. But I have a hard time doing so still