kongondo

@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.

Beta testers needed ?. Please send me a PM if you'd like to help. An active subscription/current license is required. I'm happy (and frankly relieved ?) to announce Media Manager v 012 is ready for beta testing. Please accept my apologies for the delay. With this version: Only ProcessWire 3.x (preferably the latest master) is supported from now on. Currently, only AdminThemeUiKit is supported. (we may support Reno theme in the future). Changelog ProcessMediaManager (Media Manager Library/back-end) New UI: Responsive and closely matches ProcessWire theme (UiKit) Media thumbs shown in their natural orientation Upload Anywhere: Upload directly to Media Manager Library using drag and drop New edit media page in modal (natural ProcessWire page) (respects locked status and Media Manager edit permission if present) Create image variations in natural ProcessWire page during editing Add, edit, display and access custom ‘columns’ (fields) added to media manager templates (e.g. add text field to media-manager-image and access value using Media Manager API) Hide media types menu items if media type not in use Global setting for allowed media types (e.g. image and video only) Hide ‘All’ menu item New filters dashboard Updated and freshened up upload’s dashboard Option to upload ZIP archives as is (to save as documents) vs. to decompress them (recursively) Preview PDF documents in ‘gallery mode’ (if browser supports it) Selection of media is now identical to how images thumbs are selected in ProcessWire FieldtypeMediaManager Enable Upload Anywhere (for InputfieldMediaManager use) Allow users to edit media displayed in a Media Manager Inputfield Change whether to use text or icons for action ‘buttons’ Custom fields: Display and edit ‘columns’ (fields) added to media manager templates InputfieldMediaManager New UI: Responsive and closely matches ProcessWire theme (UiKit) Media thumbs shown in their natural orientation Upload Anywhere: Upload directly to Media Manager Library using drag and drop AND simultaneously insert into the Media Manager field on the page being edited Inputfield Media Manager markup updated/refreshed using Ajax when media is added or edited. No need for a page reload (so you won’t lose unsaved changes on the page) New edit media page in modal (natural ProcessWire page) (respects locked status and Media Manager edit permission if present) If a media in a Media Manager Inputfield is unpublished or trashed, it is automatically removed from all Media Manager Inputfields present on the page (including its variations) and the fields refreshed using Ajax View values of custom columns (not all Fieldtypes supported for viewing although all supported for accessing using the API). These are refreshed on the Inputfield using Ajax once editing is complete. Better support for repeaters Preview PDF documents in ‘gallery mode’ (if browser supports it) Selection of media is now identical to how images thumbs are selected in ProcessWire Inserting image variations Media Manager API (working in the front-end and manipulation via the API) Access media in a Media Manager field on a given page (see examples below) In the example below, we access custom fields (columns) added to the image media template (media-manager-image). In this case, two fields have been added. A URL field named links and a text field called headline. You can add any field you want. Please note though that not all fields can be displayed in the backend (for practicality). In the frontend, there are no such restrictions and you can access any of the fields as shown below. Your MediaManager object gives you access to the fields. For instance: $m->name_of_your_field. Below, we have $m->links and $m->headline. Please note that $m->media still returns the first media in the MediaManager object. In case you have added more than one media to your media field, e.g. more than one image added to one MediaManager object (done via editing a Media), you can access all of them using: $m->mediaField; In the case of image media, $m->mediaField returns a Pageimages object which can be iterated. This assumes, of course, that your media_manager_image field accepts more than one image (the default). The default setting for number of files accepted for other media types is 1, hence $m->mediaField returns a Pagefile object. You can edit these fields (media_manager_audio, media_manager_document and media_manager_video) to accept multiple files is you wish, in which case $m->mediaField will return a Pagefiles object which you can loop through, access using first(), last(), eq(n), etc. // get the media manager field on the page $mediaContent = $page->media_manager_tests; $tbody = '<tbody>'; $tbody .= $mediaContent->each(function($m) { if($m->typeLabel !='image') return; $thumb = $m->media->height(130); $img = "<img src='{$thumb->url}' alt='{$m->media->description}' height='130'>"; $tds = "<td>$img</td>" . "<td>{$m->headline}</td>" . "<td><a href='{$m->links}'>{$m->title}</a></td>"; $row = "<tr>{$tds}</tr>"; return $row; }); $tbody .= '</tbody>'; $content .= "<div class='uk-overflow-auto uk-width-1-1'>". "<table id='news-outlets' role='presentation' class='uk-table uk-table-divider uk-table-hover uk-table-justify uk-table uk-table-middle uk-table-responsive'>". "<thead>" . "<tr>" . "<th class='uk-width-small'>Preview</th>" . "<th class='uk-table-expand'>Summary</th>" . "<th class='uk-width-medium'>Link</th>" . "</tr>" . "</thead>" . "{$tbody}". "</table></div>"; Output of the above code

Not really, 'regular'. Have a look at this post. It is old but still relevant (see module prefixes):

What do you mean by this? Echo the value of a field or echo a field name? If the latter, spaces are not allowed in field names (neither are hyphens; only underscores). If the former, you can just use these PHP functions strtolower or mb_strtolower (for multibyte support)

Ah, yes. As documented here as well: http://processwire.com/api/ref/wire-array/import/

I've only had a quick look at your post. It could be 'default' is a reserved word/keyword?

Hi @xportde, It would be and it doesn't need to wait for the future. It is already here ?. With the new version (announcement imminent), you can add as many fields as you want to your respective Media Manager templates. Let's say you want a URL for your images. All you would need is to: Add a URL field (in this example, called link) to the Media Manager image template (media-manager-image). If not accessing your Media Manager Library directly, create a Media Manager Field (let's call it albums) and add it to your page's template, say basic-page. In the Media Manager Field (albums) settings, enable 'Allow users to edit selected media'. Edit a page using basic-page template. Add images to the field Hover over an image and click the Edit link. Edit your link field to add your URL. In your template file, you can access your URL like this: $albums = $page->albums; $out = '<div>'; $out .= $albums->each(function($m) { if($m->typeLabel !='image') return; $thumb = $m->media->height(260); $img = "<img src='{$thumb->url}' alt='{$m->media->description}' height='130'>"; $o = "<div><a href='$m->links'>$img</a></div>"; return $o; }); $out .= '</div>'; // OR: Using foreach /* $out = '<div>'; foreach ($albums as $a) { if($m->typeLabel !='image') return; $thumb = $m->media->height(260); $img = "<img src='{$thumb->url}' alt='{$m->media->description}' height='130'>"; $out .= "<div><a href='$m->links'>$img</a></div>"; $out .= $m->body; } $out .= '</div>'; */ echo $out; And that's it. Any field you add to your Media Manager template is available as $m->name_of_field, where $m is an instance of MediaManager field as per the example above. More examples in my next (eventual) post(s). I tried to make a video, or an animated GIF, even a simple screen capture to show you what I mean but everything failed! Lots of artefacts, etc. I've recently moved to Linux, so still finding my way round.

Thanks buddy. I appreciate it. ?

Welcome to the forums @MateThemes Yes. It is here. I quote: You can set up shipping by postcodes, states/provinces, countries or continents. All these are just sub-divisions of the same thing :-). A group of postcodes make a city, a group of cities a state, a group of states countries and a group of countries continents :-). Padloper will not have something like 'what type of shipping zone do you want to create?' Instead, you create the zone and throw in the countries or provinces (optionally delimited by postcodes) you want. If you want a European Union zone, throw in the countries that make up the Union in that zone and the applicable shipping rates. If you want a zone for South America, throw in the countries that make up that continent. If you want zones for Middle, Far and Near East, specify the respective countries for those regions. Please note that it is not an all or nothing system. If you don't want Brazil in your South America zone, then don't include it in the zone but instead create a different zone for it, unless of course you don't ship to Brazil, in which case, just exclude it entirely. Hope this answers your question.

Welcome to the forums @spackmat, Just in case you couldn't find it, here's the docs on hooks. Have a look at these two files as well, under /site/: ready.php and init.php. Normally, you place your hooks in either of these, depending on when you want to intercept an event.

What @LostKobrakai said. :-). I don't think this is something Padloper should handle. If prices need to be adjusted, we have Hooks for such things. Alternatively, you could add custom price fields to the product template and use those instead, following some logic. So, this is up to the dev. On a side note, I'm not sure I get the rationale of adjusting a product's price based on a customer's location. Shipping, yes, but not the actual product price. Is it because of exchange rates? Aren't those handled by the merchants? I'll consider these when we get to that stage, thanks. My initial estimates was 6 months from when I got started (please see first post). I can't promise that though; it could even be shorter! Thanks for the interest.

No. It means I'm using different versions of Tracy on different sites (multisite) on the same machine ?. Edit: Maybe this old version is why Tracy is not appearing in modal windows or that has always been the case?

In fact I misspoke in my previous post. I've been using the new version but on a different local site. On the site I'm currently on, I have the older Tracy :-). Yeah; now I seem to remember this. It was of course on the other site where I had the new Tracy. I even played around with Adminer, I recall. Good to know, thanks.

I'm using the icon; it's not hidden for me. On this machine I'm running 4.8.24 The new window came handy today. I needed to see different windows at the same time and docked, the console was in the way, plus I just couldn't make it bigger. I've done it before, but can't remember how :-).

Awesome work @bernhard and @adrian. Hopefully one day I'll get to test all these wonderful stuff being added. That might be a while, given that it's only today that I discovered the Tracy console can be opened in a new window! ?

@teppo <aside>Dude, you threw me off with that new avatar ?. I was like who's this replying to Teppo's post; I haven't 'seen' them before...</aside>