Jump to content

teppo

PW-Moderators
  • Posts

    2,918
  • Joined

  • Last visited

  • Days Won

    90

Everything posted by teppo

  1. @erikvanberkum, I've merged your question from general support to the support thread of the FieldtypePDF module. You may also want to open an issue about this in the FieldtypePDF GitHub repository. Also, please make sure that you're running the latest version of the module 🙂
  2. The problem here is that it depends a lot on your setup, i.e. which output strategy you're using and how your site is set up etc. 🙂 If you're using simple direct output (templates/template_name.php directly renders output) then you could do something as simple as this: <?php namespace ProcessWire; // finding results goes here if ($config->ajax) { // render results without page "frames", i.e. just the list of cards // ... and when done, halt the rendering process: $this->halt(); } // normal page output Now you just need to trigger an AJAX request to the same page, read the output, and then replace the part of the page content that you wish to be "dynamically filtered" with new content. Note that for $config->ajax to work, your AJAX request needs to include the "X-Requested-With: XMLHttpRequest" header; jQuery adds this automatically, but if you're using raw XMLHttpRequest, Fetch API, or any other approach to trigger the request then you'll likely have to add that header yourself. More examples for AJAX loading content (including alternative approach, where instead of content you return JSON and then render output in JavaScript) can be found from this thread: Loosely related, but a couple of issues I spotted in your sample code: You're passing $chan and $cont values to the selector string unfiltered. This is not a good idea: visitors could pass in characters that break the query, or even rewrite the query. Always run user-provided values through Sanitizer methods ($sanitizer->selectorValue()) is a good default, but if you're expecting integers then use $sanitizer->int(), etc. Since you're first finding all results and then limiting them, you will run into performance issues if there's a lot of data. As a general rule of thumb always include a limit in your initial selector — this way the limit is applied in the database, which is much more efficient.
  3. Currently you could get this from the versionControlRevisions property of the page. The value of said property is an array of all existing revisions, or null if none were found, so passing it to count() will tell you how many of those there were: echo count($page->versionControlRevisions);
  4. I can't say that I have a strong opinion here either. Also not sure if I grasp the whole context — when you say "routing" and mention URL segments, does that mean that you create routes automatically based on page structure (I assume so but...) or that there's a separate routing setup for front-end and page structure is only reflected in the data? Or do you mean something different with this? 🙂 This may or may not be related, but one thing to consider is whether you want Symprowire to be "all in", or rather something that can be used only for some parts of the site. Couple of examples from other MVC(ish) solutions: Template Engine Factory hooks before Page::render and replaces the response, but also provides hookable method (TemplateEngineFactory::shouldRenderPage) for preventing it from rendering the page, in which case the site will fall back to the regular rendering flow (whatever that happens to be). Wireframe takes an entirely different approach: instead of a hook ("enabled by default") you need to point templates that you want to render via it to the front controller file via Alternate Template Filename setting (more details in the docs). Essentially it's disabled by default. Wireframe is my pet project and something we've used for our production sites for a while now, so that's what I'm mostly familiar with. I intentionally decided not to use hooks, since I felt it was best to let the developer decide if they want to use Wireframe for everything, just a small part of the site, or something in between. In fact it's possible to skip the MVC structure entirely, and just use Wireframe for its partials and/or components 🤷‍♂️ Template Engine Factory may be a bit closer to Symprowire feature wise, although Symprowire clearly has a much larger scope (and is more opinionated). So not sure if any of what I've said here applies as-is 🙂
  5. Depends on where and how you want to use this 🙂 The query object has "pager" property that returns a rendered pager, and Renderer has public method (Renderer::renderPager(array $args, Query $query)) that does the same. Whether or not these will be useful depends, again, largely on your context.
  6. I must admit that I'm not really following your logic here: <?php foreach ($page->find('template=uporabnik, sort=random') as $single ):?> <!-- MY Attempt, but not working --> <?php if ($single->count('template=uporabnik, objekt_select=$single') < 1) : ?> First you're iterating over all the children of current page that use the uporabnik template. It's a bit unclear what exactly that "current page" is, but assuming that it has visible "uporabnik" pages below it, this should find them. In the next step you're checking if individual uporabnik pages also have children using the uporabnik template... but these children must refer to their parent page via the objekt_select field. I'm pretty sure that there's some sort of confusion here (that latter selector doesn't seem to make much sense), but since I don't know what your page tree looks like, I'm just guessing here. Could you provide an example of how these pages are structured in the page tree, which templates are used where, and where in that structure are we now (in this example)? That would be helpful in figuring out what exactly is going on 🙂
  7. @PWaddict, the issue you reported earlier should now be fixed. Sorry for the delay.
  8. @mlfct, the issue mentioned above should now be fixed in SearchEngine version 0.30.2. Thanks for letting me know about this and sorry for taking so long to solve it 🙂
  9. This seems like a bug. So far I've traced it back to version 0.29.0, but will have to dig in further to see what's causing it. This version introduced major changes behind the scenes, so I'm not entirely surprised that something went wrong. I'll get back to you once I figure this out.
  10. This seems like an issue with ProcessWire itself, not SearchEngine. If you have a chance you might want to give the latest dev version of ProcessWire a try, though if it's a live site then I'd recommend doing it locally / in a development environment first, or alternatively backing your site up before the update (just in case). If that doesn't solve it, you may want to open an issue for this at https://github.com/processwire/processwire-issues. "Internal Server error" alone isn't very informative, so you may also want to dig into your log files etc. to see if there's anything more specific there.
  11. Done — https://processwire.com/talk/topic/25815-custom-notes/. Moved the two posts introducing Custom Notes and placed them in the Modules forum section instead of module development (it's a proper module after all), hope that's fine 🙂
  12. Hey @Cybermano, Just letting you know that I opened an issue for the module here: https://github.com/cybermano/CustomNotes/issues/5. Minor things, but they are kind of showstoppers for the module right now. After fixing those, things seemed to work pretty nicely 🙂 That would make sense in my opinion. Or if you prefer to, I can split the thread starting from that message (https://processwire.com/talk/topic/25435-custom-notes-former-list-of-allergens/?do=findComment&comment=213864) into a new thread — just let me know.
  13. teppo

    Snippets

    A few days ago I stumbled upon this old module, which had been laying in the modules directory of one of my sites since 2017 in a half-finished state. I have no recollection why I left it like that, but figured it might be useful for someone, so here we go: https://github.com/teppokoivula/Snippets https://processwire.com/modules/snippets/ Snippets is a tool for injecting front-end code snippets (HTML/JS/CSS) into page content. The way it works is that you create a snippet — say, a Google Analytics tag — and then choose... which element it should be tied to (there are some pre-populated choices and custom regex option), whether it should be placed before/after said element or replace it entirely, and which pages the snippet should apply to. The "apply to" option also has some ready to use options (such as "all pages" and "all non-admin pages") or you can select specific pages... or use a selector. Snippets are regular markup, with the exception that you can use values from current page (behind the scenes the module makes use of wirePopulateStringTags()). Available hooks: Snippets::isApplicable, which receives the snippet object and current Page object as arguments and returns a boolean (true/false). Snippets::applySnippet, which receives the snippet object, page content (string), variables (an object derived from WireData), and an array of options for wirePopulateStringTags() as arguments and returns the modified page content string. That's just about it. It's a pretty simple module, but perhaps someone will find this useful 🙂
  14. To be honest I've never attempted anything like that 🙂 Just did a quick test and something along these lines might work — though I'd highly recommend testing first in a non-production environment: if ($user->isSuperuser()) { $wire->addHookBefore('ProcessPageView::execute', function(HookEvent $event) { foreach ($event->templates->find('name!=admin') as $template) { $template->filename = 'wireframe.php'; } $event->removeHook(null); }); } Note: you don't want to set altFilename specifically. I'm not too familiar with how this actually works, but I just tried that, and it seems that ProcessWire is quite keen to save said value (persistently). Managed to break one of my local test sites 😛 (Based on a quick test setting filename seems less problematic.)
  15. I'm posting this as an update to an earlier post created by @Hari KT: https://processwire.com/talk/topic/4958-composer-support-for-processwire/. Though that approach still (kind of) works (as does the one detailed in https://github.com/wireframe-framework/processwire-composer-installer), thanks to @d'Hinnisdaël there's now a better alternative: the official composer/installers project 🙂 An example repository implementing the things detailed in this post: GitHub repository: https://github.com/teppokoivula/HelloWorld Packagist entry: https://packagist.org/packages/teppokoivula/hello-world As a module author, how do I make my module installable via Composer? 1) Add a composer.json file to your module's directory. Here's an example: { "name": "vendor-name/module-name", "type": "processwire-module", "license": "MIT", "extra": { "installer-name": "ModuleName" }, "require": { "composer/installers": "~1.0" } } The composer.json file explained: "name" consists of two parts: your vendor (author) name, and the name of the package (module). These can (but don't have to) be the same as your GitHub or BitBucket user and repository names. Please note that this value should be all lowercase! That's the syntax expected by both Packagist and Composer. "type" should be "processwire-module". You may have seen "pw-module" used by other packages; that's the value used by third party installers, you don't need to worry about that now. "license" should specify the license your module is published under. See Composer help for expected syntax. It's technically fine to leave this out, but it's always a good idea to let users know how they're allowed to use your code. "installer-name" under "extra" should specify the expected directory name for your module. Usually this is the same as your module's name. If you leave this out, the package part of the "name" value will be used instead (which may be just fine, though I'd recommend always filling in this value). "require" includes Composer dependencies of your module. The key part here is "composer/installers" — without this Composer won't know that your module requires said installer, and it may not be installable at all, so be sure to add this row. 2) Submit your project to Packagist: https://packagist.org/packages/submit. You will need an account for this step. It's free and very easy to register, and you can automatically connect it with your GitHub account. Connecting with GitHub also makes it easier to auto-update package versions from GitHub repository. 3) Recommended but not absolutely necessary: add tags to your module's Git repository. It's recommended that when you push a new version of your module to GitHub or BitBucket, you also add a matching tag: if you push version 0.0.3 (or version "3", following the old school ProcessWire version number format), you should also add tag 0.0.3 (or "v0.0.3" if you want to be verbose) to GitHub/BitBucket. (This step is not strictly speaking necessary, but it does make things easier for users installing your module, and makes much easier to track which version of the module is currently installed via Composer. It requires additional step when publishing a new version of the module, but please consider doing it anyway!) 4) Also recommended but not absolutely necessary: configure Packagist to auto-update based on GitHub/BitBucket. Follow the instructions here: https://packagist.org/about#how-to-update-packages. This step ensures that once you push a new version of your module, Packagist automatically updates stored information without you logging in and hitting the "update" button manually. (This step may not be necessary if you've already allowed Packagist access to your GitHub account.) ... and that's it. Congratulations, your module is now installable via Composer! As a module user, how do install a module via Composer? Go to your site's root directory and type on the command-line "composer install vendor-name/module-name". You can look up the correct details from Packagist, or the module author may have included them in the support forum thread. Obviously this only works for those modules that have implemented Composer installer support as outlined in this tutorial. Note: if you're using a "non-standard" directory structure for ProcessWire — you've moved the root of the project outside the public web root, or something along those lines — check out the custom install paths part of the composer/installers README. The "installer-paths" setting allows you to manually specify a custom install path for the "processwire-module" package type.
  16. Could you explain what your goal is? I mean — you're already handling dependencies via Composer, so that's a good start at least 🙂 If you want the module itself to be installable via Composer, the approach I'd currently recommend is detailed here: https://github.com/wireframe-framework/processwire-composer-installer. Change the "type" in your composer.json to "pw-module" and add wireframe-framework/processwire-composer-installer to your requires and that's just about it. In case you were wondering, ProcessWire doesn't currently have a way to handle Composer dependencies when a module is installed via Admin. Module with dependencies will either a) need to be installed the regular way and then the user has to run composer install manually, or b) installed via Composer (see processwire-composer-installer) in which case dependencies are automatically handled. ... or you could bundle all dependencies in the Git repository itself. Somewhat crude approach perhaps, but also the easiest one for most users of your module.
  17. Version 0.21.0 released: ### Added - Hookable method MethodPropsTrait::getMethodPropCacheName(string $name, string $context). Note that when hooking into this method one should refer to the object that implements the trait, such as a specific Controller class. ### Changed - Include language ID in persistent cache name generated by MethodPropsTrait for cacheable methods. @Zeka, thanks for bringing the lack of multi-language support for cache names up. While testing I noticed that a site I've been working on recently was in fact also affected. Not a huge deal in this case but it could've caused some confusion. For the record: I ended up just adding the language ID to the key. If LanguageSupport is not installed it'll be a blank value, but that doesn't really matter 🙂
  18. That's a strange one. A couple of checks first: Does your layout file include the ProcessWire namespace? If not, you'd have to call it via \ProcessWire\Wireframe (though adding namespace is always a good idea). Which version of Wireframe do you have installed?
  19. Absolutely, both options seem reasonable — I'll add this to my todo list!
  20. Generally speaking PHP 7 and 8 tend to work similarly in these situations — PHP 5 was more "forgiving" 🙂 Anyway, it could be related to VC 1.3.1. I've been using VC 2.x for a very long time, will have to set up a test site for 1.x. Edit: turns out it's an issue affecting PW < 3.0.166. At least this particular instance of it is pretty easy to circumvent; I've prepared a fix, but will have to test carefully before releasing it.
  21. Hey @PWaddict! So far I've been unable to reproduce that. I'm running PHP8, which should be close enough, but there are no warnings for me. The error you've mentioned — assuming that you're using recent ProcessWire version — seems to point to WireDatabasePDOStatement::setDebugParam(), and more precisely it getting an integer as the param name. I've no idea how that could happen, and at the very least I can't find anything in Version Control that should (directly) cause it. So... if you have any additional details, like where in the Version Control this error might originate, that'd be great. Also: which version of ProcessWire and which version of Version Control are you using?
  22. teppo

    Community Gamers

    Similar experience here. For me it was all about adventure games — Space Quest, Kings Quest, Police Quest and Quest for Glory, as well as point-and-click games such as Maniac Mansion, Monkey Island, etc. Especially early adventure games with a text parser were brilliant tools for learning the language: while they didn't necessarily require you to be fluent in English, you had to have a decent vocabulary and at least some idea about how to form sentences 🙂
  23. Hey @Pete! Not sure if this has changed recently, but just noticed that http://processwire.com/talk/ works as well. Should/could this redirect to the HTTPS version instead? Unrelated note regarding moderator actions: I'm pretty sure that flagging someone as a spammer used to hide their posts. Doesn't seem to work that way anymore. Also I seem to recall there being some sort of limit to what new users can post. Am I wrong or did something change regarding this/these? 🙂
  24. This looks like the .htaccess file found from /site/. You should check the one in your websites root directory (one folder above /site/) instead. As @wbmnfktr mentioned, similar issues have been covered here before. This one could be related (though I'm kind of guessing here). It's a bit old so there have been some changes to the root .htaccess file since then as well:
  25. It's not really about being clever: the core ships with a metadata file (wire/core/.phpstorm.meta.php) that makes PHPStorm aware of the inner workings of the wire() method. PHPDoc comments only state that the wire() method may return a number of different objects, so there's little that the editor can figure out from that alone. VSCode doesn't (AFAIK) have anything similar to this, but depending on the plugins you use this may be possible — with some caveats. I use PHP Intelephense, and while it does actually read PHPStorm metadata, it doesn't seem to support reading it from subdirectories: https://github.com/bmewburn/vscode-intelephense/issues/1384. At the moment I don't have any idea how to get this to work, except of course for duplicating the metadata file to your project's root directory. (Or finding a plugin that supports this feature 🙂)
×
×
  • Create New...