apeisa

Good news Oliver. I am very happy to get any feedback, even very minor changes to make code better. There are lot of compromises, since I don't handle OO coding that well. Also, haven't really focused on security yet, so that is something that I hope everyone takes a very critical look.

Support for stock levels added (with a shop wide setting to allow/disallow negative stock). Also now all settings do work (thanks to Ryan's fix on core).

Little OT: just realized that InputfieldInteger doesn't allow negative values. Not sure why? It saves negative values ok, but sanitizeValue changes them to positive. So in database I have -10 but edit field shows 10. Maybe a setting for this?

Great stuff! I know that in our company we will need this for sure, so big thanks from here. I have never implemented ldap myself, so cannot comment much. Only suggestion is to rename your class to SessionLdapAuth so it would go into session category on modules list.

Ahh... now I get it. There is $notices variable. Very nice. If others are thinking how to use it, just take a look at notices.inc from templates-admin folder. You can access the very same $notices from your template code. And setting these notices is super simple: $session->error("Houston, we have a problem"); $session->message("Hello world!");

It would be great if there would be an easy way to add flash-type of session variables. Here is citation from codeigniter docs:

With every software that alters database tables (like PW, Drupal etc) there is always the problem when deploying from dev to live. Initial migrate is easy, since you can just export whole database (or use exporter module), but after that it gets trickier. If you add code to your development version - that is easy one, but if you add fields/templates or change their settings then you need to add those same changes to your live site also. I think current "best practice" is just redo your changes manually, before updating your code. Mostly those are minor changes so not a huge problem. Ryan is also planning for a tool to import & export whole templates and their fields easily, which should make bigger changes also easier.

Yeah, it works, thanks for fixing this! BTW: Github sending automatic email when you mention my @github-username is superb feature!

Ryan, thanks for the fix, it works now.. almost. If I have another fieldset later on, it will lose those values. My intended setup is acually like this (without initial wrapper): FIELDSET Textfield Textfield Textfield ENDFIELDSET FIELDSET FIELDSET Checkbox Checkbox ENDFIELDSET FIELDSET Checkbox Checkbox ENDFIELDSET ENDFIELDSET First fieldset saves ok, later ones fail. Next I tried it with this setup: FIELDSET Textfield Textfield Textfield ENDFIELDSET FIELDSET Checkbox Checkbox Checkbox Checkbox ENDFIELDSET Similar effect: first Fieldset saves ok, other one fails. But when I go this flat: FIELDSET Textfield Textfield Textfield ENDFIELDSET Checkbox Checkbox Checkbox Checkbox It does save all the values.

Alex, welcome to the forums. That can be done from admin site. Just edit page "Admin" on your page tree and change it name under settings tab.

FieldtypeInteger actually has this commented function: /* TO ADD BACK LATER public function ___getConfigInputfields(Field $field) { $inputfields = parent::___getConfigInputfields($field); $field = $this->modules->get('InputfieldInteger'); $field->setAttribute('name', 'minValue'); $field->label = 'Minimum Allowed Value'; $field->setAttribute('value', $field->minValue); $field->setAttribute('size', 20); $field->description = 'The smallest number allowed by this field.'; $inputfields->append($field); $field = $this->modules->get('InputfieldInteger'); $field->setAttribute('name', 'maxValue'); $field->label = 'Maximum Allowed Value'; $field->setAttribute('value', $field->maxValue); $field->setAttribute('size', 20); $field->description = 'The largest number allowed by this field (may not exceed ' . PHP_INT_MAX . ")"; $inputfields->append($field); return $inputfields; } */

Thanks for the snippet Soma, I will implement that for sure! I will probably add more options, to search with customer name etc. BTW: if you are interested (and have time), ShoppingReports would be nice independent module that is needed. Something to get overview on your sales weekly / monthly / yearly and maybe by product etc.

Yep, that's the method. It's pretty strange since values seems to be saved, but if load another page and then come back they are back to defaults. Without fieldsets it works fine.

One idea that came into my mind is to keep default language (the one that is defined in files) as something that is not actually directly used. So you would have 4 languages: Default English German Finnish Guest user has English chosen instead of Default. If you need to change something. you don't edit the files, but you translate it from English files through admin. This way it would be more like key based translation, but with one "free" language (if you leave English language empty, it will use defaults).

Diogo: your idea is maybe little bit better than mine. If you add repeater to that, then your repeater would be just one textfield and one dropdown. Instead of combination (AAA, AB etc) you would choose A. B, C or D Then you would create blocks, one by one: A A A A B C B A D And that would become: AAA AB_ C__ B_A D__

I think this is great example for what Soma was asking for in Repeatable fields topic: multiple "block" templates. It would allow this very easily. I am not sure if that is direction where repeater is going at the future. But I guess there is at least one decent workaround: a) Wait for repeater to be released b) Create repeater, which has: 3 textareas (all collapsed if blank) and one Page reference. That would be dropdown called: Layout c) Layout dropdown has different options: AAA, AB, BA, C, D If you choose AAA, then it will use all 3 textareas for content. If you choose AB, then first textarea is for A column and second is for B. C and D uses only first textarea. Just on idea and not sure how usable that would be in real life scenario. You gotta try

This is the topic: http://processwire.com/talk/topic/552-i-get-the-404-page-when-editing-home-page/page__hl__%2Bsave+%2Bpage+%2Bpost__fromsearch__1

There was! That is probably exactly same issue, since it was also about multiple textareas.

I'm not sure about that, but it is my best guess. You could compare that your mysql user has all the same rights on the server than it has on your localhost. I think that install script checks those, but since you skipped that it doesn't help us here. What I would actually do is go back to your localhost, use Profile Exporter (https://github.com/ryancramerdesign/ProcessExportProfile) and try to install that profile to your server. Other option is to try install just fresh default pw on your server first, install script might spot some problems. You can install multiple sites, since those doesn't need to be on webroot (pw runs nicely on subpage like www.domain.com/mysite/).

You can try that. But when you create new field, pw actually creates new table to your database. I think the problem is somewhere in mysql user permissions, not pw. Not sure though. The case is, that all your "old fields" that you created locally are working, but when you have created new fields on server, they have failed somehow.

Of course you lose data by doing that, but if I have understood correctly you haven't been able to write for those fields? Or are you?

Through PW.

Andrew, nope, those are just template settings that you can edit on template field. Nothing wrong with those. If you remove those two fields you added from text-page, everything starts working? Profile exporter is a module which wraps the site as a installable site profile. It is pretty handy on when you transfer site from local to web.

Soma: you might want to try the newest version. Field settings doesn't work yet (it seems that pw doesn't like fieldsets on admin, posted about that on another topic), but you can play with defaults on getDefaultData() function on Checkout-module. I still want to make the flow cleaner, but this is starting to take shape. Oliver: I created another example payment method so if you want to take a look how I did the module implementation. Super simple really, but works nicely. There are two parts. First: $paymentModules = $this->modules->find('className^=Payment'); That snippet finds my installed Payment modules. I use that to render dropdown to choose a Payment method. Then the other part is like this: $paymentmethod = $this->modules->get("{$order->sc_paymentmethod}"); return $paymentmethod->processPayment($order); ProcessPayment(Page $order) is required from every payment method (I am using abstract class instead of interface, since I wanted them to have $this->completedUrl automatically.

Hi joyfulcode and welcome to the forums! Have you yet read http://processwire.com/api/selectors/? It has pretty good examples how to get other pages. If you provide more information how your site is build (site tree, templates used), what data you need and where I am sure we can provide better answers for you.