teppo

Moderator note: this thread is being moved to the "General Support" area. The Modules section of the forum is intended for module-specific support boards.

Actually it seems that ProDrafts already supports Repeaters – this was announced in a blog post along with ProcessWire 3.0.75, and that detail just never made it into the description at the store. In case you have any questions regarding ProDrafts, I'd recommend sending a direct PM to @ryan ? VersionControl isn't really suitable for this purpose. Repeater support is one thing (though I seem to recall that the module might kinda-sorta work with Repeaters), but a bigger issue is that there's no draft feature. I could definitely hack it to do something like export a version and import it on another site (definitely something I'll keep in mind, sounds interesting!) but currently that's not doable. I haven't really used ProcessPagesExportImport, but I know that in case of Ryan the "beta" or "development" label doesn't necessarily mean that it isn't usable. I seem to recall that much of the data for the new processwire.com site was migrated using this feature (someone correct me if I'm wrong), and although I've heard some reports of missing features and such, as far as I know it should be pretty solid already. My first choice would definitely be one environment with the ProDrafts module. I'd only consider other options if that one doesn't pan out.

If you don't create any variations on the front-end using size, width, etc. calls, ProcessWire won't create anything except for the variations created by default for admin (preview) purposes. Third party modules may still create their own variations, but if you're strictly against that behaviour, you can always avoid using any modules that do this ? What you're probably missing here is the amount of data: sure, browsers can handle resizing images, but if you're considering load times and amount of data users have to download to use your site, you absolutely want to resize images before they hit the visitors' browsers. When you're asking if this behaviour should be disabled to "reduce additional http requests (if the user resizes viewport)", it kind of sounds like you've implemented srcset on your site – otherwise there shouldn't be a additional requests when the viewport is resized due to images. Even then if you start with a larger viewport and then resize it to smaller size, browser shouldn't load the smaller sizes. Only case generating additional requests is when you go the other way, from small to large – otherwise tiny images would likely look pretty awful scaled to a larger size. Short answer is: no, it shouldn't be disabled. That being said, you don't have to create any additional variations if you don't want to – but be considerate of the user and don't make them download more data than they actually need ?

Moderator note: I'm moving this thread to the "General Support" area of the forum. Modules/Plugins area is intended for dedicated module support threads only.

Moderator note: I'm moving this thread to the "Module/Plugin Development" section. Modules/Plugins section is intended for support threads for existing modules only ?

Hi, Unless I'm misunderstanding something here, what you want is actually a Page field. In your template files you can output the URL of the selected page: <?php if ($page->page_field_name): ?> <a href="<?php echo $page->page_field_name->url; ?>"><?php echo $page->page_field_name->title ?></a> <?php endif; ?> Does that sound about right?

@jmartsch, that's a public discussion on Adrian's profile page. So no, not really direct message -- two different things ?

Thanks! The part in question would be this: "Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons, the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including inter alia as appropriate [...]" GDPR doesn't state that the controller and the processor must encrypt all personal data, period. Loosely translated it says that, taking a lot of things (such as the cost, nature, scope, context, and purpose of data processing) they must take measures appropriate to the risk and its likelihood, and one of the measures that may be appropriate depending on a lot of factors would indeed be encryption. The truth to the matter is that unless there's a court case stating essentially that everything (including specifically email addresses) must be encrypted during storage, this can be interpreted in a multitude of ways. Then again, I'm still not a lawyer, and am mainly relying on opinions on the Internet – so don't take my word for it, and please do take every precaution you feel would be appropriate to your case ?

Sadly the recordings are no longer available. For anyone interested, they will be available at wordpress.tv at some point. On a related note I think that's also a great source of information, even for non-WP users ?

There is actually one benefit: if data is stored encrypted and the key is stored separately, even if it's on the same server, someone gaining illegitimate access to just your database but not full access to the server would mean that said data could be considered much less useful to the offending party. At the very least it could take them a long time to figure out what it is that they actually got their hands on. Although this predates GDPR, in opinion 03/2014 the Article 29 Working Party stated that breach affecting only encrypted data may also mean that the source of the breach isn't subject to typical breach notification procedures: Just something to consider. I'm personally still not convinced that storing emails encrypted makes a whole lot of sense on a typical website, but I'm also not a lawyer, or a specialist in data privacy for that matter. Still, if my business relied largely on storing personal data, I would probably consider taking every precaution in order to avoid a full-blown disaster ?

Just a quick note on this one: to my best understanding GDPR doesn't explicitly require encryption. Encryption is mentioned as a suitable option for data processors and controllers in order to secure user data, but it isn't strictly speaking enforced – and thus not encrypting data (such as email addresses) wouldn't automatically mean that the product can't be GDPR compliant.

Cross-linking this post from Diogo here ?

Moderator note: the Modules/Plugins area of the forum is intended for module-specific support threads only. I'm moving this thread to the General Support area. Please post general support requests or questions to that forum area instead.

This is less of a bug and more of a.. well, issue: the line length in the forum is kind of crazy. I'm getting 220-240 characters on a single line, while 100-120 would be good for readability. Would be great to get this fixed as well. I'm thinking that there probably should be a max width for the content area – or perhaps the font size should be double what it is now? ? The font is also really tiny and way too light (at least in some places, such as the breadcrumbs and other "less important" texts), neither of which really helps with the readability issue. Anyway, great job getting the update rolled out, and the forum looking more like the main site! Edit: I'm officially getting old. Setting browser zoom level to 125% or 150% makes things way more comfortable ?

Don't shoot the messenger – I know this is from WordCamp, not ProcessCamp, but there's plenty of quality material there not strictly tied to WordPress ? https://wpwoofi.com/wordcamp-nordic-paneelit-2019/ Sadly the recording misses the beginning of the UX for everyone talk by Piccia Neri. This was my absolute favourite in the whole event, there were so many good points there. She has the ability to explain scary-sounding concepts and processes in a way that makes them really easy to grasp, and actually makes them seem attainable even in relatively low-budget projects ? "Lessons from WordPress core on how to (not) write code" has some good pointers for anyone designing dev tools, "Cache is keeping you from reaching your full potential as a developer" contains valid arguments, and although "Continuous integration and deployment with WordPress" is definitely WP-specific, the basic principles can be easily applied to other platforms as well. Just to mention a few. Anyhow, I hope someone finds these interesting ?

No worries – no hard feelings here either! It's just that folks sometimes miss the point that having a module that does x for ProcessWire doesn't mean that ProcessWire itself, as in the core package, needs to do that. In this thread alone we've had some posts where this point has been lost. What third parties (such as me) build on top of ProcessWire does not have a direct impact on the core. I get that this is a topic that can bring some emotions to the surface, so trust me: I for one would not like to see ProcessWire go the "page builder route". At the same time I see a lot of value in having a block editor style Fieldtype – or something similar – as a module that one can plug in if and when that sort of feature makes sense ?

This. Please read this before you post. Not a single person here has, to my best understanding, suggested that there should be a page builder in the core. This very topic is in the Modules/Plugins development area of the forum. This topic is not about the ProcessWire core. Thank you ?

Thanks! Didn't know of GrapesJS, looks interesting ? That being said, my first impressions are somewhat mixed: the default theme is pretty bad in terms of accessibility, UI felt kind of confusing (possibly because there are a million options there), and overall it could use a major facelift. On the other hand it seems fast, apparently there are quite a few features available as plugins, and it does seem to be actively maintained as well. Overall I'm getting a strong "for power users" vibe from GrapesJS, and so far it doesn't seem like something that I'd be happy to introduce to non-technical clients who "just want to add some blocks". In other words: in my (possibly subjective) opinion Gutenberg still seems more viable than GrapesJS.

Hey @pout, Just wanted to mention that the Modules/Plugins forum area is intended for module-specific support threads only. So unless you're releasing a new module, you should not post a new thread here. For general support requests I'd recommend the General Support area instead. Thanks! ? (I'm moving this thread to General Support.)

Without going into too much detail regarding the previous discussion here, I've just heard of https://gutenbergcloud.org/ for the first time, and I've got to say that it seems promising. The basic idea is to provide a common service for installing all sorts of blocks – and only the blocks you actually need. (Currently the situation is roughly that some blocks are shipped as one-block plugins, while others ship as massive collections of blocks, neither of which are really optimal.) Also took a quick dive into Gutenberg for Drupal (which Gutenberg Cloud promotes), and they've done a smashing job there ? I'm definitely interested in looking into setting up a Gutenberg Fieldtype, or perhaps a Process module – or something similar. Though once again my desk is kind of full, so who knows. -- Although I did say that I wouldn't go into the earlier discussion, just a quick comment on that: As a tool Gutenberg has it's flaws, and it's definitely not a tool that would/could/should somehow replace what ProcessWire does. I don't think that anyone has been suggesting that here either. Gutenberg is a block builder, and admittedly one still in a relatively early state – but even at this stage it looks promising. There really aren't any serious contenders, particularly fully free and open source. Right now there's also a lot of momentum behind the project – not to mention financial backing from Automattic – which means that as a tool it will undoubtedly improve over time, and current issues will eventually get ironed out. Whether going with Gutenberg is a good thing for WordPress or not is a debate I don't want to get into. Personally I don't know anyone seriously developing sites with WordPress and not using either one of the existing block / page builder solutions, or some sort of ACF based approach. WordPress alone is not the point – the plugins are. Since block editors are probably the most popular way of building WordPress sites, in my opinion having one built into the core is a logical next step. But that's just my opinion. And again, it has little to do with ProcessWire ?

Cross-linking this here, ping @ryan:

Please note that the Modules/Plugins area of the forum is intended for module-specific support threads only. General questions and module requests should go to other areas instead. I'm moving this thread to the "Getting Started" area.

That error is a generic PHP error message, so making sense of it requires some basic PHP debugging skills. There's no manual here – just read the message, see what it is related to, and try to figure it out from there. Google is your best friend when debugging PHP code ? The message here is rather clear: In other words you're trying to call function and() on a null value in your _main.php file, line 49. The exact reason is impossible to say without seeing the code, but my guess so far would be that you're grabbing a page or something like that, and not actually checking that it has a valid value before trying to use it as an object.

Your hook method isn't doing any caching, so every time it's executed, it makes a request to the API. In your head.inc file above you're checking if shopifyShopCurrency is already stored in session – but if it isn't, you're making two separate requests to the API: if ($page->ipapiGetUserLocation()['currency']['code'] && $page->ipapiGetUserLocation()['currency']['code'] !== 'GBP') { So, it seems to me that simply by grabbing $page->ipapiGetUserLocation() to a variable and using that for those checks you could probably cut your requests for new users to half. } elseif (!$session->get("shopifyShopCurrency")) { // Set it as the Shopify store default Just for the record, this row is kind of odd, since there's no chance that $session->get("shopifyShopCurrency") would be set by now. Although it should work, it's unnecessarily verbose and does kind of a pointless request to $session – a simple "} else {" would've been enough. It's probably unrelated, but it's also a bit strange that you're querying the currency code based on user location, but you're never actually using it. I'm assuming that this is by design, but it's still kind of curious ?

Apparently "instanceof" doesn't allow constants, strings, or expressions, while is_a() happily accepts all of those. This is news to me, and I'm not entirely sure of the behind the scenes logic, but it probably has something to do with instanceof being a language construct (those sometimes behave a little bit unexpectedly) – or it might simply be a performance optimization. After all instanceof is much better in terms of performance than is_a(). Use variables or literal class names instead – or if you really have to, use the workaround provided by @tpr above, i.e. store the constant value to a variable before use ?