teppo

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.

Hey @adrian! Just wondering: what's your take on extending current panel collection with custom tools on a case-by-case basis? Sorry if this has been discussed already, there's so much stuff in this thread that I can't keep up anymore ? I just had a quick look and it seems that adding new panels is currently not possible without directly modifying the module file(s) and dropping the class file to the panels directory. I was wondering if you'd be open to adding some way of "injecting" custom panels from outside the module? My initial idea was something along the lines of allowing custom options to be pushed into the allPanels array by passing it to hookable methods at certain points and adding support for array values so that custom panel options could contain both name and path. (I didn't actually try this. It's possible that hooks won't work due to load order and all that, so another option would be the Tracy module reading them from config settings; not quite as elegant or robust, but pretty much guaranteed to work.) Anyway, just throwing in ideas. I'm working on some Wireframe related dev tools, and was thinking that it'd be neat to have them available in the admin — and what better way to do that than to introduce them to Tracy... ?

This issue is resolved in the latest version of WireframeRendererBlade. Let me know if the problem persists, though ?

Thanks, @mlfct. This seems to be related to the WireframeRendererBlade module — I've opened an issue for it here: https://github.com/mauricius/WireframeRendererBlade/issues/1. Simply put the Blade renderer appears to expect component views to be found from /site/templates/views/[component name]/[view name].blade.php, while Wireframe expects them to be at /site/templates/components/[component name]/[view name].blade.php ? I would recommend keeping tabs on that issue if you want to use Blade. Twig implementation shouldn't have the same issue, though.

@mlfct, what version of the module do you use? I recently changed a few things that might've been related, so there's a chance that it's fixed already. That being said, I don't use twig/blade myself, so if the issue still exists in the latest version, I'll have to dig in to see what's going on. Also, thanks! I'm really glad to hear that uou've found Wireframe useful ?