Jump to content

Wireframe


teppo

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
Link to comment
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.

Link to comment
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 🙂 

Link to comment
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
Link to comment
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
Link to comment
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

Link to comment
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
Link to comment
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.

 

  • Like 1
Link to comment
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
Link to comment
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
Link to comment
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
Link to comment
Share on other sites

  • 2 weeks later...

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 2
  • Thanks 1
Link to comment
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
Link to comment
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
Link to comment
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
Link to comment
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
Link to comment
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
Link to comment
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
Link to comment
Share on other sites

  • 4 weeks later...

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
Link to comment
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
Link to comment
Share on other sites

  • 4 weeks later...

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
Link to comment
Share on other sites

  • 3 weeks later...

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
Link to comment
Share on other sites

  • teppo pinned this topic

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 monollonom
      PageMjmlToHtml
      Github: https://github.com/romaincazier/PageMjmlToHtml
      Modules directory: https://processwire.com/modules/page-mjml-to-html/
      A module allowing you to write your Processwire template using MJML and get a converted HTML output using MJML API.
      This is considered to be in alpha and as such needs some testing before being used in production!

      About
      Created by Mailjet, MJML is a markup language making it a breeze to create newsletters displayed consistently across all email clients.
      Write your template using MJML combined with Processwire’s API and this module will automatically convert your code into a working newsletter thanks to their free-to-use Rest API.
      Prerequisite
      For this module to work you will need to get an API key and paste it in the module’s configuration.
      Usage
      Once your credentials are validated, select the template(s) in which you’re using the MJML syntax, save and go visualize your page(s) to see if everything’s good. You will either get error/warning messages or your email properly formatted and ready-to-go.
      From there you can copy/paste the raw generated code in an external mailing service or distribute your newsletter using ProMailer.
      Features
      The MJML output is cached to avoid repetitive API calls Not cached if there are errors/warnings Cleared if the page is saved Cleared if the template file has been modified A simple (dumb?) code viewer highlights lines with errors/warnings A button is added to quickly copy the raw code of the generated newsletter Not added if the page is rendered outside of a PageView Only visible to users with the page’s edit permission A shortcut is also added under “View” in the edit page to open the raw code in a new tab Multi-languages support
      Notes
      The code viewer is only shown to superusers. If there’s an error the page will display:
      Only its title for guests Its title and a message inviting to contact the administrator for editors If you are using the markup regions output strategy, it might be best to not append files to preserve your MJML markup before calling the MJML API. This option is available in the module’s settings.
    • By Marco Ro
      Hi guys!
      I'm a bit anxious because this is the first module I present! (beta modulo) But I will finally be able to share something with the community too! :)
      This is a BETA version of the PayPal payment system called: PayPal Commerce Platform.
      It is an advanced system (Business Pro account is needed) that brings various benefits in terms of fees and above all integrates direct payment with credit/debit cards. 
      The module integrates with Padloper 0.0.2, which is the current installation I'm using.
      This system integrates the classic PayPal buy button, the alternative or local payment method and the new payment system: credit/debit cards that doesn't go through the PayPal account. It is a Stripe-style payment, it connects directly with the bank and integrates 3D security validation.
      I say that it is a BETA because this module currently only works with Sandbox account, to put it live you need to change API url manually (manually for the moment).
      Because this module is not ready for live:
      I would like to have your opinion on how I built the module (is the first one I do). I don't want to share something that is not fish but I need a comparison with someone more experienced than me, for be sure that this is the best way to code the module.
      If you want to try this I created a git, you will find all the instructions for installation and correct operation. (Git has a MIT licensed)
      https://github.com/MarcooRo/processwire-PayPal-Commerce-Platform I hope I did something that you guys can like :)
    • By monollonom
      (once again I was surprised to see a work of mine pop up in the newsletter, this time without even listing the module on PW modules website 😅. Thx @teppo !)
      FieldtypeQRCode
      Github: https://github.com/romaincazier/FieldtypeQRCode
      Modules directory: https://processwire.com/modules/fieldtype-qrcode/
      A simple fieldtype generating a QR Code from the public URL of the page, and more.
      Using the PHP library QR Code Generator by Kazuhiko Arase.

      Options
      In the field’s Details tab you can change between .gif or .svg formats. If you select .svg you will have the option to directly output the markup instead of a base64 image. SVG is the default.
      You can also change what is used to generate the QR code and even have several sources. The accepted sources (separated by a comma) are: httpUrl, editUrl, or the name of any text/URL/file/image field.
      If LanguageSupport is installed the compatible sources (httpUrl, text field, ...) will return as many QR codes as there are languages. Note however that when outputting on the front-end, only the languages visible to the user will be generated.
      Formatting
      Unformatted value
      When using $page->getUnformatted("qrcode_field") it returns an array with the following structure:
      [ [ "label" => string, // label used in the admin "qr" => string, // the qrcode image "source" => string, // the source, as defined in the configuration "text" => string // and the text used to generate the qrcode ], ... ] Formatted value
      The formatted value is an <img>/<svg> (or several right next to each other). There is no other markup.
      Should you need the same markup as in the admin you could use:
      $field = $fields->get("qrcode_field"); $field->type->markupValue($page, $field, $page->getUnformatted("qrcode_field")); But it’s a bit cumbersome, plus you need to import the FieldtypeQRCode's css/js. Best is to make your own markup using the unformatted value.
      Static QR code generator
      You can call FieldtypeQRCode::generateQRCode to generate any QR code you want. Its arguments are:
      string $text bool $svg Generate the QR code as svg instead of gif ? (default=true) bool $markup If svg, output its markup instead of a base64 ? (default=false) Hooks
      Please have a look at the source code for more details about the hookable functions.
      Examples
      $wire->addHookAfter("FieldtypeQRCode::getQRText", function($event) { $page = $event->arguments("page"); $event->return = $page->title; // or could be: $event->return = "Your custom text"; }) $wire->addHookAfter("FieldtypeQRCode::generateQRCodes", function($event) { $qrcodes = $event->return; // keep everything except the QR codes generated from editUrl foreach($qrcodes as $key => &$qrcode) { if($qrcode["source"] === "editUrl") { unset($qrcodes[$key]); } } unset($qrcode); $event->return = $qrcodes; })
    • By Sebi
      AppApiFile adds the /file endpoint to the AppApi routes definition. Makes it possible to query files via the api. 
      This module relies on the base module AppApi, which must be installed before AppApiFile can do its work.
      Features
      You can access all files that are uploaded at any ProcessWire page. Call api/file/route/in/pagetree?file=test.jpg to access a page via its route in the page tree. Alternatively you can call api/file/4242?file=test.jpg (e.g.,) to access a page by its id. The module will make sure that the page is accessible by the active user.
      The GET-param "file" defines the basename of the file which you want to get.
      The following GET-params (optional) can be used to manipulate an image:
      width height maxwidth maxheight cropX cropY Use GET-Param format=base64 to receive the file in base64 format.
    • By MarkE
      This fieldtype and inputfield bundle was built for storing measurement values within a field, rendering them in a variety of formats and converting them to other units or otherwise modifying them via the API.
      The API consists of a number of predefined functions, some of which include...
      render() for rendering the measurement object, valueAs() for converting the value to another unit value, convertTo() for converting the whole measurement object to different units, and add() and subtract() for for modifying the stored value by the value (converted as required) in another measurement. In the admin the inputfield includes a checkbox (which can be optionally disabled) for converting values on page save. For an example if a value was typed in as centimeters, the unit was changed to metres, and the page saved with this checkbox selected, said value would be automatically converted so that e.g. 170 cm becomes 1.7 m.

      A simple length field using Fieldtype Measurement and Inputfield Measurement.
      Combination units (e.g. feet and inches) are also supported.
      Please note that this module is 'proof of concept' at the moment - there are limited units available and quite a lot of code tidying to do. More units will be added shortly.
      See the GitHub at https://github.com/MetaTunes/FieldtypeMeasurement for full details and updates.
×
×
  • Create New...