Popular Content

Showing content with the highest reputation since 01/23/2019 in all areas

  1. 30 points
    A module helping you to manage SEO related tasks like a boss! Automatically generates and maintains a XML sitemap from your pages. Includes a Fieldtype and Inputfield to manage sitemap settings and meta data for pages (title, description, opengraph, twitter etc.) Multi language support for the sitemap and meta data. Configure default values for meta data on template level and let pages inherit or overwrite them individually. Map existing fields to meta data, reducing the need to duplicate content. Check out the README on GitHub for more details, including usage instructions. The module is currently released as alpha and needs testing! Please report any issues on GitHub or in this forum thread, if you find time to give it a try Cheers
  2. 18 points
    We're finally launching a redesign of our website! Doesn't feel like it to us, but our previous design was already from 2013 https://ed-works.com/ We like to keep things simple, so the only third-party modules that we installed were Tracy debugger, Admin on steroids and Admin Theme Boss, which we tweaked a little bit to our taste. All in all, there's not much going on inside PW. Our main concern was to serve the frontend with responsive images with a close quality to the originals, and for this, it's important that PW allows us to use ImageMagick for resizing them. We also love to use PW's image tags to add classes to the images. In this case, we use them to display the images with three different sizes. We also had to change the templates to serve the projects to the homepage via Ajax. We hope you guys like our new baby Edit: I forgot to refer that we also changed our logo and tweaked our name to ED works.
  3. 16 points
    I'm probably a well-known nay-sayer around here already, but I'm still going to add my +1 to this discussion. I feel that (particularly when it comes to API design) one clean and consistent solution should be preferred, unless an alternative approach provides major benefits. Multiple options only tend to make things more fragmented and more difficult to grasp, and doubly so when you're a new user. As such, I'm always thrilled when an update enhances the core somehow (performance, security, scalability) or makes something new possible or more streamlined (in this update valid() and validate(), plus the whitelist feature) ... but I cringe a bit when a new way of doing the same old without (seemingly) notable benefits is added. Personally I wouldn't mind seeing the core get leaner in the future, perhaps in 4.x. There are, and always will be, features that should be added to the core (shameless plug: FiedltypeDecimal), but on the other hand alternatives without major benefits or major user base, and modules that may not be particularly often-used should, in my opinion, be stripped out. A module I've been working on recently has an "alias" feature (that isn't even that important to the module, to tell the truth), which was getting way out of hand. You could provide its arguments in five different formats, at least, which all required their own handler methods. I was working on this feature on Sunday (once again), and finally got fed up with it, stripped all those alternatives out and replaced them with one unified solution: callbacks. Sure, a bit of syntactic sugar might've been lost in the process, but I also got rid of probably 75% of the required code, and the documentation page is now actually readable. So, yeah – I know exactly what you're talking about
  4. 14 points
    ProcessWire 3.0.125 has several useful new $sanitizer methods and options, as well as new ways to access them directly from the $input API variable. This makes dealing with user input even easier than it was before. This version also brings updates to our translation functions and improvements to our API documentation: https://processwire.com/blog/posts/pw-3.0.125/
  5. 13 points
    It's been some time since I read the blog-post, but I really need to ask if we need the magic functions for the sanitizer, especially the grouped ones. They're hard to document, harder to be used for automated setups – where used sanitizers are aggregated by some coded means – compared to having them as parameters and I would say they're hardly simpler for manual usage over proper parameters. Personally I'd really vote for one clear way instead of having even more ways to do the same. For me there's also the reason that I find it way cleaner to work with data a.k.a. an array of sanitizer names vs. some magic naming, but that may just be me, but I think we really need to be aware of the backdraws of having to many options to do a thing in general.
  6. 12 points
    ElasticsearchFeeder This ElasticSearch module for ProcessWire will sync your page content to an ElasticSearch index, which provides you a convenient way to search it. Thanks to @jonathan-dart who created the first ES Module for PW and which influenced us a lot. Our approach was to create an a module where we can make for each template a flexible schema. You can define on you own which data ind which format should be transfered to ElasticSearch. Github Page: https://github.com/blue-tomato/ElasticsearchFeeder Module Page: https://modules.processwire.com/modules/elasticsearch-feeder/
  7. 12 points
    This week we take a closer look at the upcoming ProMailer module with a lot more details and screenshots. Plus an update on next steps with the new website and development schedule in the weeks ahead— https://processwire.com/blog/posts/promailer-preview/
  8. 10 points
    Afraid I also agree with everyone here - too many options which I'll never remember - I'll be sticking with the traditional approach - verbosity FTW I feel like we are on a very slippery slope here and once you go down, you can't climb back out because you might break someone's code. I have always trusted Ryan's instincts about this stuff in the past (or he has at least convinced me in the end), but this time I am not so sure. I hate to come across as critical or unappreciative because I know that even in my own relatively simple modules I sometimes get caught up in going with too many options, so I do realize it's a tricky balance. I think this is a super important point!!!
  9. 9 points
    I couldn't agree more - this was also my reaction with this latest version. I was thinking of mentioning this idea myself, but I love the fact that so far we've never really had any breaking changes in the evolution of PW. But unfortunately I agree that in v4 it's time to strip out lots of the experimental ideas that just haven't taken off. Think back to: $pages("template=basic-page") Has anyone here ever used that "variable as a method" approach for finding pages? I'd much rather spell it out with a get() or find() method. I know early on I was given some grief over all the shortcut methods in Tracy, but I think that's a different situation - those are temporary bits of code that don't stick around. For production stuff I like self documenting code over shortcuts that save a few keystrokes. I have no idea how it would be determined would would stay and what should be trimmed, but I think it's needed.
  10. 8 points
    Same feelings also. I think Teppo really said well how I felt also when read the latest post (and discussion about api examples). That kind of optimization is nice per project, but it is really confusing for a platform that we use to maintain and build hundreds of websites and applications with multiple developers. I'm all in for introducing breaking changes for 4.0. That would get rid of compiler also.
  11. 8 points
    I must agree as well with all those alternatives and multiple ways for the same thing.... should really stop. I lost track long time ago and 99.99% never use any of them and really don't care at all. It's utterly confusing and I completely don't understand the reason behind it. It makes it harder than it should be. So many things goes against it...
  12. 8 points
    +1 These magic functions are "hard" to decode when reading, at least it is a syntax no one is used to, so when people come across things like this they will just get confused. Generally speaking, it is great to have options but if more and more ways are implemented to do very same thing, then when one is looking at someone else's source code it will become harder and harder to decode it if it was written in "another dialect" of the ProcessWire API than one is used to. If this trend continues, reading ProcessWire source code will become harder than it should be.
  13. 8 points
    TemplaneEngineMustache This module adds Mustache as engine to the TemplateEngineFactory. Project page in Github: https://github.com/blue-tomato/TemplateEngineMustache/ Module Page: https://modules.processwire.com/modules/template-engine-mustache/
  14. 7 points
    I think there is still a big issue for the Functions API and variable API. As my understanding we are pushing the Functions API, however, the blog posts are still using the variable API in it's examples. I'm getting really mixed messages, are we pushing the functions API or not? I can see this starting to get really confusing for new people coming in to ProcessWire. I can see them building websites with a mix of Functions API and variable API with little understanding of the difference. For example, they may believe that to get page data you do <?= page('title') ?> but to sanatize the data you use <?= $sanitizer->text( page('title') ) ?> Honestly, I think we should just push one or the other. Sometimes using one and sometimes using the other is causing a lot of confusion. We run the risk of moving into WordPress territory where there are multiple ways of achieving the same thing. We will have people asking the questions, which one or which way is best. I just believe a decision needs to be made and run with it. At the moment, I have no idea which approach to use for my next project. I was edging towards the Functions API but I just want to use what is seen as the standard.
  15. 7 points
    Happy to announce that i just gave birth to another Processwire Website. This one has an event calendar, which was easy to build with Processwire. bridgesmusikverbindet.de
  16. 7 points
    Hello all, I've just pushed a rather alpha version of this module to a new branch on github. The localisation branch adds a few new features that might be of interest. Update default countries list (in English) with names from the country-list project. Use LibLocalisation (if installed) to localise country select lists in the Inputfield. Allow localisation of config and inputfield select lists to the language of the user's browser. Switch to storing ISOs in uppercase, can still handle stored lowercase ISO codes. Unify country list loading code. Detect changes to input address when saving page. Add compatibility with FormBuilder. You'll need to do a manual update from the new branch to try this out. Backup first please. I'm pushing this now in its alpha-state, as I've had a few health problems recently and don't want to hold off making this available any longer.
  17. 7 points
    It's not hard to implement yourself. Create a template with a PHP file where you: Parse and sanitize all relevant information from the call (page id, filename, width, height, other options/actions) Retrieve the page with the given id Instantiate a PagefilesManager object with the page as the parameter Retrieve the image by calling getFile on the PagefilesManager Call size() on the image with necessary parameters/options Call $session->redirect() with the url of the object return by the site() call Here's a quick&dirty implementation:
  18. 6 points
    Hey @ryan. I'm wondering if it would be possible to set up a repository for the new site, so that we could submit pull requests and report issues there? Personally I'd still like to suggest some usability / accessibility related changes and fixes, but currently that's a bit difficult to do – and it basically requires me reporting the issue, and then you having to figure out how to fix it for the site. If there was a repository, we could a) reliably keep track of issues that have been fixed or closed for other reasons (avoiding duplicate reports), b) submit changes so that you don't have to do everything yourself, and c) experiment with the site with ease. If the site has features that can't be made public, a repository containing partial site profile would of course do, but the best solution would imho be a full site that we can install locally, makes changes to, build, test for regressions, and so on. Or perhaps you could only share access on a case-by-case basis, since even GitHub now supports private repositories? Thanks for considering this!
  19. 6 points
    Thanks for the updates @ryan! Going forward, what do you think should be done about the sanitizer methods included in the PhpDoc of WireInputData? These sanitizer methods are also the basis for what gets an entry in the API documentation for WireInputData. As noted in this request the sanitizer methods included in the WireInputData PhpDoc were already out of date (i.e. incomplete). The new $santitizer methods added in 3.0.125 are also not included there. Do you think the PhpDoc of WireInputData should just aim to keep pace with new $sanitizer methods as they are added? Or now that multiple methods can be chained together... // access sanitizer on $input as method $q = $input->get->text50_entities('q'); ...in a way that couldn't be handled as lines in the PhpDoc, perhaps it would be better to drop the list of sanitizer methods and instead include some general note about how $sanitizer methods (with a link to the $sanitizer documentation) can be used/chained with $input?
  20. 6 points
    Troll Driven Developer
  21. 5 points
    Hey Peter - you can customize in the settings exactly how you want - site wide, template wide and even by page IIRC. However, you might want to check out: https://github.com/wanze/SeoMaestro @Wanze looks to have done a beautiful job on this. @GhostRider - you might also want to check that new module out.
  22. 5 points
    Hi @ryan, could you please add some more detailed documentation for the $page->render() method to the API docs? Currently the details are quite minimal (the method doesn't have it's own page but just a short entry on the $page documentation) and doesn't cover all the options that you describe in this post: I guess the docs for $page->render() need to somehow pull in the PhpDoc comments from PageRender::renderPage().
  23. 5 points
    Quick update: version 2.0.0 of this module is now available via GitHub. This version includes updated RedBeanPHP library, various new config settings (including the ability to disable automatic setup of RedBeanPHP, and an option for choosing one of the trimmed down library versions with support for specific database type only), and various other updates to the module. I've also dropped support for PW 2.x and PHP < 5.4, and updated module requirements accordingly. For pre-3.x or pre-PHP 5.4 users the legacy branch still contains old version of the module.
  24. 5 points
    @adrian and @thetuningspoon thanks! Needed some tweakage as FieldsetPage, although based on Repeater, only has one page, not a number of child pages under the repeater page, in admin. Got it working with: /** * Creates a fieldsetpage field with associated fieldgroup, template, and page * * @param string $repeaterName The name of your fieldsetpage field * @param string $repeaterFields List of field names to add to the fieldsetpage, separated by spaces * @param string $repeaterLabel The label for your fieldsetpage * @param string $repeaterTags Tags for the fieldsetpage field * @return Returns the new FeildsetPage field * */ public function createFieldsetPage($repeaterName,$repeaterFields,$repeaterLabel,$repeaterTags) { $fieldsArray = explode(' ',$repeaterFields); $f = new Field(); $f->type = $this->modules->get("FieldtypeFieldsetPage"); $f->name = $repeaterName; $f->label = $repeaterLabel; $f->tags = $repeaterTags; $f->save(); //Create fieldgroup $repeaterFg = new Fieldgroup(); $repeaterFg->name = "repeater_$repeaterName"; //Add fields to fieldgroup foreach($fieldsArray as $field) { $repeaterFg->append($this->fields->get($field)); } $repeaterFg->save(); //Create template $repeaterT = new Template(); $repeaterT->name = "repeater_$repeaterName"; $repeaterT->flags = 8; $repeaterT->noChildren = 1; $repeaterT->noParents = 1; $repeaterT->noGlobal = 1; $repeaterT->slashUrls = 1; $repeaterT->fieldgroup = $repeaterFg; $repeaterT->save(); // Create the admin/repeaters page (different to standard repeaters) // add more options to the page if you prefer $repeaterPage = new Page(); $repeaterPage->of(false); $repeaterPage->template = 'admin'; $repeaterPage->name = "for-field-" . $f->id; $repeaterPage->title = $f->name; $repeaterPage->parent_id = $this->pages->get("path=/admin/repeaters/"); $this->pages->save($repeaterPage); // Associate the FieldsetPage field with the new admin/repeater page $f->parent_id = $this->pages->get("name=$repeaterPage")->id; $f->template_id = $repeaterT->id; //Now, add the fields directly to the FieldsetPage field foreach($fieldsArray as $field) { $f->repeaterFields = $this->fields->get($field); } $f->save(); return $f; } and example usage: $fsPageName = "fspage_widget"; $fsPageFields = "widget_title"; $fsPageLabel = _("My Widget"); $fsPageTags = "widget"; $f = $this->createFieldsetPage($fsPageName,$fsPageFields,$fsPageLabel,$fsPageTags);
  25. 5 points
    <div id="result">Ajax</div> <script type="text/javascript"> $('#result').click(function () { var ajaxUrl = "https://example.com/ajax-page-name"; //not template path $.ajax({ type: "GET", url: ajaxUrl, success : function(data){ var markup = $(data).find('#result'); $('#result').html(markup); } }); }); </script> You need to call the URL of the page itself, not its template path.
  • From Twitter

    • New post: This week we take a look at what’s in ProcessWire 3.0.126 which focuses largely on resolving issue reports, but also includes a handy new Page if() method— processwire.com/blog/posts/pw-…
      15 February 2019
    • New post: ProcessWire 3.0.125 has several useful new Sanitizer methods & options, plus new ways to access them directly from the Input API variable. This makes handling user input even easier than before. Plus updates to our i18n functions & API docs— processwire.com/blog/posts/pw-…
      25 January 2019
    • New post: In this week’s post, we’ll take a look a look at the new website and focus on some parts of it and how they were built. Then we’ll dive into the latest version of ProcessWire on the dev branch, version 3.0.124— processwire.com/blog/posts/pw-…
      11 January 2019