Jump to content

Robin S

  • Content Count

  • Joined

  • Last visited

  • Days Won


Robin S last won the day on January 5

Robin S had the most liked content!

Community Reputation

7,331 Excellent

About Robin S

  • Rank
    Hero Member

Profile Information

  • Gender
  • Location
    New Zealand

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. My comments are about styling the admin, and that's done with CSS. I think you might be talking about making changes to the admin markup - or do I have that wrong?
  2. Sure, the admin theme could make this sort of thing easier. But it's not excessively difficult to tweak the styling now if a person is motivated. When people make comments or requests about the admin theme styling (not just in recent topics but in the forum generally) I'm never sure if they realise that they don't need to wait for Ryan to do something in order to get what they want. It's CSS101 stuff.
  3. Exactly. I doubt we're going to all agree on all details of how the admin theme should look. But I hope that nobody among us is sitting there gritting their teeth because the admin isn't looking how they want it to look. Because we're all website designers/developers and we know how Cascading Style Sheets work (especially the cascading part). And it's not a difficult task to add your own CSS to the admin and override the styling of elements as you like. The admin theme markup changes very rarely and so you can spend half an hour working out your overrides for colours or whatever and then reuse those styles on all projects going forward. If you compile your overrides from SCSS/LESS then it's really easy to tweak colours for specific projects via variables.
  4. Are you doing something like adding the Justify plugin yourself? If so, you don't need to do that because it's already included in PW's InputfieldCKEditor by default. You can specify the individual justify toolbar items you want:
  5. This post might help you: Specifically the Page::editable and Page::addable hookable methods.
  6. My understanding is that there are three hookable methods that you can use if you want detailed control of which pages are viewable, editable and "listable". Viewable = user may view the page on the front-end. Example hook in /site/init.php: $wire->addHookAfter('Page::viewable', function(HookEvent $event) { $page = $event->object; // Return early if PW has determined that the page is not viewable if(!$event->return) return; // Your test here... if($page->title === 'foo') { // User may not view the page $event->return = false; } }); Editable = user may edit the page in ProcessPageEdit. Example hook in /site/init.php: $wire->addHookAfter('Page::editable', function(HookEvent $event) { $page = $event->object; // Return early if PW has determined that the page is not editable if(!$event->return) return; // Your test here... if($page->title === 'foo') { // User may not edit the page $event->return = false; } }); Listable = user can see the page in ProcessPageList. Note: superusers are not affected. Example hook in /site/init.php: $wire->addHookAfter('Page::listable', function(HookEvent $event) { $page = $event->object; // Return early if PW has determined that the page is not listable if(!$event->return) return; // Your test here... if($page->title === 'foo') { // User may not see the page in ProcessPageList // And therefore may not see its descendant pages either $event->return = false; } }); There's a catch to be aware of with this last hook. Page::listable only affects ProcessPageList and not other parts of the admin. If the existence or title of the page must remain private then you'll need to handle the following separately: Admin search (AJAX results) Admin search (results page if user hits enter) Lister (aka "Find") Maybe other places such as Page Reference fields I think @adrian has some experience with hiding pages from these places and might have some suggestions. Edit: In my opinion it would be nice if PW used Page::listable to automatically restrict the visibility of pages throughout the admin. I opened a request here: https://github.com/processwire/processwire-requests/issues/379 Besides Page::viewable, Page::editable and Page::listable there are also the following hookable methods that can be used in a similar way to the examples shown above. All of these methods are in PagePermissions.module. Page::publishable Page::deleteable (aka Page::deletable) Page::trashable Page::restorable Page::addable Page::moveable Page::sortable
  7. @Brian Scramlin, to use WireArray::sort I think the items in the WireArray need to be Wire-derived objects, e.g. WireData. Relevant API documentation: https://processwire.com/api/ref/functions/wire-data/ https://processwire.com/api/ref/functions/wire-array/ Demo:
  8. The json_decode() function has an "associative" argument that you can set to true: $meevo_response_array = json_decode($meevo_response, true); Or you can use the core wireDecodeJSON() function which does this automatically. $meevo_response_array = wireDecodeJSON($meevo_response);
  9. I think you're better off not using FieldtypeCache. See this issue for some discussion: https://github.com/ryancramerdesign/ProcessWire/issues/1577 And I remember Ryan commenting somewhere that he's thinking of removing it from the core. The simplest thing if you want to merge multiple fields into a single field for search purposes is to use the SearchEngine module. Or if you want to go more hands-on it's not difficult to populate a hidden "index" textarea field from other field values using a Pages::saveReady hook. $pages->addHookAfter('saveReady', function(HookEvent $event) { $page = $event->arguments(0); if($page->template == 'your_template') { $index = $page->title; if($page->body) $index .= ' ' . strip_tags($page->body); foreach($page->tags as $tag) $index .= ' ' . $tag->title; $page->index = $index; } });
  10. I don't know much about multilingual websites, but I think Page Reference fields are multilingual. And Page Reference fields are the most powerful way to implement tags anywhere in PW. Now that have the custom fields for Files/Images feature it seems like this would be a good solution.
  11. The title field is already optional. You just need to make it non-global by editing the Title field and unchecking the Global checkbox on the Advanced tab. Then you can remove it from any templates where you don't need it. If you want to see the values of other fields (instead of Title) in Page List you can set that on the Advanced tab when editing the template.
  12. @ryan, what follows is only about the idea of taking Repeater Matrix in a Bard-like direction for long-form content, as referred to in my earlier post. I don't have an opinion on the "builder" idea because it's not something I or my clients need. Looking at the Bard video you can imagine it as rich text field (i.e. CKEditor or maybe Editor.js) with Repeater Matrix elements distributed through it. You can add new Matrix items and edit them within the rich text interface. Here's a mockup of what a hypothetical "Repeater Matrix Bard" field might look like: But as far as I can see such an interface would be very difficult to implement. You'd have to somehow replicate the Matrix item interface inside CKEditor or Editor.js, maybe as plugins. [Actually, as soon as I made this mockup I suddenly had another idea for how it could be done, but I'll come back to that at the end of this post]. So when I first started thinking about this idea (back when Bard was introduced to Statamic) I wrote that option off as too difficult and turned to working with the existing CKEditor and Repeater Matrix fieldtypes. Of course this was going to involve compromises and the result was never going to be as slick as the Bard interface. My idea was to use placeholders for the Matrix items within the CKEditor field, in the form of CKEditor widgets. Each widget would correspond to a Matrix item, and a Textformatter module would replace the placeholders with rendered Matrix item output when the page is rendered for the front-end. This is easy to do via $matrix_page->render(). First I experimented with keeping the Matrix field visible in Page Edit, with the Matrix field in accordion mode. Hovering a widget placeholder in CKEditor highlighted the Matrix item (to help the user work out which placeholder is linked to which Matrix item) and clicking the widget scrolled to and opened the Matrix item for editing. But this takes the user away from CKEditor and disrupts the writing experience a bit too much. So then I changed to hiding the Matrix field in Page Edit so the user only sees the CKEditor field. When they add or edit a Matrix item a Magnific modal opens where they can work with the fields within the Matrix item. I added a dropdown to the CKEditor toolbar to let users add new Matrix items/widgets within the CKEditor field. This works okay but it's not fantastic - the main dissatisfaction I have is that my widgets are rather basic. This is because I'm no expert when it comes to CKEditor and its widget system. But looking at example widgets in a tutorial it seems that it's possible for them to have richer layouts and items like images (icons?) within them. I'm using the title attribute tooltip to show the text from the Matrix item header, but it would be great if the widget contained an icon corresponding to each Matrix type (sidenote: we really need a larger selection of icons available in the core) and perhaps some of the item content. Maybe the developer could specify code for each Matrix type that would render the HTML of the widget? I fear this is all beyond me but if you're interested maybe you could explore the possibilities of this? Or see if a similar approach would be more easily accomplished in Editor.js. A screencast of the system in action: Because the user doesn't see the Matrix field it would be possible for items to become orphaned there after their corresponding widgets are deleted from the CKEditor field. But it would be good to keep orphaned items for a short while to serve as disaster recovery. So perhaps orphaned Matrix items would be automatically removed after some period of time. Coming back now to the mockup screenshot and an idea of how to achieve it... What if there was a special rich text Matrix type available to be added to any Matrix field? This would consist of a CKEditor field in inline mode (to reduce the distraction of the toolbar) together with (optional) Files and Images fields to allow for linked files and embedded images (edit: it would be good if somehow a single Files field and a single Images field was shared between all rich text items). This matrix type would render differently within the Repeater Matrix inputfield - it wouldn't have a permanently visible header and the Files and Images fields wouldn't be permanently visible either. Instead a special toolbar would appear when the rich text item was hovered (probably at the bottom to avoid clashing with the CKEditor toolbar). This toolbar would include the standard Matrix icons (sort, copy, toggle, delete) and icons that make the Files and Images fields visible for when those need to be accessed. But when nothing is hovered it would render just as the rich text portions appear in my mockup. It would also be nice if the Matrix "add new" links were replaced by a "+" icon that appears when you hover between existing Matrix items, like in Bard. That would reduce some clutter in the inputfield and allow new items to be inserted in whatever position is wanted. This approach would not be quite as nice as a single rich text field containing Matrix items. Because I think the concept of multiple text fragments is not what users imagine for a long-form article. And it would result in more pages behind the scenes, although that probably isn't a big problem. But it seems like it might be relatively simple solution to the Bard idea.
  13. I didn't know about adding custom links here, thanks. 🙂 It's somewhat limited though because it can't handle URL segments or GET variables which are widely used in the admin, so you can't link to a module config for instance. My preference would be for a separate panel just for shortcut links, internal and external. The PageListSelect works well for pages but I think inputing URLs would be better because then it's one interface for entering any kind of link. Example: Just thinking out loud here, but when a link is added or changed it would be cool if... The root URL is removed from internal links so link becomes relative. If a URL is submitted without a label... For internal URLs, $pages->getByPath($url) is used, and if a Page object is returned the page title is used as the link label. For external URLs and internal URLs for which getByPath($url) returns a NullPage, attempt to get the title element using DomDocument and use it as the link label. libxml_use_internal_errors(true); $dom = new \DOMDocument(); $dom->loadHTMLFile($url); $list = $dom->getElementsByTagName('title'); $label = $list->length ? $list->item(0)->textContent : $url; These latter features aren't crucial, they're just so we have the option of being lazy and adding a URL only. 🙂
  14. It wouldn't be a bad thing to have a filter box too, although I don't think I'm familiar enough with the input labels to use that much myself. The Perfmon module looks good - I hadn't seen it before. Honestly these features aren't something I need on a typical project - I just thought the timeline looked cool. If I needed to focus in on performance I would try Perfmon, and I have Profiler Pro but haven't actually explored its features yet. I do have another idea/request though... What do you think about adding a Shortcuts panel? This would be for custom internal or external links that a user finds they are needing to visit regularly during development. For instance, I often need to visit the LoginRegisterPro config screen during development. And you could add links to various external API documentation pages that you want to jump to quickly. Sure, you could use your browser bookmarks but mine are already an out-of-control mess, and by having the links in a Tracy panel it would keep them nicely connected to a project. I'm imagining an interface that lets you enter a label and URL for each shortcut - a textarea would do, or you could get fancy with some kind of repeater-like interface. It would be good if absolute internal links were converted to relative links (i.e. strip out the site root from the URL) so the links keep working if the root URL changes.
  15. From an article @szabesz linked to earlier... No idea how difficult it would be to show a cool timeline like that, and probably something that would be better done in the Tracy core. But it looks nifty!
  • Create New...