apeisa

Just made quite a bit refactoring on these modules and streamlined that it's totally same API usage no matter if you use "single product payment" like Stripe or "shopping cart, multiple products" like PayPal. Also PayPal payment verification is based on invoice id also, so you cannot spoof it with any earlier payment (earlier verification was amount only).

Nothing too fancy there: download links will be available right after payment (in the form of www.yourshop.com/d/?code=NXSAIJF129JD) and also in invoice email you customer receives. You can set how many times and how long links will work - if not unlimited.

With pages you have "category" pages already Otherwise you need to build category views using url segments, get variables or so... Of course if you use categories only for presentation, then options might be faster / easier.

S3 works with tokens, that can be made expire like in 20 seconds, so that works of course. I will definitely support S3 at some point, but not on the highest prio currently (not all shops need digital downloads and not all need s3 for that).

I haven't given any thoughts on subscriptions. I suspect they are pretty hard to implement in general manner (and rare payment processors support subscription). I think it would be nice addition to the Payment Stripe, but probably something we should leave out from base class.

Fields and templates have export and import utilities, that are usable from UI and API.

Just crafted PayPal module also: https://github.com/apeisa/PaymentPaypal

I think both can be achieved: free-form language names and using language specific language packs for modules. There are certain benefits in not forcing only natural languages - I have used language support for client specific modifications for otherwise shared documentation for example. I think the flow should be something along these lines: When creating new language, UI recommends choosing real language from list (BCP47) or adding custom language name Modules could ship their translations in /lang/xx-xx/ format and if there is match with xx-xx and any languages already found, those languages would be automatically applied for module. There we would have both: convention (using standard languages) and flexibility (using languages for different use cases).

Jason, have you tried pw with HHVM?

Here is very simple abstract class that I hope would get ideas and contribution from community, so that different PW projects could use same payments methods in generic way: https://github.com/apeisa/Payment Currently Payment modules just assume it's found from /site/modules/Payment/Payment.php, but I would love to get it autoloaded somehow (I went with PW module dependencies and transformed the base class into PW module also). Also I have tried to keep this as minimum as possible - hopefully I have not left anything too important out. I have also created one two payment modules, that use this base class: https://github.com/apeisa/PaymentStripe/ https://github.com/apeisa/PaymentPaypal/ Please visit their repos for examples.

Same here.

Docebo? No idea what it is, sorry.

How there is two markers?

Look if there is already good php library for social login and use that.

"/blog/" should be fine too.

I would probably keep this 2.6 only. Most use is when releasing new site, so probably most usage will be with latest and greatest

Adrian, no need for custom field for that. Just set parent=page.otherpagefield as selector value for your page field. And thanks for the explanation, I got it! Nope, I mean this: parent=page.manufacturer kind values for page fields "define selector to find pages". They create ajaxified UI for field relations.

Not sure I understand this module? Is this for creating relation between two page fields? When I select Europe, then in next field I can choose countries from Europe? That is already supported in core. But there seems to be much more in this module than just that. Maybe I should just try this

Like I mentioned at Twitter - we at Avoine use it mostly at backend page filtering, but I have used it twice on templates. First time was related content kind of solution and other was custom RSS feed builder.

http://modules.processwire.com/modules/schedule-pages/ Ah, it seems you know that already? Is there something missing regarding your needs?

Is there any particular feature from PHP 5.4 you are using? I think many are using Ubuntu's release cycle (5 year LTS from 2012), where there will be PHP 5.3. for two more years (of course possible to update to 14.04).

fmgujju: just reset your password (logout and pretend you have lost your password).

Craig, I had used the Facebook login and didn't have a clue what password (if I even had one). I simply did password reset to get local password and used that when joining into directory.

Mass editing view! Clicking field name on left would open field settings in modal - clicking field name on right would open template context field edit in modal. Interesting concept! It also shows nicely, that same field can belong to multiple template (ie. field is independent from template).

Peter, have you tried the latest dev? Adrian and Ryan might have baked something for you