porl

I saw someone made a preliminary mollie payment module, but I don't think it handles subscriptions. Gave me some more things to think about, thanks!.

6 hours ago, kongondo said:

I'm sorry I don't get this one. Please clarify.

Never mind, I looked into how the modules worked and don't see any issues with other parts of the site using them with Padloper installed. I should have checked first.

I've been out of the loop for a while (my day job doesn't involve a lot of development) but I'm starting to use Processwire again for a couple of projects. Dating back to when I used it originally I noticed that not only were new features added very quickly, they were usually added for people (like me) requesting things that other CMS platforms might have said "no, you can't do that". Here we have Ryan saying "I noticed you trying to do X so I added feature Y to the core which should save a lot of work". Glad to see this pace is still continued and makes me feel like I'm in some cool "elite" group that has access to some secret magic that users of other platforms miss out on.

Hi kongondo

Number 3 would be the ideal. I was mostly wondering if padloper could be modified "easily" to do that, but it looks like it might be too far outside its scope for now. I think I should probably start with 1 or 2 and maybe look at the payment-paypal module to see if I could work towards that.

Side question, if I was to use a module like that (payment-paypal) would it be an issue if I added Padloper for another part of the site?

haha yeah I should have worded that better. I haven't found any at all.

What I mean by membership modules is something that can track "subscribed" members. So a member can sign up for a monthly subscription and the module will return if they are up to date or expired. Maybe how many days left etc.

This part I think would be easy enough to make, but not sure on the payment side. This is why I thought something like padloper would be a better starting point. Still not sure though.

Did anything come of LiteBB? Sounds promising but I can't find anything unfortunately.

Thanks again for your response, kongondo. I'll keep looking into different options. I haven't been able to find any decent "membership modules" though, do you happen to know of any?

Thanks for the quick response! If I was to use Padloper for the payment side, would it be difficult to, say, add to a template the option to "automatically charge me each month" and then use some other module (cron like for instance) to use Padloper's api to charge again on the schedule?

I feel that if that is simple enough to hook into and I could also get simple information (last time this member paid for the month membership etc.) then it might make a good solution. Otherwise you might be right to suggest looking at other "membership modules".

Just wondering, would this module be useful for "services" and "memberships" or is it very tied to the idea of products? I'm thinking of migrating my Judo club's management from an off-the-shelf site I pay for and build something more specific to us, but one of the tricky parts is managing student memberships. E.g. They pay for one month of classes and can choose to "subscribe" to monthly payments.

I know the system isn't made specifically for this kind of use case, but would it be simple enough to use for that or should I look elsewhere/do it myself?

Thanks!

An update for anyone reading - the Template Engine Factory (along with the Twig module for it) seems to work perfectly in 3.x. Thanks for the suggestions!

If I was to find that Latte didn't suit for some reason do you think your module could be easily adapted to Twig or other templates? Or is the Latte "engine" pretty well entwined with the module?

Edit: Sorry I should be clear - I'm not asking if you could do it for me, just if it might be feasible for me to "swap out engines" if needed or if it would be basically a rewrite anyway and not worth it.

Sounds great! I've been out of the web game for a bit so didn't see Latte before, but it looks interesting. Definitely keen to see it when you share it!

So Template Engine Factory still works fine with 3.x then? If so I guess it's my best bet.

Hi all

I'm about to try out ProcessWire 3 but I've been out of the loop for a while. I used to use Twig as a templating language (I wrote the first very naive module to use Twig on here but switched over to the much better ones developed by others). Whilst I'm not attached to Twig to the point where I wouldn't use anything else I'm still not a fan of "raw" PHP as the templating language for my "views".

Is ProcessWire 3 at a stage where other templating languages can be used? I know that some of its design should make it simpler to make those kinds of modules but have any been made? If not is there anyone working on one (and ideally a forum thread I can see any progress)?

I understand that these things take time, so please don't think I'm demanding anything or expecting someone to knock something up for me overnight. I am just wondering where things are at so I know if I should look into it further or hold off for now.

Thanks

Hi hafa and owzim

I haven't been on here in a while as my work commitments were with things other than web development. I have been asked to once again look into migrating our company's old site to something new (which will very likely be ProcessWire with the Twig templates) so I will be looking at this again.

I haven't yet tried the module with the latest build of ProcessWire but unless Ryan has made some major changes to things I can't imagine there being an issue. I will of course test it properly when I get to working on the site and make any updates if necessary.

As for it's interaction with the cache I admit I am not sure. Twig caches itself to "raw" PHP code, which I believe has quite good performance, but beyond that I have not tried anything.

Let me know if there is anything more you'd like to know and assuming my work priorities don't get shifted on me again I will hopefully be able to look into it

Wow, this is absolutely incredible!

One thing though (only minor and I may be in the minority): I have never really liked per-site licenses for things. I have no issue with people using them, I just prefer not to purchase them myself where there are other options.

Would you consider a per developer license (for more than the per-site license obviously)? My biggest reason for this is that I make a lot of small sites for family friends etc on the side and whilst this functionality would be great I don't want to be thinking about purchasing components each and every time I make a site for someone like that.

Of course this is far from a demand. I don't expect something for nothing nor do I think that my reasoning is the 'only right way'. All I am saying is that you will have a guaranteed customer here if you do a one-time-purchase type option

Either way, it is really great to see some more advanced functionality being done with the ProcessWire functionality. I can think of at least two sites that I can likely make use of this module, regardless of the license setup you decide on.

Perhaps a more simple solution is modifying the repeater code to make the 'repeating' functionality switchable. By this I mean it would become a more general 'field group' module with the option that the fields can be repeatable (even if this is set by default). It would also be nice to have a way to hide the fields inside from the general field list to keep things tidy.

I've updated the module with some configuration options and (hopefully) clearer instructions.

It is using functions from the development branch of ProcessWire but they are for convenience in template design and can be worked around (using things like page.get('field') instead of page.field for instance) if you need to run it on an older build before the development code gets merged.

If there are no bugs that people find then you could call this 'finished' (ignoring any future enhancements) and should be pretty stable now. Hopefully someone finds it of use. I've been making some test sites and will be definitely using it for at least two production sites I will be starting work on soon.

I think it's a great idea. Assuming you can do it without any compromising data I'd love to see how other's approach things. I'm still settling in and working out my optimal workflow with ProcessWire so any other approaches are good to compare.

No worries. I'm in no rush to update the module online. I have a few 'housekeeping' things to do with it first anyway. Adamkiss suggested packaging Twig itself with the module (assuming the license allows it) which would make for less installation steps, and I also need to do the install/uninstall routines still as I haven't had any time to do so yet.

Works perfectly thank you. I won't update the module 'officially' until the config option is in the normal branch (so people don't need to check out the dev branch to use the module) but my testing shows it has fixed the problem.

Thanks again.

I don't think it's a related behavior here. Ultimately $this->config and wire('config') are the same call. But $this->config gets passed through a __get() method method, so it can be interrupted if __get() gets overridden and doesn't pass control to wire() when it finds an unrecognized property. It's still a mystery to me as to why $this->config didn't work in your module.

No problem. As I said it works fine with wire('config') and I'm happy to use that. It is most likely that I missed something or did something braindead and this was causing the error. If it isn't related t this issue I'll politely step out of the way

Thanks for your updates to this module, and for posting to the modules directory.

No problem. I've been busy with other projects so didn't get the chance to do much unfortunately. Hopefully I can get some more work done on it.

My opinion is that the more you can help the user, the better, so long as it's something that can be removed in the same way during an uninstall(). If it's something that would be more tricky to uninstall, then maybe better to let the user create it so that they also have some ownership if/when it comes time to uninstall.

This is what I thought. My main issue is determining what to do if the user has files in the views directory. Should I remove it anyway (I don't think this is the best bet); give user a message stating that it should be removed if they no longer use it; or give some way (checkbox) for them to select to delete it on uninstall? Personally I like the last option, so is this something that is relatively easy to do in an uninstall routine? Is there another module that has user interaction in the uninstall method that I can look at for reference?

Just to confirm, you want to have a way to prevent ProcessWire from throwing an exception when a method is called that it doesn't recognize?

Yes. At first I thought this behaviour would cause more potential issues than it solves, but it would definately make templates cleaner (there are many cases where it is unclear whether you can use, say, page.image or you have to use page.get('image'). This makes things a little messy and difficult to debug due to the fact that variables might be called from inherited templates. There is an 'if defined' type function in Twig, but this method itself can trip ProcessWire's exception.

You could definitely override it for any given class, by extending the class and defining your own __call() method, but that will only affect calls to that particular class, and I'm thinking that's not what you want. It will be relatively simple for me to make PW's behavior (as to whether it throws an exception or not) configurable, so that may be the best bet, unless there's some way for Twig to catch the exceptions and continue normally.

If you don't think it is feasible to do it in the module itself then I guess if you are happy to add the configuration option it would help a lot.

By the way, I know I said this before but I am continually impressed by your friendly and open involvement with the community here. This is what Open Source is all about. Thanks again.

Sounds really interesting! I'll have to take a look and see if I can use any ideas to make the Twig module I have been working on nicer. Even now I'm thinking the name "RenderTwig" makes more sense than "TemplateTwig".

Sorry, I meant $this->config. wire('config') works fine, but $this->config failed when I had a tilde in the url (I had localhost/~porl/processwire as the url at the time). I ended up using wire('config') instead and it all worked well. At one point I added a line at the start of $this->config = wire('config') and then it worked but that was obviously a bit of a nasty hack so I didn't use it.

I wonder if this is related to the odd behaviour I had in the Twig module when I had to use wire('config') rather than $config?