Robin S

Members
  • Content Count

    2,779
  • Joined

  • Last visited

  • Days Won

    136

Robin S last won the day on August 23

Robin S had the most liked content!

Community Reputation

4,485 Excellent

4 Followers

About Robin S

  • Rank
    Hero Member

Profile Information

  • Gender
    Male
  • Location
    New Zealand

Recent Profile Visitors

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

  1. Robin S

    I think authors maintaining actions in their own repos is the way to go. I know from past experience that when tinkering around I often do several commits after I think I've done my "final commit" for a version as I spot little errors or think of new ideas. I wouldn't want to have to bother you or me with pull requests for these. Having a list of third-party actions in the readme sounds like a good idea, but I have another idea too. I think it would be cool if we could leverage the power of the modules directory and ProcessWireUpgrade for actions, so users can see when updates are available and easily pull those updates in. So the idea is that each third-party action that extends ProcessAdminActions would have its own "pseudo-module" - a module file containing just the required getModuleInfo() method. So for my action above the module folder would look like this: And ActionUnorderedListToPages.module would consist of this: <?php namespace ProcessWire; class ActionUnorderedListToPages extends WireData implements Module { public static function getModuleInfo() { return array( 'title' => 'Unordered List to Pages', 'description' => 'Creates a structure of new pages from an unordered list.', 'version' => '0.1.0', 'author' => 'Robin Sallis', 'href' => 'https://github.com/Toutouwai/ActionUnorderedListToPages', 'extends' => 'ProcessAdminActions' ); } } ProcessAdminActions would look for third-party actions like this... $third_party_actions = $this->wire('modules')->findByInfo('extends=ProcessAdminActions'); ...and then get the action by looking for an ".action.php" file in the module directory. ProcessAdminActions could hopefully grab the action title/description from getModuleInfo() rather than this needing to be duplicated inside the action file (but no big deal if that wont fly). So this would require coding some extra features in ProcessAdminActions but I think being able to use the modules directory would be really cool. And the exact details of how all this would work is up for discussion of course - this is just me brainstorming here. What do you think? I might be wrong but this sounds like it wouldn't work very reliably. Sitemaps generally just have the URL to the resource and that seems like it would problematic to parse into the desired page structure in many cases: There is no page title in an XML sitemap so pages would have to use the slug name as page title, which may not be that close to the desired title - so potentially requiring a lot of manual fixes later and not making the action much of a time-saver. Many sites don't have the tidy connection between URL and page structure that PW has - worst are ones like /index.php?id=1234&view=detail&foo=bar. I'm not sure what the action would be able to do with this. XML sitemaps often include entries for non-page resources such as PDF files. If you think the XML sitemap idea can work I'm happy to be proved wrong. Maybe you want to have a play around with it?
  2. Robin S

    An action that I made for my own convenience but that others might find useful too: Unordered List to Pages An action for the Admin Actions module for ProcessWire CMS/CMF. Creates a structure of new pages from an unordered list entered into a CKEditor field. The nesting of further unordered lists within the list will determine the nesting of the created pages. This can be useful to quickly create a page structure; especially so if you are rebuilding an existing non-ProcessWire site that has a Sitemap page that you can copy and paste from. All the created pages get the same template - for any pages that should use a different template you can easily change this as you edit the page to add content, or use the Page Manipulator action for bulk template changes. Usage Install the action by copying the "UnorderedListToPages" folder to /site/templates/AdminActions/, and then visiting the Admin Actions config screen and enabling the "Unordered List to Pages" action for the roles who are allowed to use it. Navigate to Admin Actions > Unordered List to Pages and fill out the config fields: Enter/paste an unordered list in the Source field. Select a parent page that the new pages will be created under. Select the template to use for the new pages. Execute the action. Screenshots Action config: Result: https://github.com/Toutouwai/UnorderedListToPages
  3. Robin S

    That's weird - the $wire API variable should be in scope there. Add the ProcessWire namespace to the top of /site/ready.php if it isn't there already. You are running PW 3.x right? And double-check the ready.php file is in the right place, in the /site/ folder and not in /site/templates/ or anything like that (I only mention it because it's happened before ). Your /site/ready.php file should look like this: <?php namespace ProcessWire; $wire->addHookAfter('Page::listable', function(HookEvent $event) { // Only for non-superusers if($this->user->isSuperuser()) return; // The ID of the page that Page List is listing children of $id = $this->input->get->int('id'); $page = $event->object; // Don't list pages with certain templates under Home (adjust template names as needed) if($id === 1 && ($page->template == 'internal_db' || $page->template == 'newsletter')) { $event->return = false; }; }); Here is more information about /site/ready.php: https://processwire.com/blog/posts/processwire-2.6.7-core-updates-and-more/#new-core-files-for-site-hooks
  4. Robin S

    It's possible your method that tries to get the array is firing before init() has fired. The Module docs say: So __construct() fires earlier. Where you choose populate the array would probably depend on whether you need to get any custom module config at that point. If you don't need the module config then populate the array in __construct(). But init() is early enough for most cases too. An example: <?php namespace ProcessWire; class TestModule extends WireData implements Module { public static function getModuleInfo() { return array( 'title' => "Test Module", 'version' => 1, ); } public $colours = array(); public function init() { $this->colours = array( 'Red', 'Orange', 'Yellow', ); } }
  5. Robin S

    When I tested those URLs, I only had to turn off HTML Purifier and the links remained in the field after page save. Leaving ACF on did not affect the links.
  6. Robin S

    Welcome to the forums. The structure of the page tree (Page List) always reflects the path to pages on the front-end. That fact is part of the ProcessWire philosophy that Ryan has talked about somewhere (can't remember where exactly). So you can't have the Home page appear anywhere other than at the root of the page tree. In terms of having a dashboard instead of Page List there are several forum topics that are relevant. A Google search will find them: https://www.google.com/search?q=site:processwire.com+dashboard And here is another approach you can try... 1. Install the AdminOnSteroids module, and use the "Add pages to navigation" feature to add your Internal DB and Newsletter pages as custom nav items. This will add those pages to the Pages menu so that if you click them you'll see only those sections in Page List. 2. Add a hook to /site/ready.php (add the file if it doesn't exist) so that your Internal DB and Newsletter pages do not appear in the main Page List, so they are not confusing to your users. $wire->addHookAfter('Page::listable', function(HookEvent $event) { // Only for non-superusers if($this->user->isSuperuser()) return; // The ID of the page that Page List is listing children of $id = $this->input->get->int('id'); $page = $event->object; // Don't list pages with certain templates under Home (adjust template names as needed) if($id === 1 && ($page->template == 'internal_db' || $page->template == 'newsletter')) { $event->return = false; }; });
  7. I had to handle this kind of validation in my AddImageUrls module, so the code there might be useful for anyone else needing to do the same: https://github.com/Toutouwai/AddImageUrls/blob/f67ebe9729fc54d629fe939be2f9d3e9c7f68c16/AddImageUrls.module#L118-L170
  8. Robin S

    You can achieve loads of different scrolling effects with a library like http://scrollmagic.io/ Example similar to what you are describing: http://scrollmagic.io/examples/basic/section_wipes_natural.html
  9. I don't think any of the image field settings are honoured by $pageimages->add(). Not "valid file extensions", not "maximum files allowed", not min/max width/height, etc. It's a shame as it means you have to do a lot of manual validation if using add().
  10. Robin S

    Right, I understand now. You are wanting to give a role (let's call the role "manager") the ability to edit roles/permissions and add new roles/permissions. First thing to know is that in doing this you would be going well off the map of what is documented in ProcessWire and straying into some potentially dangerous territory. Normally only superusers manage roles and permissions, and if you decide to deviate from that you'll want to do your own thorough testing. It sounds risky to me and not something to be done lightly. But I took a look at what's needed to enable this and it seems that the steps are... Manage roles 1. Create new permission "role-admin". 2. Give this permission to the manager role. 3. Open the "role" template at Setup > Templates (you'll need to show system templates in the filter section). On the Access tab allow the manager role to "Edit Pages" and "Add Pages". 4. Open the "admin" template, and on the Access tab allow the manager role to "Add Children". Manage permissions 1. Create new permission "permission-admin". 2. Give this permission to the manager role. 3. Open the "permission" template at Setup > Templates (you'll need to show system templates in the filter section). On the Access tab allow the manager role to "Edit Pages" and "Add Pages". 4. Open the "admin" template, and on the Access tab allow the manager role to "Add Children". You can skip this step if you already did it.
  11. Robin S

    It's explained in this blog post: https://processwire.com/blog/posts/new-user-admin-permissions-automatic-version-change-detection-and-more-2.6.10/#new-user-admin-permissions
  12. Robin S

    Hi Adrian, Does the "User dev template" feature do anything with _main.php if using the delayed output strategy? If not, what do you think about adding a feature where _main.php is replaced with _main-dev.php if that file exists? Of course the relevant file names would depend on what is defined in $config->appendTemplateFile and the Tracy "User dev template suffix" setting. And to round things out I guess do the same for $config->prependTemplateFile (_init.php).
  13. Robin S

    v0.1.10 released. Fulfilling a request by @adrian, if the currently edited page has children or the user may add children, a caret at the end of the breadcrumbs reveals a dropdown of up to the first 25 children and/or an "Add New" link.
  14. Robin S

    Great idea, thanks! Added in v0.1.8.
  15. Robin S

    Yes, it was an oversight. As more states need to be indicated in the dropdown items it gets harder to come up with distinguishable and tasteful styles for all of them. I think the hidden and unpublished pages need to use the same styling as in Page List, so that means I've had to change the styling for uneditable pages - these are now indicated by italics and reduced opacity (and the "not-allowed" cursor for devices that support hover). Other changes introduced in v0.1.7: The dropdowns now take $page->listable into account, so non-listable pages do not appear in the dropdowns. There is now a hookable BreadcrumbDropdowns::getSiblings method in case anyone wants to override the listed siblings for a page. This won't be needed in most cases though.