Jump to content
felix

in-page editing / create.js / create.php

Recommended Posts

Hi Ryan,

first - as this is my first post - let me say i just started using processwire and already fell in love with it. You're doing a great job!

There already are several threads about replacing the current wyswig editor (TinyMCE) with [insert $editor here].

I did a forum search and wondered why no one mentioned implementing in-page editing like most "big cms" (drupal 8, typo3 neos, symfony cmf...) currently are. In my opinion this is an absolut killer feature from a clients/authors point of view.

As create.js is just an editing API people could also start using whatever editor they like (currently availabe editors are: hallo.js, aloha, ckeditor, redactor).

If you never read about create.js you should visit http://createjs.org/ and have a look at the demos as well as this blog post: http://bergie.iki.fi/blog/createjs-in-2013/ .

There already is a PHP library (create.php - https://github.com/flack/createphp ) which aims to help integrating create.js into existing applications/cms.

I'd absolutely love to see this feature in an upcoming version of processwire (even though i will also keep using processwire it if there won't be in-page editing ;)).

Best regards,

Felix

  • Like 3

Share this post


Link to post
Share on other sites

Hi Felix, welcome to the COM.

It would not be an problem to integrate in Page editing, but I think this shouldnt be placed to the core.

With some little php template scripting its very Easy to implement the plugin and edit Pages via the API.

Share this post


Link to post
Share on other sites

Just building on what Luis said, the thing about ProcessWire is that it doesn't make any assumptions about your templates on the front-end, so you couldn't package it as a working part of the core anyway as the first thing most people do is implement their own templates which would strip out the necessary tags to make this work.

I think it could certainly be a module (just so it gets bundled with one or more of those editors) that can be downloaded and installed with simple instructions for the developer to implement the necessary tags into their template though, so that's certainly worthwhile someone pursuing.

There are some considerations though, such as the way images are handled in ProcessWire, that require further thought as well (hence why I'm thinking a module again).

As with most things in PW though, it's certainly possible to implement :)

Share this post


Link to post
Share on other sites

I see your points and fully agree.

At first i wanted to start this topic in the modules section but realized there were mostly "look at my finished modules" topics, so i decided to post it as a general wish.

Could somebody please move this thread to the "modules" section? :)

//edit: I apologize i forgot to also thank all contributors in my first posting and would like to do so now ;)

  • Like 2

Share this post


Link to post
Share on other sites

Done, and tagged as a module request :)

Share this post


Link to post
Share on other sites

I think that create.js is interesting (and made in Finland, JEJ!). I am not much fan of RDF, but in that scenario it actually seems to make a lot of sense. See this (modified their example markup to fit pw):

<div about="/path/to/mypage/" typeof="sioc:basic-page">
  <h1 property="title">Some title</h1>
  <div property="body">
    Some content
  </div>
</div>

The interesting part is that how to automate (or whether automate it at all?) the RDF in markup? 

Share this post


Link to post
Share on other sites

I think this is definitely a great idea for a module. But it's also true that it kind of goes against the whole markup agnosticism, and is pretty limited when you consider the broad range of inputs possible with Inputfields. In the context of ProcessWire, it's only a partial input solution. Most importantly, front-end editing goes against content portability and is thus not a best practice. We should be abstracting content away from design, not tightly coupling content into it. I think many using a front-end solution would try to design and fit their content for the space they are typing in. Then the content is a mess when the site goes mobile, responsive or gets redesigned, etc. Promoting content portability is an important job of a CMS, and front-end editing is not good for content portability. That being said, it's great eye candy and there are plenty of cases where I think the benefits of it would outweigh the negatives too. As a core solution, I think front-end editing is a bad idea. But as a modular option for those that want it and understand the tradeoffs, I think it's a great idea. I can think of cases I would use it myself too. 

  • Like 3

Share this post


Link to post
Share on other sites

Greetings,

I've spent a lot of time (really, a lot) on the whole subject of front-end editing.  It's something that users really want, but I agree with Ryan that we need to make sure it works in the whole scheme of site development.

I think it's good to make a distinction between two separate but somewhat similar practices:

  • Front-end editing
  • In-place editing

The difference, I like to say, is the idea of "literal" content control.

The one that causes trouble is "in-place editing," where clients want to have a window right there on the page in the exact spot where the material appears.  They want to create and edit content in that "literal" space.  This has many problems.

"Front-end editing" is more feasible -- with good development practices.  The user can link to an editing function for the page.  But they are taken to a proper interface for editing or creating content that takes into account that content cannot always be placed so directly.  The interface to edit and create content is not literal.

Seen this way, it's up to us as developers to explain to clients what each of these methods is, and why even though one seems prettier it's actually not as good for their sites.  It's a few extra steps, but if we design an interface that is easy to understand, users have no problem with the extra steps.

Thanks,

Matthew

  • Like 2

Share this post


Link to post
Share on other sites

I have to agree with Matthew that I have mixed feelings with inline editing. Having said that, where it is implemented to allow basic tweaking rather than complete rebuilding, I think it can have its place.

Since most of the JQuery/HTML5 editors are implemented on a tag by tag basis, it is easy from the template point of view to allow inline editing on some parts and not others.

Personally, I do like simply clicking on an edit button and going to a neat, proper edit page (either by popup or other) where you have the tools as set out when originating an article and then returning to the published page on save.

Consequently, my main interest in the new generation of editors is their clean lines, simple implementation and speed.

A lot of this is down to the design of the actual page which is being edited. If you look at Google Sites, you have a very fixed page structure and when you go into edit it will look exactly the same and yet be fully and properly editable.

If your page is split up with all kinds of boxes, interrupted with adverts and so on, it really does not work quite as well.

In addition, an author should write to make best use of the subject first and layout second. It is up to the editor or editing process to make sure the final piece fits in the necessary hole.

Personally, I don't think any edit tool I have come across gets the balance right - they seem to be either too quirky or completely overblown :)

  • Like 2

Share this post


Link to post
Share on other sites

This discussion came up in the office again today with a designer, and I came across this thread while googling the subject.

I've been obsessing over this topic for a decade - I've hated WYSIWYG editors since they emerged, and I still hate them, for the same reasons.

All the technical issues aside, conceptually, giving clients complete control over HTML in my opinion is a bad idea to begin with. But also, I have the opinion that bare HTML is simply the wrong medium for content, because it provides no structure and no control; no means of enforcing any standards on content.

What I would really like to see, is something like Hallo or Aloha integrated with a template-based content editor - and I mean templates in the sense of structural HTML templates of some kind. This content editor would let you pick from templates pre-created by designers/programmers for the site. It would have semi-rich content areas here and there, meaning paragraphs, h1-h6, strong/em, a-tags, ul/ol/li - but not things like inline images or tables. Instead you would have nested "micro templates" for things like "image with caption", "image gallery", and other much richer types of content than you can feasibly do with just a WYSIWYG.

This would provide much better control than just an HTML editor - and it is possible now, with contenteditable being widely supported, and great in-place editors like Hallo and Aloha now available. Bigger or smaller sections in deeply nested "micro templates" could provide the right level of in-place editing for actual content, and modern user-friendly UI for everything else - without trying to bake everything into user-editable HTML markup ("mce_"-attributes in your HTML markup anyone?) and without losing the ability to actually update these templates on the server-side, reflecting changes on existing content.

I long and yearn for the day when I can actually present a client with a content editor that I myself could stand to use... ;-)

Share this post


Link to post
Share on other sites

typo3 neos which is now in beta does most of the frontend in place editing stuff as well as adding content templates exactly the way you've mentioned. I must admit that at it's current, more advanced state it's exactly what i had in mind when i was opening this thread. but after all it's still typo3 (typoscript, flow... yikes!). that's why i won't be using it. :D

Share this post


Link to post
Share on other sites

Front end editing for customers/clients is a hot topic since the days of cms. Sooner or later your customer/client is going to ask you how he can edit/change parts of his website him self in a simple way. Examples are changing text or prices for his products. I think nowadays a cms should have included this from the start. Anyway I think markitup is a nice third party solution.

http://markitup.jaysalvat.com/home/

Share this post


Link to post
Share on other sites

<pwired>I think nowadays a cms should have included this from the start.</pwired>

I disagree on this. I prefer well formed structural information, not the graphical representation in one situation. 

Content should have an independent value, not fixed to one distribution, so it can be used on a multitude of platforms.

There are situation where in-page editing makes sense, but we should not forget there's high value in structural information.

  • Like 2

Share this post


Link to post
Share on other sites
I'd absolutely love to see this feature in an upcoming version of processwire (even though i will also keep using processwire it if there won't be in-page editing ;)).

I agree. I think the issue with in-page editing is not that it is technically speaking a better solution. But the spontaneous response by a lot of (prospective) clients is just too positive for it to be dismissed (...or they will go somewhere else!). I just recently showed my PW demo site to someone, they liked it, but the spontaneous feedback was that it would be even nicer if content could  be edited right on the page.

The thing is, I´m talking about small website owners, not people running a newspaper or large company website (who presumably are IT-pros). And to them the more intuitive the thing feels, the more appealing it is...

Obviously one has to strictly limit the options people have when editing, but that is the same when using RTEs on the back-end, to me it really is only about the CMS feeling more intuitive with on-the-page (inline) editing, not about new functions.

I truly like PW and feel that after a fair bit of searching I have found the CMS I really want to use - but it is pivotal to me that I get front-page inline editing running. I already have it working for text content using CKEditor (it´s easy, if someone needs some help with this I´m happy to post it.) But for handling images and links within the PW structure I still have to send users to the back-end, hope to be able to fix that soon.

Share this post


Link to post
Share on other sites

It is interesting to balance the discussion of in-page editing against the ideas being discussed elsewhere about versioning, drafts and previews.

For me, although I love the tactile idea of in-page editing, there needs to be some sort of safety system in place that stops people experimenting/publishing/experimenting more/republishing/changing/forgetting to publish and so on.

However intuitive it might be, I can see some huge holes opening up on a live site if there is not strict editorial controls or someone writes something in a block of text that is too short but thinks - "nah, that will be fine!"

To me, this sort of editing is fantastic when developing a site - it is really useful to see where you are heading, but after that it can be pure danger unless there is a draft/versioning/preview/editorial system in place so that changes can be made and double checked before the existing page is replaced.

Of course, this applies to editing in the back end too, but I think with front end editing clients will often think "oh yeah, see a mistake, click on it, change it, bosh ... it is done" without realising the implications of editing a site in that way.

  • Like 2

Share this post


Link to post
Share on other sites

Joss, I think you are making a valid point about issues with front-page inline editing here. I believe it just depends on the kind of site:

The reason I am so interested in making front-page editing work smoothly is that I´m intending to create a CMS/site structure ideal for small website owners. These sites are often managed by one person only and they normally do not need versioning.

As to drafts and previews:

there needs to be some sort of safety system in place that stops people experimenting/publishing/experimenting more/republishing/changing/forgetting to publish

I do agree that this would be ideal, taking things a step further. I could imagine that instead of actually editing the live pages directly things could be set up so one would edit a sort of "shadow-version", a page that looks just like the live page but only overwrites it once you choose to do so.

However the draft/preview functionality is not contained in a standard PW setup now either. You can only work on a draft version while you keep it unpublished. I´m not proposing to eliminate that when implementing in-page editing, but you could only do it on an unpublished page in the back end, same as now. If you work on an already published page any change you make goes live once you save it, unless you set it to "unpublished", but that is the case now too.

About forgetting to publish: Well yes, it can happen, same as it could happen now if you click on a link in the back-end after editing a page without clicking "Save" first. I don´t see a difference there. (In either case, maybe a JavaScript popup warning might be something worth implementing to avoid this).

Of course, this applies to editing in the back end too, but I think with front end editing clients will often think "oh yeah, see a mistake, click on it, change it, bosh ... it is done" without realising the implications of editing a site in that way.

It applies to back-end editing also, as you are saying here and I have written above. I don´t really understand then why you think that spontaneously making changes would affect the site differently if done on-page rather than in the back-end?

Share this post


Link to post
Share on other sites

Hi Joe

It is not that spontaneous edits on the front affect the site differently so much as the temptation to do so :)

It is the old adage about the button in the empty factory. If it is just a button it either gets ignored or only attracts people who are actively looking for it.

If it is big, bright coloured with a big notice that says "do not press this button," it becomes almost irresistible!   :)

Share this post


Link to post
Share on other sites

You have a point there. But on the other hand it just feels good to edit things "on the fly" and people go for it. Changing content easily is what a CMS is about after all. Whether in-page editing is preferable for a site or not will really just depend on the setting I think.

Share this post


Link to post
Share on other sites

We are currently considering whether we should change from Drupal to Processwire at least with some sites. It is quite important desicion for us, since we have about 30 websites from very small to few quite big ones. I have heard and seen lots of good things, but not having an in place editor is a bad thing.

Most of our users are not professional web editors. In our old system we had quick link to editing on backend visible to users browsing web with enough rights and this helped a lot much like in pw. But still I think for an modern cms you shoud have option to use in place editor.

Having it as module preferably including default/example theme working with it out of the box might be a good solution. Versioning would be good, but it is not necessity for us.

Share this post


Link to post
Share on other sites

Most of our users are not professional web editors. In our old system we had quick link to editing on backend visible to users browsing web with enough rights and this helped a lot much like in pw. But still I think for an modern cms you shoud have option to use in place editor.

A simple edit link can be done with ease.

Regarding in place editing: I think especially for non professionals it's important to make them aware of the fact, that websites don't come in one shape. There are mobile layouts, responsive layouts, maybe a rss feed, which is shown in a rss viewer. Ryan already talked about that earlier in this thread. Nobody wants to have content with 15 " "'s just that the next word flows to the next line. 

If you just don't like your client to have to leave the current page to edit, take a look at this: http://modules.processwire.com/modules/fredi/.

  • Like 3

Share this post


Link to post
Share on other sites

Wo and behold, somebody started building that content editor I talked about - separating content from layout:

http://madebymany.github.io/sir-trevor-js/

Very interesting! :-)

Though I expect the server-side rendering needs to be done with e.g. Node and can't easily be done with PHP.

There was some discussion about Sir Trevor, starting at this post:

https://processwire.com/talk/topic/4189-flexibility-in-page-design/?p=46536

Share this post


Link to post
Share on other sites

Aloha Editor is back with something new:

http://www.alohaeditor.org/Content.Node/blog/goodbye-contenteditable.html

http://www.alohaeditor.org/Content.Node/blog/introducing-aloha-ui.html

Basing your editor on contentEditable means that you have to clean up the broken mess of markup the browser leaves behind. Every big editor with wide adoption works exactly that way. It's basically like babysitting a caffeinated lemming. We think that this is the wrong approach. Why would you want to fix something if you can get it right in the first place?

This is why we came up with Aloha Editor 2. We provide you capabilities to create editing experiences embedded seamlessly in your web application. With a stateless API, that was built to give you full control. An API that is easy to use, so you can craft the best experience possible for your users.

  • 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 kongondo
      FieldtypeRuntimeMarkup and InputfieldRuntimeMarkup
       
      Modules Directory: http://modules.processwire.com/modules/fieldtype-runtime-markup/
      GitHub: https://github.com/kongondo/FieldtypeRuntimeMarkup
      As of 11 May 2019 ProcessWire versions earlier than 3.x are not supported
      This module allows for custom markup to be dynamically (PHP) generated and output within a page's edit screen (in Admin).
       
      The value for the fieldtype is generated at runtime. No data is saved in the database. The accompanying InputfieldRuntimeMarkup is only used to render/display the markup in the page edit screen.
       
      The field's value is accessible from the ProcessWire API in the frontend like any other field, i.e. it has access to $page and $pages.
       
      The module was commissioned/sponsored by @Valan. Although there's certainly other ways to achieve what this module does, it offers a dynamic and flexible alternative to generating your own markup in a page's edit screen whilst also allowing access to that markup in the frontend. Thanks Valan!
       
      Warning/Consideration
      Although access to ProcessWire's Fields' admin pages is only available to Superusers, this Fieldtype will evaluate and run the custom PHP Code entered and saved in the field's settings (Details tab). Utmost care should therefore be taken in making sure your code does not perform any CRUD operations!! (unless of course that's intentional) The value for this fieldtype is generated at runtime and thus no data is stored in the database. This means that you cannot directly query a RuntimeMarkup field from $pages->find(). Usage and API
       
      Backend
      Enter your custom PHP snippet in the Details tab of your field (it is RECOMMENDED though that you use wireRenderFile() instead. See example below). Your code can be as simple or as complicated as you want as long as in the end you return a value that is not an array or an object or anything other than a string/integer.
       
      FieldtypeRuntimeMarkup has access to $page (the current page being edited/viewed) and $pages. 
       
      A very simple example.
      return 'Hello'; Simple example.
      return $page->title; Simple example with markup.
      return '<h2>' . $page->title . '</h2>'; Another simple example with markup.
      $out = '<h1>hello '; $out .= $page->title; $out .= '</h1>'; return $out; A more advanced example.
      $p = $pages->get('/about-us/')->child('sort=random'); return '<p>' . $p->title . '</p>'; An even more complex example.
      $str =''; if($page->name == 'about-us') { $p = $page->children->last(); $str = "<h2><a href='{$p->url}'>{$p->title}</a></h2>"; } else { $str = "<h2><a href='{$page->url}'>{$page->title}</a></h2>"; } return $str; Rather than type your code directly in the Details tab of the field, it is highly recommended that you placed all your code in an external file and call that file using the core wireRenderFile() method. Taking this approach means you will be able to edit your code in your favourite text editor. It also means you will be able to type more text without having to scroll. Editing the file is also easier than editing the field. To use this approach, simply do:
      return wireRenderFile('name-of-file');// file will be in /site/templates/ If using ProcessWire 3.x, you will need to use namespace as follows:
      return ProcessWire\wireRenderFile('name-of-file'); How to access the value of RuntimeMarkup in the frontend (our field is called 'runtime_markup')
       
      Access the field on the current page (just like any other field)
      echo $page->runtime_markup; Access the field on another page
      echo $pages->get('/about-us/')->runtime_markup; Screenshots
       
      Backend
       

       

       
      Frontend
       

    • By kongondo
      Visual Page Selector
      Released 31 March 2016
      https://processwireshop.pw/plugins/visual-page-selector/
        As of 04 January 2018 ProcessWire versions earlier than 3.x are not supported   *******************************************************   ORIGINAL POST   ******************************************************* Introducing VPS, a commercial visual page field selector. 
      This is a pre-sale closed-beta version. This post is WIP and will be updated now and then.
      ############################
      Many ProcessWire users use the 'one image per page' principle to manage and reuse images across their sites. This works fine. However, for site editors who mainly work with images, especially for larger sites, it is sometimes difficult to remember the pages where particular images reside. This module helps to solve this challenge.
      Harnessing the awesomeness  that is ProcessWire, VPS provides a rich editing experience, enabling editors to search for, view, select, add, remove and delete page-images easily, in an easy to use and friendly interface. ProcessWire Lister is the workhorse behind the lightning-fast searches. Editors will be able to search for images by their descriptions, names, partial names, page names, templates, etc. 
      Current Features
      Single-image mode Full search Batch add/Remove/Delete Image/Delete Page in page fields Image Browser Selectable pages as per page field settings + Lister filters Grid and List View Draggable sorting Responsive (almost fully ..iframes!) Planned Features
      Multi-image mode (there are times you want to group similar images in multi-image field in one page; e.g. the back, front and side of a car photo) Configurable CSS on the fly resizing vs real image resizing (image resizing can quickly hog memory) Other as per feedback from beta testing FAQs
      When will this be available? 
      Soon.
      How much will it cost?
      Reasonably priced. Announcement soon.
      Where will I be able to buy this from?
      At all fine stores that stock quality ProcessWire products
      Do we really need another page field/inputfield select?
      See links below.
      What type of licenses will be available?
      Soon to be announced.
      Can I beta test this?
      Thanks for the interest but all available slots have been taken.
      Video (excuse the video quality please - too many takes....)
       
      Screens






      Previous Discussions
      https://processwire.com/talk/topic/10927-wishlist-select-pages-by-thumbnail/
      https://processwire.com/talk/topic/4330-get-image-from-other-pages-via-images-field/ https://processwire.com/talk/topic/417-extending-image-field/?p=6982 https://processwire.com/talk/topic/7073-profield-table-and-gallery/ https://processwire.com/talk/topic/3200-image-management-concerns-is-processwire-suitable-for-me/ https://processwire.com/talk/topic/425-file-manager/ https://processwire.com/talk/topic/10763-asset-manager-asset-selector/
    • By kongondo
      FieldtypeMatrix and InputfieldMatrix
      Modules Directory: http://modules.processwire.com/modules/fieldtype-matrix/
      GitHub: https://github.com/kongondo/FieldtypeMatrix 
      The module Matrix enables you to save data from a 2D-Matrix table. The rows and columns of the matrix table are made up of pages retrieved via a ProcessWire selector or via a page field selection of parent pages. The matrix values are made up of the data input in the matrix cells, i.e. the 'intersection of rows and columns'.
       
      Example Usage
      You have Products whose prices vary depending on colour, size, material, etc. Using the Fieldtype, you can create a table with rows made up of colours and columns made up of sizes the combination of each making up their respective values (in this case price). So rather than creating multiple text fields to do the following:
      Colour Size Price Red Small £10 Red Medium £20 Red Large £30 Red X-large £35 Green Small £9 Green Medium £15 Etc... You can instead have the following in one field:
      Small Medium Large X-Large Red £10 £20 £30 £35 Green £9 £15 Blue Etc... Yellow Purple If you set a selector in the Field's settings, to retrieve pages to build your matrix's rows and columns, it follows that all pages using the template the Fieldtype is attached to will have identical rows and columns. In some cases, this could be the intention. For instance, you might have 'Car' pages, e.g. Audi, Volvo, Ford, Citroen, Mazda, BWM, etc., each of which uses a 'Cars' template that has a single FiedltypeMatrix called 'car_attributes'. If you set a selector to build the Fieldtype's rows and columns, your users can easily compare the cars based on a combination of different values. The following matrix table best illustrates this:
      Type Engine Size Fuel Efficiency Carbon Emissions Warranty Road Tax Price 1994 Audi brand 1 values, etc. 2000 Audi brand 2 2006 Audi brand 3 2012 Audi brand 4 Each of your car pages would have similar matrices. 
      This allows you to make easy but powerful queries. Such a setup allows you to compare within and across car brands. Say you wanted to find out which car(s) offered the best value for money given certain parameters such as warranty, emissions etc. You can easily make such comparisons (see code below). You can also compare within one car type, e.g. which brand of BMWs does best in what area...The possibilities are endless.

      In the database, Rows and column pages data are stored as their respective page->id. Matrix-values store any data (varchar(255)).
       
      If instead you wanted a template's pages to each have a matrix built of different rows and columns, you would have to name a Multiple Page Field (attached to the same template as the as your matrix field) in the matrix field's settings. When editing those pages, your matrix table's rows and columns will be built using the published children pages of the 2 pages you select in the Multiple page field..
       
      The module allows the creation of matrix tables of any sizes (rows x columns). The rows and columns dynamically grow/shrink depending on the addition of row/column pages that match what you set in the matrix field's settings (see its 'Details Tab'). Please note that, if such pages are deleted/trashed/hidden/unpublished, their data (and presence) in the matrix are also deleted.
      Entering values in the matrix
      You have three choices:
      Manually entry Uploading a comma delimited (CSV) file. This can be delimited by other characters (tab, pipe, etc); not just commas Copy-pasting CSV values. (Tip: you can copy paste directly from an Excel spreadsheet. Such values will be 'tab-delimited'). In addition, if your server supports it, in the field's settings, you can enable the use of MySQL's fast LOAD DATA INFILE to read and save your submitted CSV values.
      Note that for large tables, you may have to increase your PHP's max_input_vars from the default 1000 otherwise PHP will timeout/return an error and your values will not be saved. I have successfully tested the module with up to ~3000+ values (10x350 table), the Fieldtype is not really optimised (nor was it intended) to handle mega large matrix tables. For such, you might want to consider other strategies. 
       
      Install
      Install as any other module.
       
      API + Output
      A typical output case for this module would work like this:
       
      The matrix's rows, columns and values are subfields of your matrix's field. So, if you created a field called 'products' of the type FieldtypeMatrix, you can access as:

      product.row, product.column and product.value respectively
       
      foreach($page->matrix as $m) { echo " <p> Colour: $m->row<br /> Size: $m->column<br /> Price: $m->value </p> "; } Of if you want to output a matrix table in the frontend: 
       
      //create array to build matrix $products = array(); foreach($page->matrix as $m) $products[$m->row][$m->column] = $m->value; $tbody ='';//matrix rows $thcols = '';//matrix table column headers $i = 0;//set counter not to output extraneous column label headers $c = true;//set odd/even rows class foreach ($products as $row => $cols) { //matrix table row headers (first column) $rowHeader = $pages->get($row)->title; $tbody .= "<tr" . (($c = !$c) ? " class='even' " : '') . "><td class='MatrixRowHeader'>" . $rowHeader . "</td>"; $count = count($cols);//help to stop output of extra/duplicate column headers foreach ($cols as $col => $value) { //matrix table column headers $columnHeader = $pages->get($col)->title; //avoid outputting extra duplicate columns if ($i < $count) $thcols .= "<th class='MatrixColumnHeader'>" . $columnHeader . "</th>"; //output matrix values $currency = $value > 0 ? '£' : ''; $tbody .= "<td>" . $currency . $value . "</td>"; $i++; } $tbody .= "</tr>"; } //final matrix table for output $tableOut = "<table class='Matrix'> <thead> <tr class=''> <th></th> $thcols </tr> </thead> <tbody> $tbody </tbody> </table>"; echo $tableOut; The module provides a default rendering capability as well, so that you can also do this (below) and get a similar result as the first example above (without the captions). 
      echo $page->matrix; Or this
      foreach($page->matrix as $m) { echo $m; } Finding matrix items
      The fieldtype includes indexed row, column and value fields. This enables you to find matrix items by either row types (e.g. colours) or columns (e.g. sizes) or their values (e.g. price) or a combination of some/all of these. For instance:
      //find all pages that have a matrix value of less than 1000 $results = $pages->find("products.value<1000"); //find some results in the matrix (called products) of this page $results = $page->products->find("column=$country, value=Singapore");//or $page->products->find("column=$age, value>=25"); //$country and $age would be IDs of two of your column pages Other more complex queries are possible, e.g. find all products that are either red or purple in colour, come in x-large size and are priced less than $50.

      Credits
      @Ryan on whose Fieldtype/InptufieldEvents this is largely based
      @charger and @sakkoulas for their matrix ideas
       
      Screens
       
      Field Details Tab

       
      Inputfield

      Larger matrix table

       
      Example output

    • By Pravin
      How to set the image quality as per desired..
      I tried using the above code but I get the original image size..
      <!--Content with Image left--> <?php $i = 2; foreach($page->page_content as $each) { if( $i%2 == 0 ){ ?> <section class="imageblock about-1"> <div class="imageblock__content col-md-6 col-sm-4 pos-left animated fadeInLeft"> <div class="background-image-holder"> <?php $option1 = array( 'quality' => 60, 'upscaling' => true, 'cropping' => true, ); $pravin= $each->single_image->size(790,650,$option1); ?> <img alt="image" src="<?php echo $pravin->url; ?>" /> </div> </div> <div class="container container-body"> <div class="row"> <div class="col-md-5 col-md-push-7 col-sm-8 col-sm-push-4 animated fadeInUp"> <?php echo $each->body; ?> </div> </div> <!--end of row--> </div> <!--end of container--> </section> <!--Content with Image on left--> <?php } else { ?> <!--Content with Image on right--> <section class="imageblock about-1"> <div class="imageblock__content col-md-6 col-sm-4 pos-right animated fadeInRight"> <div class="background-image-holder"> <?php $pravin= $each->single_image->size(790,650,$option1); ?> <img alt="image" src="<?php echo $pravin->url; ?>" /> </div> </div> <div class="container container-body"> <div class="row"> <div class="col-md-5 col-sm-8 animated fadeInUp"> <?php echo $each->body; ?> </div> </div> <!--end of row--> </div> <!--end of container--> </section> <?php } ++$i; } ?> <!--Content with Image on right-->  
    • By [Code] Specialist
      Hi Folks,
      I like to develop a Backend Module with extra tabs and nested fields. Is there any Example Code for my Idea ? 
      The Module should create new fields, a new Tab and several fields on it. AND... Last but not least the fields depend on each other by rules like "if checkbox $a then unfold area with Textfield 1+2 "
      If someone have a snippet for me to learn ... it would be soooo great. Thanks. 
      Michael
×
×
  • Create New...