kongondo

This is great! I know it is a lot of work but it would be really nice to have inline comments about what areas/elements the different styles target. An accompanying cheatsheet or graphic could also do the trick.

Robin, the CSS is not loading for me (you preview). Dev console throws an error as well about $ not defined.

Hi @Jonathan Lahijani, Thanks for work on this! I know your previous work and you make some great videos. I'd like to venture a few opinions if I may? For this sort of video, I think what would work best is an explainer video. Basically, a 'selling points' or 'attention grabber' sort of video. The segment should be between 40 seconds to 1 minute, tops! This is the sort of video you would make using Powtoon, Biteable or Spark. In other words, why should I use ProcessWire or what's unique about ProcessWire? This, IMHO, should be about the top-level /overarching selling points and not about the details. I think we should stick to 3, maximum 4 top selling points about ProcessWire. These can include: Easy-to-use and powerful API OR maybe consistent and powerful API? Security/Secure Custom fields Modularity Free and open source(?) > this maybe can be added as a one liner, even at the end of the video (and it's not really a unique selling point per se) An explainer video does not need to show off the full range of the power of ProcessWire. It just needs to grab the attention of the curious developer, to get a foot in the door, so to speak. Hence, the specific details, e.g. Matrix Fieldtype, procache, formbuilder, Github, etc, are for other (more) videos and are not ideal for 'an intro to ProcessWire' sort of video. In addition, ‘the going through the backend’, IMHO, should not be the focus of this video. These are for a ‘tour of the backend’ sort of video, which an explainer video, due to its length, cannot adequately cover since it will feel rushed and crammed. Ideally, the explainer video should be geared towards our target audience (which seems to be web developers), but this may be difficult to pull off. It’s best to try to fit text into one liners, rather than wrap-around texts, if possible. If the final website is going to change, and this video will show the website, you might want to hold off until then? Finally, I am not saying that it should be an animated video. I think the most important thing is that it should be simple, concise and clear but most of all, really 'sell me' to the idea of ProcessWire. Thanks.

Sometimes it's easier to just look at the core code examples. Admin Data Table is used, for instance, on the templates and fields listings. Other times, just look at the class itself, e.g. here for MarkupAdminDataTable Edit: oops, beaten to it by @gmclelland

Moderator note: @pwFoo, I removed the other original/identical topic

I'd start by reading about $cache. Try the examples at this link that I posted above especially under Cache PageArray objects. You would want the cache refreshed every time a quote page is created/edited. Secondly, do you really need repeaters for your quotes? You could store each quote as a page under one parent. Finally, without knowing a bit more about your template and page structure, it is hard to give more specific advice.

If your site is not highly dynamic, then fetch all your quotes (I am assuming they are less than one hundred) once (or every now and then) and cache the results server-side. If your quotes appear on every page on your site, or most of them, you can get away with caching client-side (e.g. quotes in hidden elements) rather than making regular ajax calls. Otherwise, you'll need to fetch quotes from your cached server-side results (i.e., the quotes cached server-side) using ajax. Have a look at WireCache ($cache) and the links below. https://processwire.com/blog/posts/processwire-core-updates-2.5.28/#wirecache-upgrades

I guess so. How many properties do you need though? The properties of images are well-known. Couldn't you just type them up in an array (name, tags, url, etc)?

You are right; It doesn't work that way. I'm not sure if that is the intended behaviour of explode() if no parameters are passed. It is returning an object; not a normal array. Btw, getValues() returns all the properties. However, this is an array of a Pageimage object. You'll still not be able to access the keys like in a normal array.

You are right. So, we convert it to a WireArray and we can use explode() ? // single image field $singleImage = $page->image; // new WireArray for convenience $wa = new WireArray(); // add our single image to the WireArray $wa->add($singleImage); // you can add all the properties you want here $arr = $wa->explode(array('name','description','url')); // normal array echo '<pre> ONE IMAGE IN WIRE ARRAY '; print_r($arr); echo '</pre>'; // normal JSON echo json_encode($arr); getArray() won't work, as you found out since it is just an array with objects in it.

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