teppo

Moderator note: Modules/Plugins section of the support forum is reserved for dedicated third party module support threads. For the time being I'm moving this thread to the General Support area of the forum. Note that Padloper also has a separate support area on the forum, accessible for existing users with a valid license; you should post Padloper questions to said support area to make sure that they get noticed by the module author(s). As for your question: the Padloper website mentions PayPal and Stripe payment modules. If there are other payment methods, at least they are not listed on the site. As for shipping methods, there's not much information out there — I'd definitely recommend posting this question to the Padloper support forum. If you have a valid license but don't have access to said support forum, please contact the module author.

Users are not typical pages, so you should use wire()->users->find() instead. Or, alternatively, you can use wire()->pages->find('template=user, id=..., check_access=0').

There are a few problems with that code: Switching $magazine to $page doesn't actually help at all. $page is not defined here either. As I mentioned in my previous post, you're in function context, and in that context you only have access to a) function arguments ($event), b) variables you've made accessible with "use" (currently there are none), and c) global functions. $page is none of those. Another issue is that there's no savedPageOrField method for Inputfield, so Inputfield(...)::savedPageOrField is never triggered — what you're looking for is Pages::savedPageOrField. From your post I assume that you've put this code in the template file, i.e. /site/templates/your_template_name.php? If so, the hook only applies to when you're viewing a page using that template, i.e. it has no effect in Admin. I'm not sure if that's what you really intended, but I'd assume not — more likely you'd want to put this hook somewhere it gets added in the admin as well, so perhaps /site/init.php or /site/ready.php. ... and, finally, even if your code did work, you would've likely ran into an infinite loop: if you hook into page save and save the page, that'll trigger the page save hook, which will then save the page and trigger the page save hook again, which... you know the drill. Pages::saveReady() is often better method to hook, as you can just modify the page values, and they'll get saved soon after (you don't have to call save in your hook) ? In this case something along these lines could work: // hook into Pages::saveReady $wire->addHookafter('Pages::saveReady', function($event) { // get current Page object — in this case this is the first argument for the $event object $page = $event->arguments[0]; // bail out early if current Page *doesn't* have the field we're interested in if (!$page->template->hasField('snipcart_item_image')) return; // ... and also bail out early if the snipcart_item_image field hasn't changed if (!$page->isChanged('snipcart_item_image')) return; // now that we know that snipcart_item_image has changed, set a custom value to another field $page->set('imagecolorat', 'YOUR_NEW_VALUE_HERE'); // finally, populate our modified $page object back to the event $event->arguments(0, $page); }); Note: written in browser and not properly tested.

I know you mentioned docs being confusing, but I'd still suggest taking another look at them — specifically this part, as it explains this pretty clearly: https://processwire.com/docs/modules/hooks/#defining-hooks. To simplify things a bit... the key difference between the first two is that $wire->addHookAfter() works outside classes, while $this->addHookAfter() is how you'd usually attach the hook when you're in a method of a class (i.e. while you're working on a module of your own). $page->addHookAfter() attaches the hook to the current Page object (which $page typically refers to), not all Page objects in general. Important distinction in case you're working with multiple pages and don't want your hook to run for all of them. Not sure if that explains it any better than the docs, but again the biggest difference is just the context in which you're defining the hook (use $wire when in template files, /site/init.php, /site/ready.php, /site/admin.php, etc. and $this when you're within a method in a class) and whether you want your hook to apply to a single object ($page, $pages, or a specific item such as $mypage where $mypage = $pages->get('some_selector')) or all items of a specific type. Most commonly you'll need your own hookable methods when you're, say, developing a reusable module. Instead of tweaking the module on a per-site basis, you'll likely want to keep it as-is and rather make some minor modifications by hooking into it's methods. This way you can easily update the module without having to redo or work around your modifications every single time. On some edge cases you might have a utility function on the site, and then depending on some other event you may want to say that "at this specific instance the method should do something else", so you'd want to make it hookable. Can't think of many cases where that'd make sense, though. I'm not sure what you're getting at here. Is this is just an example of what you're doing at the moment? Either way your hook looks fine to me. Should've read this more carefully. You're accessing $magazine object here, but if this is your entire code, that won't work — you're not defining $magazine variable anywhere. Since you're in function scope, you only have access to the arguments passed to that function, variables you've passed in with "use" language construct, and global functions. Even if $magazine exists outside your function, you'd have to pass it in with function($event) use ($magazine) { ... } That being said, what you're probably looking for is something like Pages::savedPageOrField(). If you take a look at that docs page, there are code examples dealing with changes etc. Or, alternatively, Pages::savePageOrFieldReady(), which occurs right before the page/field is saved (which means that you can modify the values right before they are saved to the database). ... and please let me know if I missed your point here ?

Definitely this one. Unless the translator has very specific requirements (i.e. they intend to import the file into some sort of app), CSV export/import is by far the most effortless approach for all parties involved ? Edit: purely out of curiosity tried to run a conversion from ProcessWire's JSON format to other formats (such as PO, the format typically used by WP translation plugins — .wordpress is a new one for me, so not sure if they meant this, or if that's just something I haven't come across yet) using https://localise.biz/free/converter, and it seemed to work fine. Though would need to test properly to make sure that the process is also easy to reverse, and the result can be imported properly. Conversion done this way would be a bit of a pain, though, since you'd have to convert each file one by one. Unless you happen to have most of your translations in a single file or something like that. Seems like there are decent libraries for this available as well, so a conversion tool would be relatively simple to set up, but again for a one-off case that'd be a lot of extra work ?

It seems that whatever route you take, the memory / performance optimization approach would eventually run off the cliff. I mean... it's just not scalable. So, trying to think outside the box for a moment: When you say that "Snipcart returns to your page", what does that mean specifically? Does it perform a GET/POST request against the page? If so, is there any chance that it would provide enough information for you with that request to actually generate a smaller subset of prices used in that specific order? This would technically shift the responsibility for the validation step from Snipcart to your site, but it also seems like something that could scale much better ? Anyway, just throwing in ideas.

Sorry, this is not my area of expertise either. Used to deal with that a lot, but thankfully no longer — switching all email sending features to use services like Mailgun has made my life so much better ? Anyway, your solution seems reasonable. Only thing I'm wondering is whether it'd be better to specifically check for ASCII encoding with mb_detect_encoding(), instead of "not UTF-8"? It's a really small nuance, though.

Stabbing in the dark: perhaps your htaccess is not working quite as expected, or you're missing some module(s) from PHP? Although if your entire front-end works as expected, this seems a little weird. Admin and front-end both go through the same index.php file after all. Either way it's very likely a PHP / server configuration issue. If that's the case, a quick search on Google for something like "php files show up as text" will give you a ton of stuff to try ?

I'm really starting to think that camel case / pascal case should be avoided... well, just about everywhere ? Recently ran into a similar issue where a piece of code worked flawlessly on my machine, yet on the live server it spat out nonsensical errors. Turns out my local (Mac) env is case insensitive (which also applies to the virtual machine I use to run Linux on it) while the server is case sensitive. Spent half an hour or so debugging the issue and tearing things apart just to find a tiny typo in the filename. So frustrating! ?

This is a bit of a border case on this forum, I know — but it's also such a great event that I wanted to share it anyway: https://wpaccessibilityday.org/. In short this is a currently ongoing 24 hour streaming video / webinar event with loads and loads of accessibility focused talks. I'm writing this right after the first talk, so you haven't missed much if you jump in now (and again, it's a 24 hour event, so there's a lot more to come). Direct link to the stream: https://www.youtube.com/watch?v=X0BcKR2Go1E. Some of the talks are obviously pretty WP centric, but based on the schedule I'd say that the majority of the content should apply to just about all regular websites, as well as content management platforms in general ?

Hey folks! Just wanted to mention that ProcessRedirects 2.0.0 is now out. As far as I can tell it should fix most of the issues that have been reported here, as well as those reported via GitHub. This is a major update and the module now requires ProcessWire 3.0.112+ and PHP 7.1+, so please keep that in mind if and when updating ? Here's a kind-of-a-changelog for this release from the PR that got merged earlier today: In case anyone is wondering why update this module now even though we already have a very powerful alternative (Jumplinks), the thing is that this module still serves a purpose: it's super easy to use, and does what it needs to do — no more, no less. Powerful features can be a double-edged sword, as they also tend to increase complexity, at least to some extent. When it comes to "power users", Jumplinks is by far a superior tool, but for regular content editors who just need the occasional shortlink (or something similar), this module is often just the right fit. Hope that makes sense. Anyway, I still have some relatively minor additions in mind that I'd like to add to the module (assuming that Antti thinks they are a good fit), but again, for the most part this module already does what it needs to. Power users will likely feel more at home with Jumplinks ? If you find a bug or have a feature in mind that this module really needs to have, feel free to open an issue at the GitHub repository. Thanks!

/site/config.php is not cached. Your site content may be, though, if you're using ProCache or something similar. (Technically something else on the server could cache PHP files, but if a restart does nothing then this seems unlikely to be the issue here.) I'd first check that this file is indeed the correct one: add something like a die() statement there, and if the site still runs as usual, either it's loaded from some sort of cache, or you're editing the wrong file. Do other changes to e.g. template files have an effect on the site? And you are editing site/config.php, not wire/config.php? Edit: If this is a dev environment, make sure that you don't have separate config-dev.php as well. Anyway, just throwing in wild guesses here ?

Hey @cosmicsafari — not a bad question at all. The description field comes from a module config setting. By default the module is set up to look for field called "summary", but you can change this to something else: $config->SearchEngine = [ 'render_args' => [ 'result_summary_field' => 'summary', ], ]; My guess is that your pages don't have the summary field? You can use some other field instead (if there's a suitable field), or you could let the module auto-generate the description by setting the summary field as "_auto_desc"... though please note that the support for auto-generated descriptions is experimental, and comes with one major gotcha: SearchEngine doesn't know which parts of your search index are "public knowledge", so it may end up displaying anything stored there. If you end up using this option, be sure to test it and make sure that you haven't indexed anything you don't want to show up in the search results ?

Depending on your needs https://modules.processwire.com/modules/process-email-to-page/ may be worth looking into. I'm not particularly familiar with this module, mind you, so don't ask me how (or if) it works ?

Hey @Mike Rockett, and sorry to bother you with this again, but just wanted to run something by you. I've tried the solution above, but at least in my case it doesn't seem to be quite that simple. For some background, in this case the source path is "tilaukset" (orders in Finnish), and it should always link to a specific target URL. This works fine as-is, but when it's shared on Facebook, following the link from there results in 404 due to added query string. Going step by step: If I append [/] to the end, it works with or without slash at the end — so far so good. If I also append {all} or {!all}, the redirect only seems to work if there's content there, i.e. plain "tilaukset" or "tilaukset/" no longer work. I'm not sure if this is intentional or not, but I guess the question is if there's a way to specify that "I don't care what comes after this, it could contain nothing or it could contain content, either way ignore it"? ? I'm using <tilaukset|tilaukset?{all}> for now, but that seems pretty complicated when what I really want is (in terms of regex) "tilaukset.*" (or alternatively "tilaukset/?.*"). This also keeps the query string intact; I'd prefer it to be dropped, but that's not by any means a major issue. Am I missing something?

Glad you got it sorted! ProcessWire modules are written in PHP, and PHP code always requires the "<?php" start tag -- otherwise it's interpreted as plain text. In case you're embedding PHP within HTML you'll also need the closing tag "?>" (<h1><?php echo $page->title ?></h1>), but if the entire file is in PHP (as module files usually are) it's best to leave that one out.

Just checking, but you didn't forget to add <?php at the top of your module file, did you? ? Note: I've moved this topic to the "Module/Plugin Development" forum area. The "Modules/Plugins" area is only intended for support threads of finished modules.

First of all, what you're saying here seems a bit off: you mentioned using selector field, but judging from the value it looks like you might actually be using a Page reference field — is that correct, or is the field type really Selector? Anyway, if it is a Page reference field, then $pages->get() is obsolete here: the stored value is already a Page. What you're doing here is taking that selected page, reading the value of the "title" field from it, and then asking ProcessWire to give you that same page again with $pages->get(), even though $sp->parent = $sp->some_field is all you really need to do. And even if you do have to get the parent with $pages-get(), you shouldn't match "title" to "name"; either match "name" to "name", or better yet use "id" (which is always unique across the system) ? Also note that whenever you use $pages->get(), it will return any matching Page, including those that have been unpublished or trashed. In most cases you should use $pages->findOne() instead, or alternatively add some checks to confirm that this is indeed a valid (and non-trashed) page. -- As for the error you're seeing, I think the biggest issue is that you're not sanitizing the selector value. Whenever you use a "dirty" value (including values stored in ProcessWire fields) in selectors, you should make sure it's valid. $sanitizer->selectorValue($new_parent) is the "generic" way to do this, but in this case you're using the value as a page name, so you should rather use $sanitizer->pageName($new_parent). Note that if at this point $new_parent contains encoded entities, this could mean that you're using this code snippet in a context where output formatting is enabled. You can always get the "raw", unformatted value from a field with $page->getUnformatted(): $new_parent = $sp->some_field->getUnformatted('title'). -- Finally, depending on the use case you should know that this script could result in some errors or notices since you're not checking if $sp->some_field contains a value before you try to use it as an object. It's possible that you intentionally omitted some parts when posting the code snippet here, but if not, then you might want to add something like "if (!$sp->some_field) continue;" to the beginning of your foreach loop to skip empty values. -- So, long story short: it's possible that the whole $pages->get() operation is unnecessary — but if that's not the case, then the issue is likely related to missing sanitization (and possibly output formatting) ?

Hey @Sevarf2. Which version of Template Engine Factory is this? If it's 2.x, do you have auto_page_render setting enabled via module config? I'm not particularly well versed in the inner workings of said module, but my initial assumption would be that it's related to the way it chooses which pages to render. It may also have something to do with hook priority, etc. Anyway, let me know which version you're using, and I'll see if I can set up a quick test case.

Hey @Eduard, Thanks for working on this! It would be great if you could also submit this to the modules directory (https://modules.processwire.com/add/). There's currently one existing Russian translation, but it was last updated 8 years ago, so your version should probably replace that one... ?

Just gave this a quick try, and so far everything seems to work for me. Copied HelloWorldPanel to /site/modules/Wireframe/TracyPanels/Wireframe.php, renamed the class to WireframePanel, and changed labels. So far so good — it's not doing anything sensible yet, but seems to load just fine. Will report back once I've had time to actually make the panel useful... ?

I guess it depends on your point of view. I can see how "always compare old to new" might make sense, but personally I prefer current approach, which is basically just "selected revision compared to any other revision". At least for now I think that current approach is straightforward and makes sense (without requiring additional UI tricks, such as the one used by Wikipedia) ?‍♂️?

Hey @Manon! This seems like a good idea, so I've gone ahead and implemented it in Version Control 2.x (available via the dev branch int the GitHub repository). Note that if you're using Version Control 1.x, this update is not available there — I'm planning to merge the dev branch into master soon (this year at least), making 2.x the default version, and as such I'm not going to make any additional feature updates for 1.x releases.

Just a quick heads-up that Wireframe 0.17.0 went live a few hours ago. Versions 0.15.0 .. 0.17.0 mostly included behind-the-scenes improvements and refactoring for existing features, so didn't think these were particularly interesting. Full changelog can be found from CHANGELOG, as usual. Probably the one and only feature that might come in handy during development is the shortcut method for defining view template and view at the same time (to use a view from a specific template instead of current one), added in 0.16.0: <?php // find blog posts and render them using the "list_item" view of the "article" template: ?> <ul> <?php foreach ($pages->find('template=blog-post') as $post): ?> <?= $post->setView('article/list_item')->render() ?> <?php endforeach; ?> </ul> On a loosely related note I've removed the "WIP" label from the topic of this thread, and am considering submitting the module to the modules directory. I think it's long overdue, really ?

Hey @Jessie! I'm not familiar with this particular error, but the first thing I'd try would be to upload the wire directory again. FTP connections are somewhat prone to errors, it seems, and a missing or corrupted file could possibly explain this. If that doesn't help: Which version of ProcessWire are you using? What's the PHP version on your server? Also: I'm assuming this is a vanilla ProcessWire setup, and you don't have any third party modules installed? At least int he past the CropImage field has had similar issues, so if this isn't the built-in Image field we're dealing with, that'd be good to know. Sorry for not being able to provide a clear answer; hopefully we can figure this out without too much hassle ? As a general rule of thumb: never change anything within this directory. Wire is not meant to be edited.