Soma

Have you tried turning off session challenge?

Ah I've read that but didn't get it! Surely over-engineering. Not a UI pattern that someone would recognize IMHO.

Another thing I noticed with the UI dropdown menu. Hover over "Setup". It drops down. Now move the cursor fast over the first open menu item and right back up to the top menu item. The dropdown will stay hidden. This can be annoying. It looks like this is a timeout issue with this jquery menu.

Updated a install with latest version. Just noticed the top user pulldown with the wrench, the wrench icon it switches to an eye when I hover to open the pulldown.

Thanks Ryan I will test it soon and report back. There is no "/" then. It would be "/de/".

These problems may arise when installing a module manually and then updating using modules manager. This mostly has to do with folder naming of the module. MM takes class name entered on modules directory so it's possible you named the folder different when manually installing a module. Not sure there is a good way to prevent that but if you install modules explicit with mm only this shouldn't be a problem.

Just pushed a new dev branch to my fork of Shop module with the current version of the discount module included. Working nice so far. https://github.com/somatonic/Shop-for-ProcessWire/tree/dev https://github.com/somatonic/Shop-for-ProcessWire/commit/80663d3512ff251b0f616f812645b24573e19834 If anyone interested to try to see. This is my how my cart looks:

But you don't accept, we don't even have it Well then there would be the hook for your needs

Thanks Beluga. This is just a simple discount feature and nothing to do with vouchers or anything complicated. Just a simple calculation. Thing is that most simple shops I build are only local shops and most have discount depending on total sum. So I need that feature, that's why I'm working on it. I have no plans to make a full featured thing. Further here in Switzerland we're the only country in the world that has no 0.01 amount, smallest is 0.05! So I even need a special rounding. So far I have added just a method (hookable) just for that in the discount module or maybe it would even make more sense in cart module itself. It's obvious there's many things to consider and not every shop is the same, so at least a little flexibility is helpful here.

I'm currently creating an additional shopping module type for simple discount calculation in the cart. The idea is as soon as you install this module, shopping cart is recognizing it and adds it into calculation and outputs it in the cart. The module work like the shipping cost module, but will only be needed once, so no abstract class is needed. You then can enter percent of the discount and the threshold. I need this for a current simple shop I'm building. In the past I never needed that and on first shop I built I did this by building a custom checkout. Do you think this is a good idea? Or would it be better to modularize these things more in cart/checkout so one could add them without the need to modify "core" shop modules?

Every page in PW requires a "name", it's like a ID that makes the page accessible either via a view or API too. Nothing actually to worry about, just use a generic name.

Then I would create a new template "user-order" add a single page field "product" and a datetime field to the template. Then create a new order with this template , and save it under the user page. I think you just need to allow children on the family settings on the user template.

The page field will have them in the order they were added already.

Martjin, add() works for both actually. The user template has nothing to do with template files. And as long as you don't touch wire folder you're fine upgrading.

Sorry I was too quick reading wrong on my small mobile narrow view. I think you could also file an issue on github.

This is not a bug? Because if you have pw in a subdirectory the directory is in the url. That's the intended behavior.

While using the shop module, here a thought that come to mind every time. I would like to see that the forms output by the checkout being ProcessWire forms generated via API. This would allow to modularize/extend this part much easier. Currently it's just html markup concatenated together and it makes it impossible to modify it without modifying the module. Another option would be to make methods that are generating the markup hookable, but I'd rather like PW form API fields. This would also allow for easier rendering and validating the form. What you think?

Adde a couple commits with a PR to Shop Module with some small fixes and additions: https://github.com/apeisa/Shop-for-ProcessWire/pull/8 - added support for variation price, so you can have price per variation. Cart will look for it and use the price in repeater item, else it will take the one from page - added 2 new methods to cart module: getProductPrice($item) will return product price from either repeater or product page getProductPriceTotal($item) will return product price total for quantity in $item->qty - made those methods bookable also so they could be modified maybe useful for discounts etc. - updated checkout module for this new price calculation I'm working on a simple shop currently for the 4-5 time now and taking the shop module always a little further on the way. Thanks

I voted already for two rounds but no chance.

Works everything as it should. I can access (when logged in) or can't access (once I log out) the file. But after trying around I found a strange behavior with when removing guest view access for the page. At first it works as it should. Then I unpublish the page, and it isn't accessible anymore (as expected) Then I publish the page, and only then me as the superuser can't access the file anymore but I should be able to. Once I give guest role view access to page again and start again, it is the same procedure.

// via field settings $field = $fields->get("title"); echo "width:" . $field->columnWidth; // via template context $tpl = $templates->get("basic-page"); $field = $tpl->fieldgroup->getField("title", true); // true for template context echo "width:" . $field->columnWidth; https://gist.github.com/somatonic/8323844

http://lmgtfy.com/?q=processwire+hide+pages+in+admin First search result shows a thread, where you even liked my posts where I explain and show an example module of how it could be archived. So there's no way to do it without a mean hack. I'm still waiting for Ryan to implement something to make this easier and brought that up on github again.

As vagely mentioned the LanguageSupportPageNames module is the problem here, as it doesn't load in a Bootstrap it seems. There's no page rendering happening so ready() method of it will never get called. I'm using heavy page creation importing with multilanguage and also ran into this, and also need a solution sooner or later, so i tried again. A solution I found is to add a hook yourself in the script on Pages::saveReady and delegate that to the LanguageSupportPageNames which usually seem to handle this part of page name saving. So if you add this code above your bootstrap, it will work as if in a page template. wire()->addHookAfter("Pages::saveReady", null, "hookPageSaveReady"); function hookPageSaveReady($event){ wire("modules")->LanguageSupportPageNames->hookPageSaveReady($event); }

If you follow and read the link martijn and kongondo posted http://processwire.com/api/fieldtypes/images/ you'll see that it's actually all there mentioned.