teppo

I would recommend doing this on the front-end: when the close button is clicked, hide the box and set a cookie. Check the cookie on page load (with JavaScript) and only show the box if the cookie isn't set. This is all pretty simple, and you can likely find a pre-built solution with a bit of googling. If front-end implementation isn't, for whatever reason, possible, you can also also set the cookie with PHP (if you're running ProcessWire 3.0.141 dev or later, check out $input->cookie) or use $session to remember that the user has closed the box. This will, though, require that you pass the request to PHP first – for an example the "close button" could actually be a link to something like "/?close_the_box=1" which then triggers required PHP code in your home template, or you could perform this query with JavaScript when the button is clicked. Hope this helps a bit.

Hey folks! I've been a bit quiet here, but that's mostly because I've been busy building stuff with ProcessWire and Wireframe ? Just wanted to give a quick heads-up for a new feature called components that I'm currently testing (it's in the dev branch of the module already), in case anyone wants to comment on it before it gets merged to the master branch. Wireframe components are classes extending an abstract base class (\Wireframe\Component), and they can either render output directly by implementing the render() method, or they can be rendered using a separate Component View file. This is probably a familiar concept to most, but the general idea is that while partials ("dumb" files with no way to process params, and no clean way to separate code from markup) are enough if you just have some relatively static snippet that you need repeatedly, components add an extra layer where you can a) specify which params they accept, b) process those params, and c) include any additional "business logic" that should be triggered when the component is rendered. Here's a simplified example of how this comes together: /site/templates/components/Card.php (class for the Card component) <?php namespace Wireframe\Component; /** * Card component */ class Card extends \Wireframe\Component { /** * Constructor method * * @param \ProcessWire\Page $item Page related to current Card. */ public function __construct(\ProcessWire\Page $item) { // Pass properties to view $this->title = $item->title; $this->summary = $item->summary; $this->image = $item->get('image|hero_image'); } } /site/templates/components/Card/default.php (default view for the Card component) <?php namespace ProcessWire; ?> <div class="card"> <?php if ($image): ?> <img src="<?= $image->size(640, 480)->url ?>" alt="<?= $image->description ?>"> <?php endif; ?> <h3><?= $title ?></h3> <?php if ($summary): ?> <p><?= $summary ?></p> <?php endif; ?> </div> ... and for fetching and rendering the component, there's a little static helper in the Wireframe module class: <?php foreach ($cards as item): ?> <?= Wireframe::component('Card', [$item]) ?> <?php endforeach; ?> Note that Wireframe::component() actually returns an instance of the component class, not a string, but since \Wireframe\Component::__toString() calls \Wireframe\Component::render(), what we're doing here is essentially the same as echoing out the result of (new \Wireframe\Component\Card($card))->render() ? So, anyway, that's basically what I've been working on here. I'd be happy to hear if you have any comments on this addition – I haven't yet merged it to master since I'm still experimenting with it, and I'd like to avoid as many breaking changes in the master branch as I can. So far this has worked great for me, but to be honest my requirements have been pretty basic. Thoughts?

Hey @verdeandrea! Questions related to ProCache should be posted to the ProCache VIP support area here on the forums. When you bought ProCache you should've gotten access to this area, but if you didn't, please send a message to Ryan. The modules/plugins area of the forum is intended for third party module support threads (one per module), so I'm moving this thread to general support. Please let me know if you want it moved to the ProCache support area instead ?

To be fair PHP 7.4 has only been out for a few weeks. I'm not advocating sticking with old versions for any longer than is necessary, but as with most software, going with the cutting edge version of PHP is a bit of a risky move. I'd recommend giving it a few more weeks at least ?

Not familiar with Azure service apps (?) but a 500 error should always leave a log trail. I'd definitely start by hunting down those log entries and see from there how to go further – it's difficult to say much more based on this alone, sorry.

Hey there Jim, welcome to the forum! I've seen a few other reports related to the developer directory pop up lately as well. @Pete, you aware of these? ?

A bit off-topic, but while typecasting an empty array to boolean does indeed result in false, "empty($array)" has its benefits. It's slightly more verbose, but it also won't cause a notice if $array hasn't been defined yet, and it's arguably more obvious (leading to better readability). Relying on typecasting can sometimes result in obscure issues, as well as make the code ever so slightly harder to decipher. Using "count" to check if an array is empty is a common mistake. Even if in most cases the actual performance difference is too small to really matter, there's no reason to do this ??

Sad to see you go, but this seems like a reasonable conclusion in your case ? Regarding your issue – I've never come across anything exactly similar myself. Since we're talking about the default multi-language site profile, there's very little data to load, so my initial guess would be that the request, or perhaps the PHP process, gets stuck somewhere. In the case of PHP the file compiler (core feature originally intended to ease migration from 2.x to 3.x) comes to mind – though that probably shouldn't be the case here – while disk based sessions could be another. Of course the database connection could also be the bottleneck, but if you're sure that it's configured properly, then I have no idea how it could be that slow. MySQL slow query log could help in ruling this issue out though. If you still want to debug this further, you might want to give database sessions a try (they can be enabled by installing the Sessions / ProcessSessionDB module, which is bundled with the core package), and just in case specifically disable the file compiler by setting $config->moduleCompile and $config->templateCompile to false in /site/config.php. I have no recent experience with Windows, so not sure if something there could cause the slowdown. That being said, I do know that others are running ProcessWire on Windows, so that alone shouldn't be a problem, unless it's some rather obscure configuration issue there. If other systems are working as expected then a configuration issue sounds less likely. While WordPress admittedly caters for a number of really unlikely borderline cases (including the use of the deprecated mysql PHP extension), Laravel working as expected probably means that the environment itself is properly set up.

I merged your question to the correct thread earlier, so yes – this is it ?

Hey @DL7, just a quick heads-up: I've merged your questions into the support thread for the Admin Restrict Page Tree. The modules/plugins area of the forum is intended for module-specific support threads (one per module), and you can find the correct thread via the modules directory.

Hey @Mike Rockett. I'd be happy to try, if you're busy. I've got a need for this in one of my current projects anyway ?

Just for the record (not saying that it would be the best solution overall), FieldtypePageIDs also has certain benefits if/when the problem is loading too many Page objects into memory. It could be worth looking into in this sort of situation ?

Another +1 from here. If a module I maintain works for something other than Uikit then that's brilliant – but if it doesn't, I won't lose any sleep over it. For quite a while I used to support the "legacy" theme, new default theme, and Reno theme, but that was a major headache. There will no doubt be sites running those older themes for quite a while, but my guess / gut feeling would be that a notable portion of those are older sites that probably aren't that actively developed anyway.

Hey @Mike Rockett! I'm wondering if there's some way to add support for URL segments in the module. Any chance you might've figured this out already? ? Basically in my use case there are pages that list items below them, yet those items actually live outside of the publicly viewable page tree. It's a no-brainer that they wont work right out of the box, but what I'm wondering is if we could somehow – hook or some template setting or something – inform MarkupSitemap of these "non-pages", and add them to the sitemap. I had a quick look at the codebase, and I'm wondering if this could be achieved by an optional hook in MarkupSitemap::addPages, perhaps by passing $page and $url to a hookable method after calling $this->urlSet->addUrl($url)? Seems that this way I could add a custom round of iteration and also add those URL segments as new URLs to the URL set ?

@Mike Rockett, sorry to bother you with this again, but with version 1.5.56 of Jumplinks we're still seeing quite a few database errors: Looking at the database the column is now varchar(512), but it seems that's just not enough. On a related note: on this site "Log 404 hits to the database" isn't checked, so I'm wondering why this is still happening? This is unrelated to the database issue above, but it also seems that there might be some unnecessary / unexpected process going on in here ?

If you're using the code you posted earlier, i.e. "$results = $pages->find(...)" and "$out.= $results->renderPager()", SearchEngine settings won't kick in at all. This is plain old native ProcessWire stuff, so you'd have to provide pager settings directly to the renderPager() method ? SearchEngine pager_args only apply if you're using it's native rendering features. Though please let me know if I'm missing the point here!

Hey @guy, thanks for sharing this! Unless I've missed something important, note that your module doesn't actually have to hook into WireMail::___send() – it's a WireMail module, so it should implement its own ___send() method instead. This is how WireMail modules are designed to work, and it also guarantees proper interoperability in the case that other WireMail modules are installed ? See WireMailMailgun for a reference.

Just released SearchEngine 0.13.0. This version adds more validation regarding the search index field: there's a warning if the field is of wrong type, an option to automatically create it if it doesn't exist (i.e. it has been removed after the module was installed), and there's a notice in the module settings screen if the index field exists and is valid but hasn't been added to any templates yet. Additionally there's a fix for an issue where FieldtypeTextareaLanguage wasn't recognised as a valid index field type in module settings. This could've resulted in the index field setting getting unintentionally cleared if/when module settings were saved.

The trick is to whitelist "q", after which MarkupPagerNav automatically sticks with it. Add this after you've validated the $q variable: $input->whitelist('q', $q); Note also that if this is your literal code, you should move the renderPager call in the if statement – if $q isn't set or validated, $results will be null, and this will cause an error ?

@ceberlin @3fingers As of 0.12.0 SearchEngine now supports multi-language indexing and searching. This is based on the native language features, so the results you see depend on the language of current user etc. While I don't have a good test case at hand right now, I did some quick testing on one of my own sites and it seemed to work pretty much as expected – though please let me know if there are problems with the latest version ? What you need to do to enable this is convert the index field (which is by default called search_index) from FieldtypeTextarea to FieldtypeTextareaLanguage.

This is on the top of my to-do list now ?

Hey Bernhard! SearchEngine already provides a way to highlight hits found from the generated summary, but since there's currently no built-in way to show dynamic summaries on the search page, this doesn't apply to the entire index. See here for an example: https://wireframe-framework.com/search/?q=wireframe. Please let me know if I've completely misunderstood what markjs does – I'm interested, but not quite sure if it would be beneficial, and/or how it would differ from current situation ?

Just released Wireframe 0.7.0. This version is all about caching: when requesting Controller methods from view (<?= $this->some_controller_method ?> etc.) the return value is now cached (runtime cache). Additionally if method names are added to protected $cacheable_methods property of the controller class, along with an applicable expire time (i.e. "protected $cacheable_methods = [ 'method_name' => 3600 ]"), Wireframe automatically caches the value using WireCache (persistent cache). Caching is usually a good thing, but not always preferred, which is why runtime caching can be prevented by adding the method name to (protected) Controller property $uncacheable_methods (protected $uncacheable_methods = [ 'method_name' ]). Persistent caching is always opt-in. Changelog: ### Added - Runtime caching support for Controller method return values. Values are cached *unless* the name of the method is found from Controller::$uncacheable_methods. - Persistent caching support for Controller method return values. Values are cached only when found from the Controller::$cacheable_methods array. ### Changed - In the View class all internal requests for Controller properties are routed through View::getFromController().

Well, this likely rules out the first issue I was thinking of. There are still two possible explanations: either sitemap generation fails, or writing the sitemap file to the disk fails. I'm not particularly familiar with this module, so all I can suggest at this point would be dumping some debug data out of SitemapManager::generate() function; basically checking if the !count() statement is returning false (in which case there are no items, which in turn would warrant further investigation into why that would happen), or if it's the write operation that is failing. You should also double-check that the path on disk (the root of your site, essentially) is writable for the user running Apache (often www-data, but could be something else, depending on your setup). Edit: I installed SeoMaestro on a new site running the latest dev version, and everything worked as expected. I know this won't help much in this case, but at least I can confirm that the module should work, which means that the issue is likely somehow related to your environment, or the specifics of your site ?

Do you have a SEO field (FieldtypeSeoMaestro) added to at least one of your templates? I can't remember if this was always a requirement, but without that the module won't generate a sitemap, and thus it will output that specific error message. This error is a bit misleading: it recommends checking that the folder on disk is writable, but you'll get the same error even if you simply didn't have any items to add to the sitemap. What's happening here is basically that the module attempts to generate a sitemap with SitemapManager::generate(), which returns false if it fails to write the file, but also if there are no items to be found. Ping @Wanze – might be a good idea to add additional check for this ? If you do have the SEO field and the write permissions are fine, I'd probably try debugging the sitemap generation code in the SitemapManager class, just to see if it's working as expected.