teppo

@thlinna, could you specify what kind of issues you were experiencing? I've just installed this on a PW 3.0.118 site, and so far no luck: the module installs as expected, fields show up in user editor, and a user with login_disabled checked cannot log in or use the admin. The module wasn't exactly verbose about what it was doing during install/uninstall, so I'll push a new version that lists fields and template(s) affected during both install and uninstall. Other than that this version doesn't really change anything, since I'm not seeing any issues here yet ?

Hey @adrian and @zoeck, Sorry for not responding to this – I've been kind of tied elsewhere, and totally forgot this question. Bad excuse for bad communication, I know ? I'll have to dig into this. I didn't intentionally strip any features from 2.0, but it's entirely possible that something in Admin Theme Uikit (assuming that you're using that) or the updates I did for 2.0 did indeed disable Repeater Matrix support. I had to put the development of this module on hold since there were some difficult (or at least time-consuming) UI issues to tackle, and I just didn't have the bandwidth for that. I'll do my best to try to find some time soon(ish). Sorry, but can't really promise any kind of timeframe right now.

Hey @thlinna, thanks for the report. I'll schedule some maintenance time to later today ?

Note: this topic was moved to the "Module/Plugin Development" subforum. "Modules/Plugins" area is intended for support threads of existing modules, and any module development related questions or discussions belong here ?

Note: I've just moved this topic to the "General Support" section of the forum. Since this is a core module thing, it doesn't really belong to the Modules support area ?

Hey @LAPS! Sorry, I can't really help you with your issue, but wanted to mention that I've merged your question into the Pages2PDF support thread. Module-related questions should be posted to appropriate support threads whenever possible. This keeps things nice and clean on the forum side, and it's also the best way to get answers ?

Another "me too" from here. In fact when @apeisa first introduced me to ProcessWire, I wasn't that enthusiastic about it (some things about templates and fields just didn't seem to make sense), but having Ryan walk you through all that was a real game changer. We could use an updated video, though ?

Got to agree: there are a number of ways to get past this, but I'd argue that it's less about the syntax itself, and more about the way you structure your templates. In my case (and yes, this is a shameless plug) I'm using pw-mvc so that I can move anything I see as "code" to a separate controller file, and only include simplest loops and output statements on the view side. Sure, this project doesn't force any such restraints, but as a general rule of thumb I try to make my views as "dumb" as possible: as long as they have absolutely no idea how variables they output are generated, they a) remain clean and b) I can easily modify just the view, or just the controller. One way to handle structures that need a bit of pre-processing is to loop through $projects twice: once in the controller, where you store just the required fields (formatted to your liking) in an array, which you then pass to the view, where you iterate over it second time. Two loops is not optimal in terms of performance, but typically the performance hit is questionable at best, and this approach can make your view files much cleaner. Another approach I like to implement are separate render-functions: renderThumb(), renderNewsBlock(), renderHighlight(), etc. Depending on the project I often include a common functions.php file with these functions somewhere before markup is generated, and then abstract any complex, repeatable stuff there. Sure, that way you're kind of mixing HTML with code as well (in functions.php), but your views remain nice and clean ?

If you pasted that code here as-is, the issue seems to be that there's an extra space after self::new – it should be "self::new($items)" and not "self::new ($items)". A FileCompiler issue, perhaps? Could also try manually replacing /wire/core/WireArray.php with the one found from GitHub, just in case. Ping @ryan ?

I know you already rest your case, but still wanted to point out that Uikit is actually very configurable, meaning that you can pick and choose the components you need. You don't have to include the full framework, and when using SASS or LESS you can easily recompile the framework at any time. There's also another thing that in my opinion makes it a great fit for ProcessWire: Uikit also includes the concept of hooks. You quite literally modify it the same way as you'd modify ProcessWire. The point behind front-end frameworks is that you don't have to reinvent the wheel every single time. In most cases our grids, carousels, cards, and whatnot are not really that different from project to project. Sure, they are styled differently, and may even behave differently, but the basic structure and function is similar. So, why write a new component every single time when you can reuse the old structure/behaviour and just give it a brand new bespoke look and feel? What you're essentially claiming is that every Uikit site looks the same (or requires a lot of hacks to not), yet I disagree. Again if you take an out-of-the-box version of Uikit and use the ready-made default theme (you did notice that using it is completely optional, right?) then yes, it's going to look like... well, an out-of-the-box Uikit with a ready-made theme. Just don't do that, and you'll be fine. Yes, with a framework there will always be some amount of configuration and hooking/overwriting involved, but that's a small price for the benefits you reap. For arguments sake: if we thought that all pre-made components were pure evil, we shouldn't be using ProcessWire either. ProcessWire doesn't dictate your sites look and feel, but it sets a baseline for how it'll work behind the scenes. Uikit does the same for the front-end. Both are easily configurable and modifiable. One might even go as far as say that they are natural allies – two parts of a whole. For the record, before writing this post I was not fully convinced of Uikit: I've been using Foundation, which in my opinion is superior in many ways, and has a rather different method of modification – essentially a massive config file for modifying pretty much every single thing you can imagine. But diving into the Uikit docs made me like it a lot more, and not least so because it really does have certain similarities with ProcessWire itself. In short: Uikit is a great choice for the new processwire.com.

You don't necessarily have to change that approach with ProcessWire ? I've done a few projects with a similar setup, and the easiest method (in my opinion) is to use either sessions (if you're happy to involve PHP in this) or cookies (for a JavaScript only solution) to keep track of the products that were added to cart: When "Add to cart" (or whatever you call it) button is clicked, use JavaScript to add product info to cookie or submit an AJAX request to a PHP based processor in which you sanitise and store product details in PHP session. Note: if you use a PHP processor, you might want to consider making that button a form submit with product ID / details as a hidden text field. This way even if the user doesn't have JavaScript available/enabled, you'll still be able to process the request. When the user reaches the order form, autofill a hidden field (textarea) with contents of the cart. I've handled this part with FormBuilder forms, but obviously you can use a custom form as well. As long as you're essentially just sending a list of selected product names, sanitising data is a simple task, and even if someone does figure out the "hidden form field" trick and goes on to modify the data manually, there's no real harm in that. Or you can just leave that field visible , if it's fine that the client adds more details before sending the enquiry – or perhaps even replace it with a neater UI. Hope this helps a bit.

This is an old thread, but just wanted to point out at least one major benefit of Slack: it is extremely popular among web devs. IRC is obviously popular as well, but – and this is just my opinion, so take it with a grain of salt – mostly among folks who've been using it for a long time, and of course those who've got a problem with using proprietary platforms in general. In my experience new users tend to very much prefer the slick interface and easy setup of Slack, and since a lot of us are already using Slack for in-company stuff, client communication, and even for other (open source) projects, it'd be easier if ProcessWire had an official Slack workplace as well. In some ways it's the same question as for why use GitHub even when there are decent (and even more powerful) free/open alternatives: because it makes ProcessWire easier to approach for new users. Because that's where the users are, and that's how they find us. At least that's how I see it ? (Note: I've been an IRC user since the 90's, although not so much during recent years, so in my case it's not that I can't use IRC. It's just that all my other dev-related discussions currently happen in Slack, and I'm not too keen on getting back to IRC. I guess I've grown accustomed to what Slack is and how it works, and I see a host of benefits in it.)

Hey Thomas, Thanks for this module, looks really interesting, and I'm looking forward to giving it a go. Just a quick comment on this part of the README: I think that a configurable endpoint name would definitely be a worthwhile option – or if that turns out to be difficult, perhaps you might want to consider something slightly more descriptive, such as /rest-api/ or something? To be completely honest I'm being a bit selfish here: I've got the bad habit of using /api/ for any site-specific API implementations I might need, and that would pose an issue for this particular module ? Reminds me of the "two hard things in computer science" thing. This thread already covers both: cache (well, token...) invalidation and naming things ?

Great read! A bit off topic (hey, this is the pub) but this is part of the reason why I love reading about old-school software development, and game development in particular. You know, when folks had to figure out how to run complex software while dealing with various limitations – such as being limited to something between 32 and 64 KB of memory in total. Good times. For the record, there are some awesome videos about old school development and hardware at YouTube by user The 8-Bit Guy. Not only does he clearly know his "old-school" computers inside out, he has also released amazingly polished new games for old hardware ?

From a core development perspective I'm going to agree with this – but while the core probably shouldn't include a pre-built, "full featured" page builder (at least for the time being, since no one really knows what the future holds), there's no reason why third parties should be discouraged to create such tools. I also know for a fact that there'd be a market for that ?

Hey @pwired The point is that when you do this ... <ul> <?php foreach ($pages->find("template=news-item, limit=5, sort=created") as $item): ?> <li><a href="<?= $item->url ?>"><?= $item->title ?></a></li> <?php endforeach; ?> </ul> ... it looks a bit cleaner (as in "less like code mixed with markup") than doing something like this: <ul> <?php foreach ($pages->find("template=news-item, limit=5, sort=created") as $item) { echo "<li><a href='" . $item->url . "'>" . $item->title . "</a></li>"; } ?> </ul> ... or this: <ul> <?php foreach ($pages->find("template=news-item, limit=5, sort=created") as $item) { ?> <li><a href="<?php echo $item->url; ?>"><?php echo $item->title; ?></a></li> <?php } ?> </ul> I wouldn't say that there's anything wrong with using selectors within template files, although personally I try to avoid even that when possible. What we're discussing here is simply the syntax used in template files: if you use "full-blown", especially multiline <?php ... ?> code blocks it can seem like you're mixing view side (markup) with business logic (code) even if you're not. On the other hand (probably not what you meant, but just to clarify) if you're wondering why business logic and markup should be separated in the first place, there are a number of reasons to do that. In my case the biggest benefits are a) the ability to alter data structure (model), business logic, or representation (markup) without touching other parts of the site or app, and b) the ability to switch entire view – or use multiple views simultaneously – without having to duplicate any actual "code". (There's a sh*tload of stuff about this in the web, so I won't go into too much detail here. Just google "separation of concerns".) --- Slightly off-topic, but regarding selector use within markup, and why I personally prefer to avoid that: this is in part because in my opinion it looks cleaner, but also because this way I can tweak template names, data structures, etc. without having to modify my views at all. This in turn becomes more useful when you have multiple views for the same data. So, once again, "depends on the use case" ?

@pwired, it's just about separation of concerns (code and markup), and honestly it's also largely about looks: if there are multiline PHP code blocks within your template files, it appears that you're mixing code with markup, which is generally discouraged. In contrast, by using only the short syntax of certain statements (such as <?php foreach (): ?> .. <?php endforeach; ?>) or short echo statements (<?= $variable ?>) you're making it as obvious as possible that you're using PHP as a templating language and indeed not entangling business logic with markup.

You're talking about short echo tags (<?= ... ?>) right? In that regard I agree: that's a good solution in template use. Short open tags (<? ... ?>) are a different thing entirely, and although earlier decision to remove them was apparently cancelled, they're still discouraged and disabled by default.

Just a quick heads-up: I'm moving this thread to the "Module/Plugin Development" subforum. The main Modules/Plugins area is intended for support threads of existing modules, while questions regarding module development belong to said subarea ?

Since this is a feature / change request involving a core module I'm moving this thread to the "Wishlist & Roadmap" forum section.

Agreed. In template files I personally prefer <?php foreach (): ?> ... <?php endforeach; ?> (and similar syntax for if...endif etc.) and for output the short echo syntax (<?= $some_var ?>) makes sense, but I'd also advice against using short opening tags (<? ... ?>). Although it remains a part of PHP syntax, there's no guarantee that it's always going to be enabled, and it's commonly frowned upon by PHP devs ?

@thetuningspoon, it would be helpful if you could provide a limited test case (i.e. a minimal setup where this performance problem occurs), or if that's not possible/feasible, a description of the structure and this particular feature in as much detail as possible. For an example: What's the page structure like, and which part of it is cloned? Are users actual users or do you have "user" pages in a custom page structure – and if, do each of these have multiple orders? Or are you linking users to orders via a Page field or something along those lines? How many fields do your orders (if order pages is what you are cloning) have? How many Repeater fields there are, and approximately how many Repeater items (real content or ready items) do they contain? How many users/orders are you dealing with? Where in your page structure are you storing cloned orders? Are there any third party modules (or modules/hooks you've created) that could affect this? As you can see, this raises quite a few questions, and that's just the tip of the iceberg I'm afraid. All in all this sounds like something that would be easiest to debug by setting up a test case – otherwise it's difficult to isolate the issue. As @LostKobrakai already pointed out, 20 seconds for cloning a relatively small page structure is not normal, unless there's a massive amount of data to copy (in db or on disk). If you're dealing with a large number of items, Repeaters could of course also play a role in this: after all each repeater item is a Page, and their storage method can also result in bottlenecks at large enough scale ?

Happy to do this, so thanks for the heads-up. Personally I've avoided commenting on existing issues unless I've actually got something valuable to add, mostly out of fear that a pile of "me too" comments would just make it harder to keep track of for Ryan or anyone else following the discussion. This is why the thumbs-up emoji seemed like a good alternative ?

Absolutely. The best approach depends entirely on the needs of a specific project and client ? For an example, while (re)building a large news site some time ago we first considered going with a page builder, but in the end implemented a single RTE field for the main copy of each article, with some minor layout customisations. The thing is that their old system was based on blocks, and one particular pain point with that was that since the authoring process itself relies on producing the whole text as a single document, it had to be manually split for the site. It's also true that new tools tend to require some getting used to. That first review is a good example of this: when you've had 15 years to get used to doing things in a specific way, migrating to a new set of tools can feel rather awkward. I'm not saying that Gutenberg is the "perfect" page editor, but it's not necessarily quite as bad as that text makes it seem: "Oh …. need an image in the middle of a text block … grunt. Create new text block, copy paste the first part of the text into the new text block, insert the image block." Actually you can just move the cursor to where you want the image, hit enter to create a new empty block, and then insert an image. Or you can insert the image right into the paragraph block if you want it inline with the text. "Oh … I needed the image one sentence further down. Old way – cut image paste where I want. " In this case you have a couple of options: click the arrows next to the image block to move it up or down, drag it where you want it, or copy and paste it to the right position. Admittedly the work in progress state of Gutenberg shows here: while "copy" already works, "cut" doesn't, so there's an extra step of deleting the old image. It is still a beta version, so I'd cut them some slack ? In my opinion a true professional is able to choose the best tool for the job, thus avoiding a cognitive bias commonly known as "the law of the instrument" (or "the law of the hammer"). If I run into a project where the client clearly needs a page builder, then that's what I'll use. The great thing about working with a system like ProcessWire is that we have so many options: one can implement a page builder together with a set of template specific predefined custom fields and all the benefits that come from being able to precisely define content hierarchies and URL structures. In other words it's all about having options – and of course having an open mind when it comes to exploring potential new solutions ?

By the way, since we're talking about page builders, I assume that everyone here is already familiar with Gutenberg? If not, in a nutshell it's a flexible and extendable (new custom blocks can be registered by third party plugins) page builder developed by core devs as an official alternative (and perhaps at some point in the future as a full replacement) for the current WP editor interface (which is essentially a customized TinyMCE field). Gutenberg has caused a bit of turmoil among the WP folks, with some considering it the best thing that has happened to WP and others wishing that it would just go away. Personally I think that it's a brilliant move from the core devs, and fits the WP ecosystem like a glove – not to mention that it has already spawned an entirely new category of third party plugins (Advanced Gutenberg Blocks, Stackable, Atomic Blocks, and so on). In other words it seems that the WP core devs are taking the page builder approach very seriously, while other approaches – such as custom fields and content types – remain in the realm of third party plugins.