kongondo

Please refer to the first post in this thread, under 'Pricing Model'. There are no immediate plans to change the prices. There is no firm release date. It may be more than 4 months away.

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

Sounds to me like this is more of a fork than a hack ?.

Glad you are feeling better ?.

I like Tabulator ?. I had a bit of a play with it some months ago, for some pet module I was working on.

Sounds pretty straightforward then. At its simplest, two date/timestamp or similar fields, with start and end dates. Depending on the granularity you want, you can set up a cron to check memberships once a day, i.e. focus on the day not the exact time of expiration (which would mean more regular crons). Then: pseudo code: if(today > endDate)// membership has expired However, not sure what exactly you want in your membership 'module' (besides the usual - name, email, start_date, end_date). I'm still not clear what exactly you want to settle for given our previous discussions. Do you: Want to send the member an email to remind them that their membership has expired and that they need to renew it? Want to automatically renew their membership, raise an invoice and send to member but meanwhile set their membership status as 'pending'? Want to automatically renew their membership, charge and collect payment from their specified payment method and send them an email confirmation? If 1 or 2, you can do that already with ProcessWire. No need for Padloper. If #3, as previously stated, Padloper does not automatically collect Payments. I'm not sure if the PayPal module can be modified to accept recurring, automated Payments. I haven't gotten round to working on it yet and it may be a long while before I do that, I'm afraid.

https://github.com/processwire/processwire-issues/issues/648#issuecomment-410758636

Ooh. My reading was that @porl had found some; ... they were just not decent ?.

Nothing comes to mind, I'm afraid. Which ones did you find?

Hi @alexpaul, Glad tidings or spamming us? I have removed the link in your post. If your question is not related to ProcessWire, please check in the WooCommerce support boards instead.

By the way, this is what we are currently doing with Media Manager. If you add a field to a media manager (in-house) template, media manager will find it and will make it accessible to you via its API. Essentially it means you can use Media Manager for a whole range of things.

This is an interesting thought. My opinion has always been: teach a man/woman to fish = pw core and API (basically, /wire/) man/woman fishing = /site/ So, modules, or as others call them, custom plugins, are exactly where the fishing should be happening. I don't find it at all WordPressy since ProcessWire's (custom) modules, unlike WordPress's, are not the cobbling together of disparate things to provide a solution to a problem that should have fundamentally been resolved by the core. Agreed, but therein also lies the beauty of reusability. If I find myself building blogs with every/most sites that I build, it makes sense to package the blog solution. In other words, modules ?. The point about second-guessing what fields a user needs is a good one, but it is not one without a solution. This is easily solved (again, back to blog module) by a 2-step installer that asks what fields the user needs. We also have Fields like Table and DynamicSelects that allow you to add/remove fields/columns even post-install.

I see. Seems like a special case, especially the bit about adding the fields to two selected templates. I might have a peek at the module if I get some time.

I agree, and this is a situation I've encountered. I just do what can be done with JSON, the rest I do using other API, as an after-step. I beg to differ. I don't get the point about being messy. If you have an installer and an uninstaller, that covers the job. The blog module, for instance, needs to store preferences data somewhere. Whether these are stored as data in a field on a page, or in the modules config, they all end up in the database and are transparent to the user. Storing such preferences in a file (I'm not saying that is what you are suggesting) seems inefficient to me and prone to error, i/o. I don't think this is a problem at all. You always remove templates first (after deleting your pages, of course). It doesn't matter if it has fields, using the API, the template will be removed. You then delete the fields you installed. Coupled with clear documentation and a big warning sign on the module's config page, there shouldn't be any cause for confusion. This is how I do it in all my bigger modules. In addition, my uninstall routines do not automatically remove the fields and templates created by the module. Instead, there is a cleanup page accessible only to superusers. If they hit 'remove' having read the warnings, it means they know what they are doing. I'd love to hear your opinions regarding storage of module data, though.

I'm assuming this is addressed to me? I've never used that module so can't comment much. What I meant was that sometimes some data is just related and it makes sense to have them in one field, similar to the example I gave. Assuming that was some customer's or member's data, with one simple query, I have all their info rather than querying several tables to get info about one entity. Interesting you mention this. It's something I've thought about previously. If I had to redo the Blog module, I would combine some of the fields. What do you see as drawbacks to combing/collapsing related fields into one field, storing their data as columns? Technically, the database doesn't care. Yes, some people (me included) hate horizontal scrolling when viewing databases, but it's not a thing one does daily ?.

@bernhard, I'm not sure, but I think this is a different issue from what @Robin S stated. I think the point was that, modules do not have to create fields, etc, unless they need them. Now, how those fields, templates and pages are created is a different issue. Not wishing to OT this topic, IMHO, we do already have the API for creating, deleting and checking for field and template collisions. Regarding the former two, we have the normal/older method of new Field() and the newer setImportData() [OK, you would need to export the JSON first, but that's a one off thing]. As for collisions, it is a simple as getting the field; if a field was found; then abort. Maybe I'm not getting the point, and we'd need to discuss this in a different thread anyway ?.

What Robin said above. In addition, sometimes you don't need many fields, but just many inputs. I don't know how comfortable you are with PHP and you would need to study ProcessWire Fieldtype modules, but rather than have lots of fields that do small things, sometimes it is easier and more efficient to create custom fields whose (database) columns will hold your many inputs. For instance, rather than have a field each for first_name, last_name, middle_name, telephone_1, telephone_2, hobbies, profession, etc...you can create one custom field that will hold all these related data with each piece a column in that field. In ProcessWire-speak, those columns are subfields which you could access using the API as $myField->firstName, $myField->lastName and in selectors like so, my_field.first_name, my_field.last_name. Just thought to throw this in there, just in case.

You seem to be confusing Fieldsets and Fieldgroups. They are very different things. Fieldsets are special fields to help you group fields together for the purposes of how they are displayed on a page during edit. In a sense, they group the Inputfields of the fields within the Fieldset. Each Fieldset is then displayed in its own tab during page edit. As usual though, the order or even the presence of fields on a page have no bearing on their appearance in the frontend. Back to the main question, I quote the definitions of Fields, Fieldgroups and Templates as per the docs:? Fields That just means a database table, that is created via ProcessWire using a defined schema and installed as a module. You can read more about them here. Fieldgroups You will rarely have to interact directly with Fieldgroups. Each template you create has a corresponding Fieldgroup. A Fieldgroup just says these are the fields available in this template. Hence, it is possible to reuse a field across different templates (i.e. across different Fieldgroups). More about them here. Templates This one is self-explanatory, me thinks ?. More about them here.

Yes. PageTable is a free ProFields module ?. I'll still move this topic though to general support.

Automatically 'charge' should be able to work since it is basically creating a manual order in an automated way (cron, hook), if that makes sense ?. As for actually taking payment automatically, that, we don't currently do as we don't store customers' payment details. (nor will we be heading in that direction). Maybe by setting up recurring payments, say in PayPal, it might work? I've not tried it so just guessing here. This would mean automatically triggering a PayPal payment request, again, something I've not tried before.

Yes. They say it's the next big thing since...eh, the last next big thing ?.... https://medium.freecodecamp.org/a-beginners-guide-to-graphql-60e43b0a41f5 https://blog.apollographql.com/graphql-vs-rest-5d425123e34b https://graphql.org/ https://www.prisma.io/blog/top-5-reasons-to-use-graphql-b60cfa683511/ https://medium.com/open-graphql/graphql-1-140fab436942 ...and some reasons why you may want to avoid using it... https://www.robinwieruch.de/why-graphql-advantages-disadvantages-alternatives/ https://blog.logrocket.com/5-reasons-you-shouldnt-be-using-graphql-61c7846e7ed3

On a broad level, there's really only two types of products; physical and non-physical. The former require shipment, the latter do not. To the extent that a service is basically a non-physical product, yes, you can use Padloper for that, similarly to how some people use it to sell digital products. However, managing memberships is outside the remit of the module. You could use Padloper to handle payments and related transactions but would have to implement a separate membership management. I think, iirc, there might be one or two membership modules on the forums. Having said this, currently, Padloper cannot do recurring payments (at least not automatically) which is something you would need for your monthly payments subscriptions.

The notion of core in MODX might be different from the one in ProcessWire (maybe?). Btw, I don't know if you've seen this post on MODX to ProcessWire welcome brief? It might be of interest ?. One of the philosophies of ProcessWire, one that makes it very extensible is the fact that everything, all its building blocks is a module. Yes, even the admin (backend) is a collection of modules. Modules are just PHP classes. You have your classes (i.e. modules, or the site's custom classes) and these live here: /site/modules/. ProcessWire has its own core classes: the ones designated as modules live here: /wire/modules/. The are other classes, in fact, the main classes of ProcessWire, aka the core, and these live here: /wire/core/. In order for ProcessWire to know about and register your classes, they have to live where ProcessWire expects them to, i.e. /site/modules/. Now, this does not mean that all your classes have to be modules. No; you can have custom classes (i.e. my_class.php) living in /site/modules/my_module/my_class.php or /site/templates/includes/my_class.php (@note: includes here is just arbitrary) which you access from within your registered classes (modules) or from within your template files. Any attempt to access such classes directly will be blocked by ProcessWire for security reasons. This just means you can have helper classes or other libraries you need for your modules which ProcessWire does not need to be aware about (in respect to registering them). The foregoing means that... ..is not necessary in ProcessWire. your /site/ is already outside the core. It survives upgrades and ProcessWire never touches it. It just communicates with it (bidirectional communication). All ProcessWire core variables (e.g. $wire, $config, $fields, $page, $pages, etc) are available everywhere for your use, both in the backend and the frontend. I hasten to add that ProcessWire will not automatically install your modules for you. If it finds a new module, it will just let you know that it has found a new module. If it finds duplicates of the module, i.e. either duplicated under /site/modules/ or under both /site/modules/ and /wire/modules/ , it will alert you to the fact and will ask you to choose which one you are going to use. This means that you can duplicate a core module found in /wire/modules/ under /site/modules/, edit it to suit your requirements and ProcessWire will happily continue serving the copy under /site/modules/ and yes, it will survive upgrades. This is not always a good idea though, as the mother module could get some upgrades which you would be missing on and/or require. So, in ProcessWire, we develop our modules under /site/modules/. Most people who develop modules use a versioning system, invariably git, and host their modules on GitHub, BitBucket, GitLab, etc. Secondly, many people make use of git's branches and work in the dev branch. All development and testing is done under that branch. When ready for production, they merge into master branch. For modules submitted to the ProcessWire modules directory, if the project (code) is hosted in GitHub, ProcessWire (the site) reads the master branch of the project to access the README and the download link. In the past, I have used symlinks to link my module to different ProcessWire versions. For a quick and dirty check, I have occasionally had two wires, e.g. wire and wire27 which I rename to suit my needs RE ProcessWire version. Many of us here develop using the latest ProcessWire dev. I cant' speak for everyone, but I think many then use (if they need to) a ProcessWire 2.7 just for final tests. I doubt many of go back and forth between versions (i.e. between 2.7 and 3). No ?. As long as you name your module classes as per ProcessWire requirements work with what suits your needs. The above is just the basics. We have people here who work in teams and have slightly different approaches, but the basics are the same.

Hmm. The hyphen has always worked for me so something must have changed. It's also not consistent with templates in that case, since, a hyphen still works there.

I can confirm this. I've noticed this since a couple of weeks back. It still works with templates though. I haven't tried this, but until the recent past (and similar to the templates list), -mytag should collapse the list (notice the hyphen). So, a recent change broke this.