Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 03/01/2020 in all areas

  1. UPDATE 2020-03-01 SnipWire 0.8.3 (beta) released! In this new release the installation and uninstallation process has been heavily revised! The module and its submodules should now uninstall perfectly. To preserve the full products catalogue and products data, all fields with the custom field type FieldtypeSnipWireTaxSelector are now converted to FieldtypeText on uninstall. If yo want to reinstall SnipWire and reuse your previous products catalogue, you simply need to change the taxes field back to FieldtypeSnipWireTaxSelector. Here is the complete list of changes: Updated products package installer to add specific module config on install The uninstallation process is now much more reliable FieldtypeSnipWireTaxeSelector is now uninstalled properly (existing fields are converted to FieldtypeText) Refactored ExtendedInstaller class to be more reliable Extended resources installer page is now more user friendly Fixed product price JSON output if a currency field is missing Small fixes and code enhancements Updated apexcharts.js vendor plugin to version 3.15.6
    2 points
  2. Another loose approach to MVC like the last few posts above, is how I usually do things. Pages API is the model, template files are controllers, and separate files for views: <?php namespace ProcessWire; // templates/home.php region('breadcrumbs', false); region('content', wireRenderFile('views/home/hero')); region('content+', wireRenderFile('views/home/testimonials')); region('content+', wireRenderFile('views/home/benefits')); $meta['name']['twitter:description'] = $settings->site_tagline; $meta['property']['og:description'] = $settings->site_tagline; <?php namespace ProcessWire; // templates/register.php require_once("./_forms.php"); $status = processRegisterForm(); if ($status && $status['success']) { wire('session')->redirect($page->url . 'success/'); } $view = [ 'status' => $status, ]; if (wire('input')->urlSegment(1) == 'success') { region('pageTitle', 'Registration complete'); $page->summary = ''; $viewName = 'views/register/success'; } else { $viewName = 'views/register/form'; } region('content', wireRenderFile($viewName, $view)); wireRenderFile() is an alias of the PW Files API 'render' function and takes a path to a file and an optional array of data/variables. I also use the Markup Regions functionality. The examples above are taken from this GitHub repo for one of my sites.
    2 points
  3. I treat things similar to this, except that the separation between "view" and "controller" is created by PW's "Prepend file" feature possible via the template settings. The procedural code of the "controller" is placed into a file article-control.php, for example, while the "view" is in article.php, which is the standard template file with PHP's "alternative" syntax, just as originally intended by Rasmus Lerdorf. To keep files organized, I put this into /site/init.php for each template that needs code: $templates->get('article')->filename = $config->paths->templates . 'pages/articles/article.php'; While the location of the prepended "controller" is set in the admin like this: pages/articles/article-control.php This way I can put any article/articles related files into the pages/articles/ directory, and not just these two ones but files like included template partials, JavaScript files only required by article pages, etc.
    2 points
  4. Another perspective: The API acts as the model, with the $page / Page class giving you access to page data through a generic interface. By default, the PHP template file for the current content type / template acts as Controller and View, though you can easily seperate Controller and View by using, for example, a frontend templating library like twig. That's close to my usual setup: View: Twig acts as a View layer, since it gets pretty privileged access to API variables, you can get anything done you'd usually do in a PHP View class. Controller: The PHP template file acts as the Controller, for example processing input and rendering the correct Twig template. Usually, I just keep the template logic procedural, because ProcessWire already does a lot of work in determining the correct template file and setting up API variables. Though you could also use a custom Controller class and just use the template file to instantiate it. Model: As mentioned above, the $page API variable is already a kind of generic model for your data, and for sites that are mostly brochure sites / presentational in nature, this is really all you need. But if you want to go further, you can create custom page classes by extending the Page class and set your template to use that, this way you can make your model as smart as it need to be. I have written two tutorials on how to integrate Twig if you're interested ? Part 1: Extendible template structures Part 2: Custom functionality and integrations
    2 points
  5. Just to clarify this a bit: 1. No (out of the box). 3. ProcessWire doesn't enforce any specific architecture on you; instead you can utilise just about any architecture/strategy you want. If you haven't yet had the chance to read https://processwire.com/docs/front-end/output/, I'd suggest checking it out — learning about direct output and delayed output (and their differences) should clear some things up. As @szabesz pointed out above, there are ways to use MVC (or something very similar) on ProcessWire powered sites/apps. In my opinion MVC is great for a lot of stuff, but as always, by design ProcessWire makes zero assumptions: for some use cases simple direct output approach is quite enough, and makes things more straightforward (to build, but also to maintain) ?
    2 points
  6. I saw this slide on Twitter : Apparently PHP8 will throw Errors instead of Warnings for many instances. So perhaps it is adviceable to already start preparing your code for the upgrade.
    2 points
  7. Here's a small new module that started as a spinoff of a memcache proof-of-concept. Cache your strings and partials in-memory using Redis as a backend. CacheRedis All you need is a running Redis database. The module supports connection through regular TCP, over TLS and via unix domain sockets. Host and port are configurable, and authentication is supported too. Here's a screenshot of the module configuration options: I'll not go into too many details about the usage, you can see everything explained in the README on GitHub, and just highlight the most important points. When the module is active, you'll have a wired $redis variable, which means you can reach the module as $redis, wire("redis") or within Wire classes / modules as $this->redis. CacheRedis is strongly influenced by WireCache, and its usage is (hopefully) straight forward. // Store an entry in the cache under the given key name with the given value: $redis->store("cached_value_number_one", $expire, $value); // Retrieve a value from the cache $value = $redis->fetch($key); // Delete a cache entry $redis->delete("my_other_cached_value"); // Clear the whole cache $redis->flush(); // Retrieve a value from the cache, and if not found, create it through the given function // and store it with a lifetime of 5 minutes (300 seconds) $value = $redis->fetch($key, 300, function() use($page) { return "Page last changed on " . strftime('%m/%d/%Y %H:%M', $page->modified | $page->created); }); // Render a file using wireRenderFile and store it in the cache. // We'll pass a selector as the expiry value so this cache gets // emptied every time a page matching the selector is saved. $news = $redis->renderFile("partials/news.php", 'template=blog-post', ["page" => $page]); The module is still very crude work in progress, but I hope some of you feel daring, try it out and let me know in case anything breaks. Have fun!
    1 point
  8. Have you tried it? There is already support for strtotime strings for datetime fields in PageFinder selectors, and your example query works just as you wrote it. ? For in-memory (WireArray) selectors you have to use a timestamp in the selector.
    1 point
  9. And the community loves you (two). Thank you for releasing the files, I'll definitely have a look into it after holidays. I'm sure it will be tremendously useful and I hope I will find the time to provide some improvements to it. Thank you so much.?
    1 point
  10. Thanks @bernhard, problem solved! I decided to use the "convert field type" method.
    1 point
  11. @Jan Romero, I got it working with your code. Thanks.
    1 point
  12. Hi @B3ta I had too much work this week so its planned for the next tuesday. Can you upload again the screenshot please ? I can't see it. Thanks you.
    1 point
  13. Try again. I re-built the minified JS for production and pushed a new release. Should work now.
    1 point
  14. How is RockDatetime different from wrapping date fields in Carbon instances? Not trying to be dismissive here, just curious how this would help to establish a sane default for dealing with datetimes (which ProcessWire is currently lacking, unfortunately).
    1 point
  15. Hello, Recommend @teppo's module:
    1 point
  16. Any news on the new stable version? Currently i'm getting this error when I'm trying to activate the module.
    1 point
  17. I think this is hard to say when we don't know the exact setup. I could think of these options: Prevent uninstall (as you said). Convert the fieldtype (as you said). Move the dependencies out of SnipWire into the Fieldtype. This means SnipWire could not live without the Fieldtype but the Fieldtype could live without SnipWire. Move the helper functions in a separate module that both SnipWire and the Fieldtype can use as a dependency. Maybe static methods are an option? https://www.php.net/manual/en/language.oop5.static.php Though I think you can't access the $wire object in static methods, so that might not be the easiest option, because you can't use all of PW's internal tools.
    1 point
  18. I think you edited your original post and topic title, right? My answer was for the original question and isn't relevant now that you've changed it. Better to mark a topic as solved and start a new topic in such situations I think.
    1 point
  19. Hi there, I have been trying for days, but unfortunately without any good results.. Within my website users log in, and each user has personal files he/she can download. Everything works perfectly thanks to the module, however I cannot wrap my head around the following: - On the 'overview' page, the user can see an overview of their files after they logged in. Lets call this page 'overview.php.' - On the 'download' page, the module's API is called. overview.php: // files are placed in a repeaterfield that contains the 'securefile' and a 'title' field. <?php foreach ($user->fileRepeater as $id => $f): ?> <a href="/download?id=<?= $id ?>"> Download button </a> <?php endforeach ?> download.php: <?php secureFile = $user->fileRepeater->eq($input->get->id)->file; $secureFile->isDownloadable(); $secureFile->download(); ?> Unfortunately, this does not work for me. The page URL does not pass the $id query parameter, it simply redirects to '/download.' If anyone has any ideas.. I am very much open to it! (edit) Solution: Some problems have simple solutions.. download.php wasn't working due to the URL ending incorrectly.. As I wanted to pass as specific ID through $input->get->id, it simply didn't pass the id because the URL ended with a slash.. Solved it by going to the template in question within PW > URLs > Should page URLs end with a slash > No
    1 point
  20. Yeah, I guess PW's module dependency features are too limited for such cases. I think you'd need to remove the dependencies in the module's info array and implement them on your own somewhere in the modules' install() and uninstall() methods.
    1 point
  21. Hi guys, I was very excited for this module, but my life took a huge direction change and I no longer have the time to invest in module development. I am gonna leave the files here. You guys can take it and run. Maybe there might be something useful here. Maybe not. I still think it's a good idea to do drag and drop modal building in PW. So hopefully one day something like that can come to light. I love this community and I love ProcessWire. Live long and prosper. - Joshua Designme 2.zip
    1 point
  22. In an ongoing effort to provide a sort of case study, and more info about this, I'll post random screens and info about the various features of this site. (1) Custom Dashboards The site uses a custom module that supports multiple dashboards. Any given dashboard is configurable and access controlled also. This is the main dashboard: (2) The admin editor pages take advantage of some great modules, namely RuntimeMarkup @kongondo, PageFieldInfo @Robin S, Field Descriptions Extended and more, There is also a new module not released yet called Admin Comments, which for this project got a lot of use. When dealing with a large and complex data collection as was the case with this project, the editors benefited from the ability to have the data auto-analyzed on each work so the "auto flags" field helped with that. The comments also allowed editors to post information, ideas and comments right into the page editor. The AdminComments module also provides the option for any posted comment to be emailed to the other team members (selectable), and the notification email (which is customizable) allows the recipient to click directly to the editor for that page. This saved incalculable hours of work, and enhanced communication during the project, across this large data set.
    1 point
  23. Media Library uses pW image fields behind the scene. So in Setup->Fields you can search for the field which has the label 'MediaImages'. In the field settings, you can add 'svg' to the allowed file types. That should do the trick.
    1 point
×
×
  • Create New...