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 Cybermano
      Food Allergens Module
      A simple List of Food Allergens
      My needs were to provide a simple list of food allergens for our clients with restaurant related activity.
      The idea was to simply output the list (to speed up the data entry) without leaving the food menu editing, eg. opening another page in new tab or window.
      This isn't a perfect solution, but it works fine for my needs and I decided to share the base idea.
      This could also be easily used to show little notes or short "vademecum", not only for the list of food allergens.
      ---
      Main features
      The basis
      All moves from a short editing of the module in this tutorial: How to create custom admin pages by @bernhard
      First of all it creates an empty admin page, with a dedicated permission to let safe-user to see it (this permission has to be created as a new ones, manually or by the module).
      Once the page is created, I have hooked its behaviour into the ready.php, to show the content (basically a list).
      A step further
      With the tips of  @bernhard, @Soma (and many others), see here , the magic happens. 
      The new page will be shown as a panel, so editors will not abandon their data entry to have a quick view to the list.
      A little further
      Why scroll to the top of the page to click a link?
      The next step was to create a sticky button only in the food menu pages.
      Again with a @bernhard tip I moved into the customization of this simple module and the related hook.
      ---
      How to use this module
      After installed, it creates the page /admin/page/allergens/ and the module is to be setted up. The first field is a CKEditor with multi-language. This is the place where to write the informations that will be shown into the page. The next field is a simply text-area where to place a bit of JS that will be appended to the markup of the text (omit the 'script' tags). I also putted a checkbox with a silly statement: this to think at least twice on the safety of the written JS. Now comes the first way to display the link to the page
      Field Note with Link. Enable and save it. The module will display a new row with 4 selects (1 standard and 3 ASM):
      View mode (to show the page as Panel or as Modal PopUp); Templates to select: select one or more and save before proceed, so the  asm-select of the pages will be populated showing all the pages of the selected templates. Pages to select: also here select at least one and save before proceed to populate the asm-select for fields only with the ones that belong to the selected pages. Select the fields where to place the note and save again. That's all: now you will find into the notes of the selected fields the link "See the List of Allergens".
      At the same way, the option for the sticky button, but with a plus
      The field select is obviously unnecessary, but you could play with the last row: the inline styles to fix your sticky button where you like. Here you could set the sticky position of the <div> and the absolute ones of the <a>.

      Video Explanation
      In these screencasts you could see a custom JS that show a "copy" button near a "hanna-code" call.
      This because I've set a specific one for each allergen to show up a tooltip in the front end.

      Registrazione #33.mp4  

      Registrazione #34.mp4 ---
      Last but not the least
      Actually it works fine for my needs, even if it's much improvable: I'm working on the permissions creation, the uninstall section, a separate configs and defaults and how to include the hook into the module leaving free the ready.php. According to a simpler uninstall. Also I would make the link text as a dynamic text field, so it will be more flexible.
      I always learn a lot here, so I would share my code for whom it could be interested.
      I removed the hanna code references, but I provide you the html list of the allergens, English and Italian too, so you can paste them into the "source" of the CKEditor field to have a ready to use module.
      Obviously you are free to modify the code as per your needs.
      Please, keep in mind that I'm not a pro coder and I beg your pardon for my verbosity (speaking and coding). 😉
      I hope be helpful or for inspiration.
      Bye
      ready.phpList-ITA.htmlList-ENG.htmlAllergens.module
      README.md
    • By Robin S
      This module is sort of an upgrade to my earlier ImageToMarkdown module, and might be useful to anyone working with Markdown in ProcessWire.
      Copy Markdown
      Adds icons to images and files that allow you to copy a Markdown string to the clipboard. When you click the icon a message at the top left of the screen notifies you that the copying has occurred.
      Screencast

      Note: in the screencast an EasyMDE inputfield is used to preview the Markdown. It's not required to use EasyMDE - an ordinary textarea field could be used.
      Usage: Images
      When you hover on an item in an Images field an asterisk icon appears on the thumbnail. Click the icon to copy an image Markdown string to clipboard. If the "Description" field is populated it is used as the alt text.
      You can also open the "Variations" modal for an image and click the asterisk icon to copy an image Markdown string for an individual variation.
      Usage: Files
      When you hover on an item in a Files field an asterisk icon appears next to the filename. Click the icon to copy a link Markdown string to the clipboard. If the "Description" field is populated it is used as the link text, otherwise the filename is used.
       
      https://github.com/Toutouwai/CopyMarkdown
      https://processwire.com/modules/copy-markdown/
    • By BitPoet
      I've realized that I've been jumping back and forth between the PW API docs and the source code for site modules far too much. The idea to hold all necessary documentation locally in one place has occurred to me before, but getting PHPDocumentor et al set up and running reliably (and producing readable output) as always been too much of a hassle. Today I was asked how I find the right hooks and their arguments, and that inspired me to finally get my backside down on the chair and whip something up, namely the
      Module Api Doc Viewer
      ProcessModuleApiDoc
      It lets you browse the inline documentation and public (optionally also protected) class/method/property information for all modules, core classes and template files in the ProcessWire instance. The documentation is generated on the fly, so you don't have to remember to update your docs whenever you update a module.
      The module is quite fresh, so expect some bugs there. Behind the scenes it uses PHP-Parser together with a custom class that extracts the information I needed, and the core TextformatterMarkdownExtra module for rendering the description part in the phpdoc style comments.
      This is not a replacement / competitor to the API Viewer included in the commercial ProDevTools package. There is quite some information included in the inline documentation that my module can't (and won't) parse, but which makes up parts of the official ProcessWire API docs.
      This, instead, is a kind of Swiss army knife to view PHPDoc style information and get a quick class or function reference.
      If you feel daring and want to give it a spin, or if you just want to read a bit more, visit the module's GitHub repository.
      This is the overview page under "Setup" -> "Module API Docs":

      And this is what the documentation for an individual class looks like:

      The core module documentation can of course be found online, but it didn't make sense not to include them.
      Let me know what you think!

    • By tcnet
      File Manager for ProcessWire is a module to manager files and folders from the CMS backend. It supports creating, deleting, renaming, packing, unpacking, uploading, downloading and editing of files and folders. The integrated code editor ACE supports highlighting of all common programming languages.
      https://github.com/techcnet/ProcessFileManager

      Warning
      This module is probably the most powerful module. You might destroy your processwire installation if you don't exactly know what you doing. Be careful and use it at your own risk!
      ACE code editor
      This module uses ACE code editor available from: https://github.com/ajaxorg/ace

      Dragscroll
      This module uses the JavaScript dragscroll available from: http://github.com/asvd/dragscroll. Dragscroll adds the ability to drag the table horizontally with the mouse pointer.
      PHP File Manager
      This module uses a modified version of PHP File Manager available from: https://github.com/alexantr/filemanager
       
    • By teppo
      Admin Restrict Branch Select is an add-on / companion module for Admin Restrict Branch. With this module enabled, you can manually select more than one branch parent per user via the branch_parent field, and users with more than one option selected will be able to switch between those while editing site content. Switching between branches is done via a select field injected at the top of the page tree.
      Note that users are still limited to one branch at a time: this module will not make it possible to view multiple branches at the same time.
      When the module is installed, it will automatically update the branch_parent field if deemed necessary, i.e. if it isn't yet configured to allow selecting multiple pages. You can make changes to the field later, if you want to restrict selectable options by template, use asmSelect instead of PageListSelectMultiple, etc. 
      This is an early beta release, so be sure to test carefully before enabling this module in production!
      https://processwire.com/modules/admin-restrict-branch-select/
      https://github.com/teppokoivula/AdminRestrictBranchSelect
×
×
  • Create New...