Wanze

PW-Moderators
  • Content Count

    1,052
  • Joined

  • Last visited

  • Days Won

    10

Wanze last won the day on February 6

Wanze had the most liked content!

Community Reputation

1,455 Excellent

1 Follower

About Wanze

  • Rank
    Hero Member
  • Birthday 06/19/1986

Profile Information

  • Gender
    Male
  • Location
    Bern, Switzerland

Recent Profile Visitors

12,343 profile views
  1. Wanze

    A lot of the rules protect direct HTTP access to sensitive files such as config, logs, sessions, templates... most other frameworks and CMS's keep this sensitive stuff out of the web root, so HTTP based access is not possible by design. In ProcessWire, the root directory equals the web root directory, so we need to protect access to these files. On the plus side, ProcessWire can be installed on hostings that do not allow to change the web root. The drawbacks are that we need to be extra careful that nobody can access sensitive/private files.
  2. Wanze

    Version 0.5.0 fixes two issues, please update: Fix wrong url in the <link rel="alternate" hreflang="x-default"> meta tag. Fix date formatting for the lastmod property in the XML sitemap. Cheers
  3. Wanze

    Actually I wanted to ask you if you would like to develop the 2.x version of TemplateEngineSmarty, and if you like, maintain the project? The implementation itself is really easy, you can basically copy + past from Twig and tweak/change things for Smarty. I only use Twig these days, so I might miss some useful/important stuff for Smarty. What do you think?
  4. Hi folks! I release a now major version 2.x of the TemplateEngineTwig module. This version is compatible with the newly released 2.x version of the TemplateEngineFactory (more details in this post). Note that the new version of the TemplateEngineFactory might break backwards compatibility, depending on the feature usage. Read the following guide on how to update, before you do so. So what's new in version 2.0? Updated Twig to 2.6.2 Added a setting to enable debug mode, independently from ProcessWire's debug mode. The Twig_Extension_Debug is automatically loaded if debug mode is active. Added unit tests and Travis for CI. Note that this version no longer bundles Twig. Therefore, installation is only possible with Composer. This makes sure that the 3rd party dependencies are handled correctly. If you update from 1.x to 2.x, please let me know any issues you have. If you do not update: The 1.x version of the module will stay available on the 1.x branch. For a new project, definitely pick version 2.x! Cheers
  5. Wanze

    Hi folks! I just released a new major (2.x) version of the module. Important things first: This version includes backwards compatibility breaks. At the moment, only Twig and the bundled ProcessWire engine work with the 2.0 version. I will now contact maintainers that implemented other engines (Pug, Jade etc.) and ask them to release a 2.x version as well. The 1.x version of the module is still available on the 1.x branch and continues to exist. So why a version 2.x? Basically it's the same concept, but done in the right way. The rendering via template engine is now integrated correctly into Page::render(). You can call the render() method on any page, and the module will render it via template engine. In version 1.x, this is only true for the current page. Automatic page rendering is now optional, you can use the module to only integrate a template engine, without hooking into Page::render at all. There are settings to enable/disable the automatic page rendering for templates. Because there might be templates where Page::render should not be replaced. The module provides hooks to customize it for your needs. I wrote a bunch of unit tests and use Travis for CI. Problems like "the 404 page is not displayed if a Wire404Exception is thrown in a controller" are now tested properly. I am writing a documentation on everything, you can read it here: https://github.com/wanze/TemplateEngineFactory/blob/master/DOCUMENTATION.md One important part is how to update from 1.x to 2.x. Depending on the feature usage of the module, this might involve some manual update steps, because the public API changed. If you try to update, please let me know about any issues you are encountering, so that we can add them to the documentation. Don't worry, you do not have to update, as the 1.x version continues to exist. For a new project, definitely start with 2.x! Last but not least, modules providing template engines must be updated too, but this should be quite easy. For Twig, I decided to support installations only via Composer, and I think that this should be the way to go for the other modules. 3rd party dependencies must be manageable in a reliable way, and Composer is the right tool for this job. Cheers
  6. Wanze

    LostKobrakai is right. Laravel's dependency injection container automagically resolves type-hinted objects, see: https://laravel.com/docs/5.7/container#automatic-injection
  7. Wanze

    @csaeum Are you sure that the name of your Seo Maestro field is "seo"? Did you create the field? Looks like the $page is not aware of it. Cheers
  8. Wanze

    Version 0.4.0 renders some common meta tags not managed by the fieldtype, and fixes a couple of issues reported. Thanks! See https://github.com/wanze/SeoMaestro/releases/tag/v0.4.0 for more information. Cheers
  9. Wanze

    Thanks @B3ta I think that the decision where the Seo Maestro field is rendered should be left to the user. And it should be done in the same way it works for all fields: By editing the template and placing the field. Display it in a new tab? Create an InputfieldFieldsetOpen and wrap the field. But maybe the content editor only needs to see meta title and description - then it's not worth to create a new tab. I understand that it requires some manual work to add the field to all templates, but I don't think it is the responsibility of the module to do this. There are other solutions like the Migrations module, which can do this task in a few milliseconds. For the project I built this module, it took me 10 minutes to write a migration that creates and configures the field, adds it to all templates, tweaks the settings per template and also wraps it in a tab. No need to do this by hand if I deploy to production. Cheers
  10. Wanze

    It's possible! From the Sanitizer class description: Cheers:)
  11. Wanze

    Version 0.3.0 should fix problems on single language installations. I will update Travis CI to run the test suite on two installation profiles (single and multi language). This is possible, just wrap the Seo Maestro field in an InputFieldsetOpen.
  12. Wanze

    Just noticed that the module does not work correctly on single language installations, as I always tested on multi language setups. Should be easy to fix though, I know what the problem is Cannot fix it today, so if you are testing, you might want to test with multiple languages. Sorry for this, I obviously should have tested this myself. Cheers!
  13. Wanze

    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
  14. @tiefenbacher_bluetomato You can us the following hook to extend the smarty object: wire()->addHookAfter('TemplateEngineSmarty::initSmarty', function (HookEvent $event) { $smarty = $event->arguments('smarty'); // Register your function here });
  15. Wanze

    @Sten In home.twig, the block engagement block is nested inside the home block. In engagement.twig, this is not the case. Does it work if you either move it out of the home block in your parent template; or recreate the nested block structure in engagement.twig.