Jump to content

Recommended Posts

55 minutes ago, bernhard said:

What if I have some piece of code that is needed on several templates (controllers are out) that has some business logic?

I use Utility Classes in these cases 🙂

Or you could maybe use PHP traits and use them in the controller classes?

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

Thx @Craig I did read about them and then forgot that they exist 🙂 Sounds like a good usecase for them! So I'd build a utility class "LocalTime" and then call LocalTime::local("d.m.Y H:i:s")? Sounds like a good solution!

Share this post


Link to post
Share on other sites

Something like that, yes! Use it in controllers and/or components as and when you need to 🙂 

If I needed more, or different, date or time functions than just "local()", I'd maybe call it "DateTimeHelper" and have various functions inside all related to date/time calculations or formatting, as I like to group similar things together.

I also like to use these for getting pages for sections of the site that are repeated in different places - like news or events - and have functions like findRecent() or findByCategory(), which can accept parameters for limit, category, etc. These can then be used on homepages, sidebars, main news/events pages, or RSS. The functions interpret the parameters, set some defaults (parent, template), and make some pages()->find() calls to return the requested pages.

Share this post


Link to post
Share on other sites
16 minutes ago, Craig said:

If I needed more, or different, date or time functions than just "local()", I'd maybe call it "DateTimeHelper" and have various functions inside all related to date/time calculations or formatting, as I like to group similar things together.

Yeah, but that sounds like a good usecase for a regular PW module as this could likely also be useful for other projects 🙂 

Share this post


Link to post
Share on other sites
2 hours ago, bernhard said:

that sounds like a good usecase for a regular PW module

Like RockDatetime? 😉 Yeah - if it's mostly site-specific, I'd put it in a utility class. Multiple sites - probably a module 🙂 

  • Like 1

Share this post


Link to post
Share on other sites

Heads-up! Wireframe 0.12.0 is now the latest master version. This is a pretty big update (in both lines of code, as well as features), so I'd recommend testing carefully after updating. The biggest parts are implemented as a companion module Wireframe API, but there are quite a few changes and updates for the main module as well:

### Added
- Support for named arguments when using `Wireframe::component($component_name, $args)`.
- JSON API. See comments in the WireframeAPI module file for more details.
- New Page methods Page::getController() and Page::setController().
- Module config screen provides support for creating directories corresponding to configured Wireframe URLs, assuming that they were provided as relative paths.

### Changed
- Wireframe::setView() accepts optional view name as an argument.
- View::setController() accepts Controller name (string) in addition to Controller class instance or null.
- When Controller is instantiated, it no longer overrides the Controller property of the related View instance.

### Fixed
- Wireframe::partial() now works as expected for partial names with file ext included (partial_name.php etc.)
- Wireframe::partial() prevents 2 or more dots in partial name, just in case (directory traversal is not intended).

 

  • Like 4

Share this post


Link to post
Share on other sites

@teppo just a short heads-up 🙂

I'm building my new design mostly of components. The homepage view looks like this:

<?php namespace ProcessWire;
echo Wireframe::component("Header");
echo Wireframe::component("Search");
echo Wireframe::component("Slider");
echo Wireframe::component("Welcome");
echo Wireframe::component("Visions");
echo Wireframe::component("News");
echo Wireframe::component("Quotes");
echo Wireframe::component("Newsletter");
echo Wireframe::component("Partner");
echo Wireframe::component("Footer");

This is pseudocode of the Welcome component:

<?php namespace Wireframe\Component;
class Welcome extends \Wireframe\Component {
  public function __construct() {
    $this->setBg();
    $this->setEmblem();
  }
  private function setBg() {
    $this->bg = null;
    try {
      $item = $this->wire->gg->home()->get(HomePage::field_slider)->first();
      $img = $item->get(Slideritem::field_img);
      $this->bg = $item->imgUrl($img);
    } catch (\Throwable $th) {
      $this->log($th->getMessage());
    }
  }

  private function setEmblem() {
    $this->emblem = null;
    $img = $this->wire->gg->settings()->get(HomePage::field_emblem_white);
    if(!$img) return;
    $this->emblem = "<img class='tm-emblem uk-margin-large-left' src='{$img->maxHeight(100)->url}' uk-svg>";
  }
}

While this is really not a big deal, I wonder if it would be possible to get rid of the bypass of having to set component properties manually and have them listen to getMyprop() methods automatically?

Maybe they could even do a try catch automatically and log the error silently on production and throw an exception on dev?

The component would then become a lot cleaner:

<?php namespace Wireframe\Component;
class Welcome extends \Wireframe\Component {
  
  public function getBg() {
    $item = $this->wire->gg->home()->get(HomePage::field_slider)->first();
    $img = $item->get(Slideritem::field_img);
    return $item->imgUrl($img);
  }

  public function getEmblem() {
    $img = $this->wire->gg->settings()->get(HomePage::field_emblem_white);
    if(!$img) return;
    return "<img class='tm-emblem uk-margin-large-left' src='{$img->maxHeight(100)->url}' uk-svg>";
  }
}

Thx

Share this post


Link to post
Share on other sites

Hey @bernhard!

I believe this is the same concept that was discussed earlier, i.e. having direct access to public component class methods from the component view? If so, I'll be sure to dedicate this some thought soon, and if it does indeed seem like a good idea, I'll try to get it implemented for the next release (after 0.13.0, which went live a few minutes ago) 🙂

I'm leaning towards adding this feature, but the added complexity still worries me. Just providing access to public methods of the class is one thing, but if I go on and add that, I pretty much have to add at least the (runtime) caching support currently provided by the controller to make sure that devs don't accidentally step into a really nasty performance trap. And if I add this, for the sake of consistency I have to consider also adding support for persistent caching, method aliases, disabled methods, and a few other things.

Anyway, this is just me thinking out loud. I'll see what I can do about this in the near future 🙂

I've added your idea about catching errors and logging them to my todo list. Not entirely sure about this one yet, but it's definitely worth thinking through.

  • Thanks 1

Share this post


Link to post
Share on other sites

Wireframe 0.13.0 went live a while ago.

This version introduces only one new feature: variables sent by controller to the view — as well as $partials and $placeholders — now work as-is while rendering fields (= in field templates). In previous versions these were accessible via the $view API variable, which didn't feel quite as intuitive. This required a new hook so there's a bit of added overhead, but at the same time various optimizations were made here and there, so this is unlikely to be noticeable.

One thing to note is that this version contains a few breaking changes, though I'd be a little surprised if they affected any real sites: some Wireframe methods were converted from public to protected (these were never really intended as part of the "public API"), and the first argument for Controller class constructor method is no longer an instance of ProcessWire (this wasn't actually necessary).

Here's the full changelog:

### Added
- New hook makes View properties directly accessible in TemplateFiles (e.g. when rendering field templates)

### Changed
- Wireframe::getController() is now a public method that can return current Controller instance, the Controller instance for provided page, or a Controller instance for provided Page and template name.
- Visibility of following methods was changed from public to protected: Wireframe::___checkRedirects(), Wireframe::___redirect(), Wireframe::___initView(), Wireframe::___initController(), \Wireframe\Config::getCreateDirectoriesField().
- Controller class implementation was streamlined: new objects are wired using the native wire() function, and thus Controller constructors no longer require the ProcessWire instance as an argument.
- Wireframe no longer caches partials unnecessarily, plus new Partial objects are automatically wired.
- Various minor optimizations, some code cleanup, and a few improvements to comments.

 

Share this post


Link to post
Share on other sites
57 minutes ago, teppo said:

I believe this is the same concept that was discussed earlier, i.e. having direct access to public component class methods from the component view?

Yes 🙂 Just wanted to share my experience so far and point out that I still think it would be nice to have.

1 hour ago, teppo said:

I'm leaning towards adding this feature, but the added complexity still worries me. Just providing access to public methods of the class is one thing, but if I go on and add that, I pretty much have to add at least the (runtime) caching support currently provided by the controller to make sure that devs don't accidentally step into a really nasty performance trap. And if I add this, for the sake of consistency I have to consider also adding support for persistent caching, method aliases, disabled methods, and a few other things.

No idea about the complexity behind, so of course it's better to think twice 🙂 Also no idea about Wireframes caching yet. I'll throw everything to ProCache in the end 🙂 

---

What I wondered during the last days of working with Wireframe is if all those different concepts (controllers, views, components, partials) are really necessare or make sense? I found myself rewriting some partials to components because I added some business logic. Now I have only one partial left 😄 Maybe I'll have to add others, maybe not. I don't know yet. But I wonder if it wouldn't be easier to have just one concept for all blocks? So everything would be a component and work the same. I understand that Controllers are tied to the template of the viewed page, but couldn't that also be handled by the component? I'm not sure I like that all my content is split up in different "types" and it's not instantly clear where I have to look for markup portion xy...

Maybe that feeling is even stronger because I'm using custom page classes a lot. So there's not really a need for controllers at all, because my pages are already some kind of controller?! But even if that was one part of the "problem", the other part still remains: Why partials + component? Wouldn't it be easier to merge them to one single concept that always works the same? I know, that would bring in lots of breaking changes, but I'd be interested why you built the module like that. Maybe there is a good reason for that I just didn't realize until now 🙂 

Please don't take this as criticism at all. Just trying to find the right way for doing the frontend part of my projects 🙂 

  • Like 2

Share this post


Link to post
Share on other sites
3 hours ago, bernhard said:

Why partials + component? Wouldn't it be easier to merge them to one single concept that always works the same? I know, that would bring in lots of breaking changes, but I'd be interested why you built the module like that. Maybe there is a good reason for that I just didn't realize until now 🙂 

As I get it, partials came first (there were no components at the time). And components were added later due to user requests. I think too that only one (the components)) should stay in the future. But I may be missing something.

  • Like 2

Share this post


Link to post
Share on other sites
6 hours ago, bernhard said:

Why partials + component? Wouldn't it be easier to merge them to one single concept that always works the same? I know, that would bring in lots of breaking changes, but I'd be interested why you built the module like that. Maybe there is a good reason for that I just didn't realize until now 🙂 

I'm going to start from the end, because this is the easy part (maybe) 😅

First of all, all the main concepts found from Wireframe have been around, in one form or another, for about a decade. Wireframe (the module) was developed a couple of years ago, and components were added about six months ago. Partials have been around since the very beginning, while components are a brand new thing.

As for "should there be both partials and components", this is a good question going forward:

  • Components are more versatile, but also more complex. There's a class (for business logic) and one or more views (for markup).
  • Partials are a lot simpler. Even though you can pass params to partials and arrange them in directories by type or whatever, they are essentially just individual include files.

In my typical project there's a need for both: by default I prefer the simplicity of partials, but if I really need to do something more complex on a per-element basis (justifying the mental and technical overhead of the class based approach), I go with a component instead. Heck, in one recent project I even surprised myself by using components within components. Not what I'd call an "easy to grasp setup" (which is always something that I try to emphasize in my work), but it gets the job done and was fun to work on.

Will components and partials eventually merge into one? I don't know — maybe, maybe not. For the time being I quite like having them both around. In my projects they tend to solve different problems, even though they could be used interchangeably 🙂

6 hours ago, bernhard said:

Maybe that feeling is even stronger because I'm using custom page classes a lot. So there's not really a need for controllers at all, because my pages are already some kind of controller?!

Oh, I'm sure that this makes a huge difference!

As I've mentioned before I haven't really used custom Page classes, because — for my use cases — controllers provide same benefits, and then some more. Nevertheless, had custom page classes existed when I started working on Wireframe, there's a good chance that I would've taken an entirely different route 🙂

6 hours ago, bernhard said:

What I wondered during the last days of working with Wireframe is if all those different concepts (controllers, views, components, partials) are really necessare or make sense? I found myself rewriting some partials to components because I added some business logic. Now I have only one partial left 😄 Maybe I'll have to add others, maybe not. I don't know yet. But I wonder if it wouldn't be easier to have just one concept for all blocks? So everything would be a component and work the same. I understand that Controllers are tied to the template of the viewed page, but couldn't that also be handled by the component? I'm not sure I like that all my content is split up in different "types" and it's not instantly clear where I have to look for markup portion xy...

I might've already touched some of the same topics earlier — particularly the one about having more than one type of object in Wireframe — but a few additional notes on this:

  • You don't have to use anything you don't need. Layouts, views, and controllers are all optional. In many of my projects there's one layout, a bunch of views (often much fewer than there are viewable templates, since many templates are so simple that the layout file takes care of all the markup), and a few controllers (just for those templates that require something "more complex" behind the scenes; news or event containers / lists, page search, etc.
  • The "everything is a component" approach is quite possible with Wireframe, though that was never really something I intended (or expected, to be honest!) The roots of Wireframe are in the MVC architecture, and that's where controllers, view, and model (which in this case is actually ProcessWire) come in. Components were intended as something that you can use to "fill in the gaps"; a bit like utility classes, for that matter.

When you say that "Controllers are tied to the template of the viewed page", that's actually not entirely true: by default Wireframe will indeed only know that for a Page using the "basic-page" template it should check if a controller class called BasicPageController exists... but you can also make multiple pages share a single controller, change the controller on the fly, etc. Much of this is pretty new and I'm still experimenting with it, but I have high hopes that it will become even more useful in the future.

As for the "couldn't that also be handled by the component" part: controllers do certain things that components don't, there's always exactly one controller active for a specific page at any given time, and these two work in a different context. The context of a controller is a page render request, while the context of a component is much smaller — essentially the subset of the request that it has been provided with. In my opinion it's best to keep them as separate concepts — at least for the time being — though once again who knows what will happen in the future 🤷‍♂️

6 hours ago, bernhard said:

Please don't take this as criticism at all. Just trying to find the right way for doing the frontend part of my projects 🙂 

I hope I don't really need to say this, but... feedback, comments, and (constructive) criticism is always welcome. I can't promise that I'll agree with all of it, but I'm happy to hear others' experiences nevertheless 👍😅

--

I'm pretty sure that you've seen this already, but I've got a couple of site profiles online — https://github.com/wireframe-framework/site-wireframe-docs and https://github.com/wireframe-framework/site-wireframe-boilerplate. These are a bit dated by now (neither uses components, for an example), but they may provide some insight into the way I personally use Wireframe.

I've been really looking forward to revisiting the weekly.pw website and sharing that as well, hopefully something I can get done before the end of the year. This site is also really, really dated (both visually and feature wise), and I'd also like to show off some of the new stuff in Wireframe 🙂

  • Like 4

Share this post


Link to post
Share on other sites

Changelog for Wireframe 0.14.0:

### Added
- New ComponentView class, as well as the ability for component views to access Component class public methods as properties, in the same way view files and layouts can access Controller class public methods.

### Changed
- Hook related code moved from Wireframe module to separate Hooks class.
- Accessing public class methods as properties in view files were moved into new trait MethodPropsTrait. This is used internally by Controller and Component classes.
- Some minor improvements related to dependency injection within Wireframe objects (and ProcessWire objects instantiated by Wireframe.)

@bernhard, what you suggested here...

On 8/28/2020 at 1:09 PM, bernhard said:

While this is really not a big deal, I wonder if it would be possible to get rid of the bypass of having to set component properties manually and have them listen to getMyprop() methods automatically?

... is now doable. The way it works is just like with Controllers (this functionality is provided by a new shared trait behind the scenes):

<?php
// component class
namespace Wireframe\Component;
class Test extends \Wireframe\Component {
	public function hello() {
		return 'world';
	}
}

// component view
hello <?= $this->hello ?>

 

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

Hey @teppo,

first off thank you for creating this module - really love the approach. I recently took over a processwire project, which pretty much consisted of php/html spaghetti-code. Being an processwire greenhorn (having worked with Typo3 & WP up until now), this drove me crazy - but your module definitely helped me to bring some structure into that chaos. ^^

Anyway, long story short: 
I was wondering, if i can also use blade or twig templates for the view part of a component? It works flawlessly for all my template & partial views, but i am somehow having issues with components. Always running into something like this, although an default.blade.php view exists for that component:

Method Wireframe\Component\SocialWidget::__toString() must not throw an exception, caught InvalidArgumentException: View [SocialWidget.default] not found.

I might also just be missing something, as i only have an intermediate knowledge of php.

Thanks in advance!

  • Like 1

Share this post


Link to post
Share on other sites

@mlfct, what version of the module do you use? I recently changed a few things that might've been related, so there's a chance that it's fixed already.

That being said, I don't use twig/blade myself, so if the issue still exists in the latest version, I'll have to dig in to see what's going on.

Also, thanks! I'm really glad to hear that uou've found Wireframe useful 🙂

  • Like 1

Share this post


Link to post
Share on other sites
Quote

what version of the module do you use? I recently changed a few things that might've been related, so there's a chance that it's fixed already.

I've been using 0.14.0 from the your repo master branch and mauricius' blade renderer implementation. 

  • Like 1

Share this post


Link to post
Share on other sites

Thanks, @mlfct. This seems to be related to the WireframeRendererBlade module — I've opened an issue for it here: https://github.com/mauricius/WireframeRendererBlade/issues/1. Simply put the Blade renderer appears to expect component views to be found from /site/templates/views/[component name]/[view name].blade.php, while Wireframe expects them to be at /site/templates/components/[component name]/[view name].blade.php 🙂

I would recommend keeping tabs on that issue if you want to use Blade. Twig implementation shouldn't have the same issue, though.

  • Like 1

Share this post


Link to post
Share on other sites
8 hours ago, teppo said:

Thanks, @mlfct. This seems to be related to the WireframeRendererBlade module — I've opened an issue for it here: https://github.com/mauricius/WireframeRendererBlade/issues/1.

This issue is resolved in the latest version of WireframeRendererBlade. Let me know if the problem persists, though 🙂

  • Like 2

Share this post


Link to post
Share on other sites

@teppo was already following up on the github issue. works perfectly now - thanks for pinpointing the issue and chiming in with mauricius!

  • Like 2

Share this post


Link to post
Share on other sites

Just a quick heads-up that Wireframe 0.17.0 went live a few hours ago. Versions 0.15.0 .. 0.17.0 mostly included behind-the-scenes improvements and refactoring for existing features, so didn't think these were particularly interesting. Full changelog can be found from CHANGELOG, as usual.

Probably the one and only feature that might come in handy during development is the shortcut method for defining view template and view at the same time (to use a view from a specific template instead of current one), added in 0.16.0:

<?php
// find blog posts and render them using the "list_item" view of the "article" template:
?>
<ul>
	<?php foreach ($pages->find('template=blog-post') as $post): ?>
		<?= $post->setView('article/list_item')->render() ?>
	<?php endforeach; ?>
</ul>

On a loosely related note I've removed the "WIP" label from the topic of this thread, and am considering submitting the module to the modules directory. I think it's long overdue, really 🙂

  • Like 6

Share this post


Link to post
Share on other sites

Hi @teppo

any ideas why I'm getting this error on a fresh install?

Notice: Trying to get property 'paths' of non-object in C:\laragon\www\micropage\site\modules\Wireframe\lib\Config.php on line 163

Warning: Creating default object from empty value in C:\laragon\www\micropage\site\modules\Wireframe\lib\Config.php on line 173

Also the directories look weird. The regular directories have not been created, but they are also not listed on the settings page:

XtdR5fY.png

  • Like 1

Share this post


Link to post
Share on other sites

Hey @bernhard! Thanks for reporting this.

The latter problem is connected to the first one. Config screen asks the main module for the paths object, but due to a recent change this wasn't available. This is fixed now in the latest version of the module (0.17.1).

  • Thanks 1

Share this post


Link to post
Share on other sites

New release — 0.18. This version adds Tracy panel for Wireframe:

wireframe-tracy-panel.thumb.png.1b43985627716b20eeb0d3fce8a5b390.png

Obviously the panel will only show up if both Wireframe and Tracy are installed. Currently it displays some content I thought could be useful while developing, but I'm open for suggestions. Tracy doesn't really enforce any rules here, so in the future the panel could also provide interactive developer tools or something along those lines... just not sure yet what would be useful 🙂

Thanks to @adrian for adding support for custom panels!

  • Like 6

Share this post


Link to post
Share on other sites

Hi @teppo - getting this on PHP 8

Fatal error: ProcessWire\Wireframe::__set(): Return type must be void when declared in /site/modules/Wireframe/Wireframe.module.php on line 842

  • Like 1

Share this post


Link to post
Share on other sites

Thanks for reporting this, @adrian! The issue is clear (return types for magic methods are now enforced by PHP) and the fix is simple, but I'll have to set up a test environment to make sure it really fixes the error... and doesn't introduce any new issues 🙂

I'll get back to this ASAP.

Edit: the dev branch at https://github.com/wireframe-framework/Wireframe/tree/dev now contains a fix for this, if you'd like to give it a try. I'll have to test this properly before merging to master.

Edited by teppo
  • Like 1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By joshua
      ---
      Module Directory: https://modules.processwire.com/modules/privacy-wire/
      Github: https://github.com/blaueQuelle/privacywire/
      Packagist:https://packagist.org/packages/blauequelle/privacywire
      Module Class Name: PrivacyWire
      Changelog: https://github.com/blaueQuelle/privacywire/blob/master/Changelog.md
      ---
      This module is (yet another) way for implementing a cookie management solution.
      Of course there are several other possibilities:
      - https://processwire.com/talk/topic/22920-klaro-cookie-consent-manager/
      - https://github.com/webmanufaktur/CookieManagementBanner
      - https://github.com/johannesdachsel/cookiemonster
      - https://www.oiljs.org/
      - ... and so on ...
      In this module you can configure which kind of cookie categories you want to manage:

      You can also enable the support for respecting the Do-Not-Track (DNT) header to don't annoy users, who already decided for all their browsing experience.
      Currently there are four possible cookie groups:
      - Necessary (always enabled)
      - Functional
      - Statistics
      - Marketing
      - External Media
      All groups can be renamed, so feel free to use other cookie group names. I just haven't found a way to implement a "repeater like" field as configurable module field ...
      When you want to load specific scripts ( like Google Analytics, Google Maps, ...) only after the user's content to this specific category of cookies, just use the following script syntax:
      <script type="text/plain" data-type="text/javascript" data-category="statistics" data-src="/path/to/your/statistic/script.js"></script> <script type="text/plain" data-type="text/javascript" data-category="marketing" data-src="/path/to/your/mareketing/script.js"></script> <script type="text/plain" data-type="text/javascript" data-category="external_media" data-src="/path/to/your/external-media/script.js"></script> <script type="text/plain" data-type="text/javascript" data-category="marketing">console.log("Inline scripts are also working!");</script> The data-attributes (data-type and data-category) are required to get recognized by PrivacyWire. the data-attributes are giving hints, how the script shall be loaded, if the data-category is within the cookie consents of the user. These scripts are loaded asynchronously after the user made the decision.
      If you want to give the users the possibility to change their consent, you can use the following Textformatter:
      [[privacywire-choose-cookies]] It's planned to add also other Textformatters to opt-out of specific cookie groups or delete the whole consent cookie.
      You can also add a custom link to output the banner again with a link / button with following class:
      <a href="#" class="privacywire-show-options">Show Cookie Options</a> <button class="privacywire-show-options">Show Cookie Options</button>  
      I would love to hear your feedback 🙂
      CHANGELOG
      You can find the always up-to-date changelog file here.
    • By joshua
      As we often use Matomo (former known as Piwik) instead of Google Analytics we wanted to embed Matomo not only in the template code but also via the ProcessWire backend.
      That's why I developed a tiny module for the implementation.
      The module provides the possibility to connect to an existing Matomo installation with the classical site tracking and also via the Matomo Tag Manager.
      If you have also PrivacyWire installed, you can tell MatomoWire to only load the script, if the user has accepted cookies via PrivacyWire.
      To offer an Opt-Out solution you can choose between the simple Opt-Out iFrame, delivered by your Matomo installation, or a button to choose cookies via PrivacyWire.
      You'll find the module both in the module directory and via github:
      ProcessWire Module Directory MatomoWire @ GitHub MatomoWire @ Packagist ->installable via composer require blauequelle/matomowire I'm looking forward to hear your feedback!


    • By Robin S
      If your module has a lot of config fields you might want to divide them into groups inside a tabbed interface. Here is a demonstration module showing how this can be done.
      https://github.com/Toutouwai/ModuleConfigTabs

      Thanks to @kixe for providing my starting point in this forum topic.
    • By FireWire
      Hello community!

      I want to share a new module I've been working on that I think could be a big boost for multi-language ProcessWire sites.

      Some background, I was looking for a way for our company website to be efficiently translated as working with human translators was pretty laborious and a lack of updating content created a divergence between languages. I, and several other devs here, have talked about translation integrations and have recognized the power that DeepL has. DeepL is an AI deep learning powered service that delivers translation quality beyond any automated service available. After access to the API was opened up to the US, I built Fluency, a DeepL translation integration for ProcessWire.
      Fluency brings automated translation to every multi-language field in the admin, and also provides a translation tool allowing the user to translate their text to any language without it being inside a template's field. With Fluency you can:
      Translate any plain textarea or text input Translate any CKEditor content (yes, with markup) Translate page names for fully localized URLs on every page Translate your in-template translation function wrapped strings Translate modules DeepL offers translations to the following languages: English (US), English (UK), German, French, Spanish, Portuguese (EU), Portuguese (Brazil, Italian, Dutch, Polish, Russian, Japanese, Chinese (Simplified)
      Installation and usage is completely plug and play. Whether you're building a new multi-language site, need to update a site to multi-language, or simply want to stop manually translating a site and make any language a one-click deal, it could not be easier to do it. Fluency works by having you match the languages configured in ProcessWIre to DeepL's. You can have your site translating to any or all of the languages DeepL translates to in minutes (quite literally).
      Let's break out the screenshots...
      When the default language tab is shown, a message is displayed to let users know that translation is available. Clicking on each tab shows a link that says "Translate from English". Clicking it shows an animated overlay with the word "Translating..." cycling through each language and a light gradient shift. Have a CKEditor field? All good. Fluency will translated it and use DeepL's ability to translate text within HTML tags. CKEditor fields can be translated as easily and accurately as text/textarea fields.

      Repeaters and AJAX created fields also have translation enabled thanks to a JavaScript MutationObserver that searches for multi-language fields and adds translation as they're inserted into the DOM. If there's a multi-language field on the page, it will have translation added.

      Same goes for image description fields. Multi-language SEO friendly images are good to go.

      Creating a new page from one of your templates? Translate your title, and also translate your page name for native language URLs. (Not available for Russian, Chinese, or Japanese languages due to URL limitations). These can be changed in the "Settings" tab for any page as well so whether you're translating new pages or existing pages, you control the URLs everywhere.

      Language configuration pages are no different. Translate the names of your languages and search for both Site Translation Files (including all of your modules)

      Translate all of the static text in your templates as well. Notice that the placeholders are retained. DeepL is pretty good at recognizing and keeping non-translatable strings like that. If it is changed, it's easy to fix manually.

      Fluency adds a "Translate" item to the CMS header. When clicked this opens up a modal with a full translation tool that lets the user translate any language to any language. No need to leave the admin if you need to translate content from a secondary language back to the default ProcessWire language. There is also a button to get the current API usage statistics. DeepL account owners can set billing limitations via character count to control costs. This may help larger sites or sites being retrofitted keep an eye on their usage. Fluency can be used by users having roles given the fluency-translate permission.

      It couldn't be easier to add Fluency to your new or existing website. Simply add your API key and you're shown what languages are currently available for translation from/to as provided by DeepL. This list and all configuration options are taken live from the API so when DeepL releases new languages you can add them to your site without any work. No module updates, just an easy configuration. Just match the language you configured in ProcessWire to the DeepL language you want it to be associated with and you're done. Fluency also allows you to create a list of words/phrases that will not be translated which can prevent items such as brands and company names from being translated when they shouldn't

       
      Limitations:
      No "translate page" - Translating multiple fields can be done by clicking multiple translation links on multiple fields at once but engineering a "one click page translate" is not feasible from a user experience standpoint. The time it takes to translate one field can be a second or two, but cumulatively that may take much longer (CKEditor fields are slower than plain text fields). There may be a workaround in the future but it isn't currently on the roadmap. No "translate site" - Same thing goes for translating an entire website at once. It would be great, but it would be a very intense process and take a very (very) long time. There may be a workaround in the future but it isn't on the roadmap. No current support for Inline CKEditor fields - Handling for CKEditor on-demand hasn't been implemented yet, this is planned for a future release though and can be done. I just forgot about it because I've never really used that feature personally.. Alpha release - This module is in alpha. Releases should be stable and usable, but there may be edge case issues. Test the module thoroughly and please report any bugs via a Gitlab issue on the repository or respond here. Please note that the browser plugin for Grammarly conflicts with Fluency (as it does with many web applications). To address this issue it is recommended that you disable Grammarly when using Fluency, or open the admin to edit pages in a private window where Grammarly may not be loaded. This is an issue that may not have a resolution as creating a workaround may not be possible. If you have insight as to how this may be solved please visit the Gitlab page and file a bugfix ticket.
      Requirements:
      ProcessWire  3.0+ UIKit Admin Theme That's Fluency in a nutshell. A core effort in this module is to create it so that there is nothing DeepL related hard-coded in that would require updating it when DeepL offers new languages. I would like this to be a future-friendly module that doesn't require developer work to keep it up-to-date.
      It's Free
      This is my first real module and I want to give it back to the community as thanks. This is the best CMS I've worked with (thank you Ryan & contributors) and a great community (thank you dear reader). The only cost to use this is a subscription fee for the DeepL Pro API. Find out more and sign up here.
      Download & Feedback
      Download the latest version here
      https://github.com/SkyLundy/Fluency-Translation/archive/main.zip
      Github repository:
      https://github.com/SkyLundy/Fluency-Translation
      File issues and feature requests here (your feedback and testing is greatly appreciated):
      https://github.com/SkyLundy/Fluency-Translation/issues
       
      Thank you! ¡Gracias! Ich danke Ihnen! Merci! Obrigado! Grazie! Dank u wel! Dziękuję! Спасибо! ありがとうございます! 谢谢你!

    • By Robin S
      An inputfield module that brings EasyMDE Markdown editor to ProcessWire.
      EasyMDE is a fork of SimpleMDE, for which there is an existing PW module. Inputfield EasyMDE has a few advantages though:
      EasyMDE seems to be more actively developed than SimpleMDE, which hasn't seen any updates for several years. You can define options for Inputfield EasyMDE. Inputfield EasyMDE can be used in Repeater fields and in custom fields for File/Image fields.  
      Inputfield EasyMDE
      EasyMDE (Easy Markdown Editor) as an inputfield for ProcessWire.
      EasyMDE is a Markdown editor with some nice features, allowing users who may be less experienced with Markdown to use familiar toolbar buttons and shortcuts. More information is at the EasyMDE website.

      Installation
      Install the Inputfield EasyMDE module.
      Usage
      Create a new textarea field, and in the "Inputfield Type" dropdown choose "EasyMDE". Save the field and if you like you can then configure the EasyMDE options for the field as described below.
      To convert Markdown to HTML you can install the core TextformatterMarkdownExtra module and apply the textformatter to the field. Alternatively you can use $sanitizer->entitiesMarkdown() on the field value, e.g.
      echo $sanitizer->entitiesMarkdown($page->your_field_name, ['fullMarkdown' => true]); Configuration
      On the "Input" tab of the field settings you can define EasyMDE options for the field in JSON format. Refer to the EasyMDE documentation for the available options. Keys in the JSON must be surrounded with double quotes.
      Example:
      "toolbar": ["bold", "italic", "heading", "|", "side-by-side"], "sideBySideFullscreen": false  
      https://github.com/Toutouwai/InputfieldEasyMDE
      https://processwire.com/modules/inputfield-easy-mde/
×
×
  • Create New...