Jump to content

bcartier

Members
  • Posts

    107
  • Joined

  • Last visited

  • Days Won

    1

bcartier last won the day on July 21 2016

bcartier had the most liked content!

Profile Information

  • Gender
    Not Telling
  • Location
    Canada

Recent Profile Visitors

5,141 profile views

bcartier's Achievements

Sr. Member

Sr. Member (5/6)

100

Reputation

2

Community Answers

  1. Love this module, but I'm concerned about the speed. In my tests, a native template returning the same records and data as the GraphQL endpoint: Returning 20 pages and some details about page references: Native Template: 0.4s GraphQL Endpoint: 3.2s Is this performance something that could still be improved?
  2. This is a fantastic module! Thank you Nurguly! Does this handle Language fields yet? For example, I have translated titles, summaries for an "article" template, and I've allowed the article template, along with the "title" and "summary" fields in the module settings, but the the translatable fields are still not available through GraphiQL, even though the other non-translatable fields are.
  3. Thanks AndZyk! I had the feeling I was missing something obvious . I didn't see it in the cheat sheet and assumed it wasn't available.
  4. I'm wondering why there isn't a way to access published_date from the templates... I've seen Ryan comment to other questions about this that they should use 'created', but it seems to me they are not the same. For example, we have a team writing articles. We might have a page that's first created in October (saved without publishing), and isn't published until November. In these cases the created and published dates are a month apart. If I want to do something like turn off the comment form in the article template for articles published more than 6 months ago, what are my options for doing that accurately? Is there a reason published date has been excluded from the PW api?
  5. Sorry Mike - I built it based on v3. I'll see if I can get it working for 2.8...
  6. My main focus was to reducing visual clutter and to add whitespace to help convey hierarchy, grouping and meaning of elements. I'd like to extend this theme to prove several colour combinations (like AdminThemeDefault does). I went with this colour scheme hoping it might tie in nicely with the proposed redesign of the processwire.com website (especially the dark concepts)
  7. I've been working on a version of the core theme based on some proposals in the forums on a new processwire.com design. It's entirely derived from the default theme and inspired by ideas around a new ProcessWire look and feel. I wanted something that I'd be proud to show clients, and something that could draw developers to ProcessWire who might have been turned off by the default admin UI. This was created by working from the default theme, and developed organically over time. It's not coded in the most efficient way, but I hope it's useful for some of you. I'd love to see a cleaner look in the default theme. Ryan, if you see anything you like, please steal it! Likewise if you see anything you think could be improved, I'm all ears. -Brent AdminThemeSubtle.zip
  8. I also think a split button is a more familiar choice of the UI
  9. apeisa: each matrix block (a set of fields defined when creating a matrix field) is it's own table and each field within the Matrix block is a column. It's very easy to query values using their API - similar to ProcessWire's subfields via Page References.
  10. I've used Craft on a number of projects. I agree that PW is far ahead in many ways, but they are really pushing the envelope with the Matrix field and the Live Preview. I think Craft's Live Preview hits a sweet spot between front-end editing and structured content. I really think this is the best of both worlds. I'm hoping that the front-end editing that's coming with ProcessWire 3.0 moves more in that direction actually. I think it really helps clients understand the structures they're building and gives them confidence as they're editing before committing a change. PageTable Extended technically accomplishes what Matrix does - but the UI isn't strong enough to actually use it yet (in my opinion). I tend to use ProcessWire unless the client needs Drafts/Revisions or in cases where Matrix solves a publishing challenge that would be muddy or over-complicated in ProcessWire (from a UI perspective).
  11. There seems to be a problem with loading required javascript files for inputfields when a field is loaded via AJAX. For example, if I set the visibility of an Page reference field that uses asmSelect, the inputfield UI doesn't load (it's just a plain multi-select) and I'm seeing a JS error "$select.asmSelect is not a function". When ajax loads the fieldtype, it seems as though it's not loading jquery.asmselect.js Do these core inputfields need to be updated? How to write new inputfields so that the required js in included correctly when the field is loaded by AJAX? Has anyone found a solution to this? Thanks guys! -Brent edit: here's the announcement about these new AJAX options. It says that "The AJAX-driven features should now work with all core input fields (yes, even including files/images, repeaters (!), PageTable, asmSelect, and so on)." but it's not working for me in the Reno, or default theme. I'm working with the latest dev version of PW (2.6.17)
  12. Having some experience with ExpressionEngine, Craft CMS, Drupal, WordPress and (luckily) ProcessWire, I find Ryan's approach to ProModules to be a smart and effective solution. With product exposure and attention comes a market. That market can be 3rd party commercial modules, or first-party modules. Personally, I'd much prefer a first-party module for something at tightly integrated as Drafts. I think this is an evolutionary step for ProcessWire, and a positive one. If a project requires the workflow or functionality that ProDrafts offers, I think the small price is beyond reasonable. If you have a few publishers, and this module saves them a few minutes /day, it's paid for itself pretty quickly. I hope Ryan continues on this course. I don't see it detracting from the core product at all - in fact the opposite. As more Pro modules have been released, the pace of core development has spiked. All-in-all a good thing in my opinion. Sponsored development is a great contribution too (thanks Apeisa and Avoine!), but Pro Modules are also a great way to push PW forward.
  13. Thanks LostKobrakai - I'll explore that option too and see what works best.
  14. I decided on Page::render because this site has a lot of internal urls stored in fields and output via templates that also need to carry the segment. There's also a large, sitemap-style menu that uses the $cache feature, and I didn't want to cache every variation. This way I can cache the large menu aggressively, and use replacements when rendering.
  15. No problem. Here's the module I put together: <?php class SiteFilter extends WireData implements Module { /** * getModuleInfo is a module required by all modules to tell ProcessWire about them * * @return array * */ public static function getModuleInfo() { return array( // The module'ss title, typically a little more descriptive than the class name 'title' => 'Site Filter', // version number 'version' => 1, // summary is brief description of what this module is 'summary' => 'Add the current filter value as urlSegment1 for all internal links.', // singular=true: indicates that only one instance of the module is allowed. // This is usually what you want for modules that attach hooks. 'singular' => true, // autoload=true: indicates the module should be started with ProcessWire. // This is necessary for any modules that attach runtime hooks, otherwise those // hooks won't get attached unless some other code calls the module on it's own. // Note that autoload modules are almost always also 'singular' (seen above). 'autoload' => true ); } /** * Initialization function. This is where we'll attach our hooks. * */ public function init() { // minify page markup automatically wire()->addHookAfter("Page::render", $this, "addSegment1"); } public function isExternal($url) { $components = parse_url($url); if ( empty($components['host']) ) return false; // we will treat url like '/relative.php' as relative if ( strcasecmp($components['host'], wire('config')) === 0 ) return false; // url host looks exactly like the local host return strrpos(strtolower($components['host']), '.' . wire('config')->httpHost) !== strlen($components['host']) - strlen('.' . wire('config')); // check if the url host is a subdomain } /** * addSegment1 * * We have a session variable we'd like to append to all internal urls to persist site filters when * bookmarking, and sharing urls. This also allows filtered pages to be cached. Each template needs * to have segments enabled, and we use a regex value for allowed segments to prevent a runaway * cache. * @param HookEvent $event */ public function addSegment1(HookEvent $event) { // let's not mess with the back-end urls $cur_page = $event->object; if($cur_page->template == "admin") return; // Let's not pollute the page with domDocument warnings libxml_use_internal_errors(true); // event return value contains rendered markup $markup = $event->return; $currentFilter = wire('session')->settings_filter; if ($currentFilter == "") return; // we don't want to attempt minifying markup unless it's actually HTML if (strpos($markup, "<html") === false) return; $dom = new domDocument; $dom->loadHTML($markup); $dom->preserveWhiteSpace = false; $links = $dom->getElementsByTagName('a'); foreach($links as $link){ $url = $link->getAttribute('href'); $external = $this->isExternal($url); if($external === false){ if(strpos($url, $currentFilter) === false){ $url .= $currentFilter . "/"; $link->setAttribute("href", $url); } } } $newMarkup = $dom->saveHTML(); $event->return = $newMarkup; } }
×
×
  • Create New...