Jump to content
didhavn

Remove "New" Button from Pages List-View

Recommended Posts

Hey All.

I need some help with a problem relating to users permissions to create pages and selectively remove a "new" button.
I have a container page called "Sektionen" to keep Sektions of pages. These sections are created within different pages via a pagetable field. Now I want to change the way new sections can be created in a way that they can ONLY be created via the pagetable-field, not via the "new" button in the pages tree (see screenshot - this button should be removed).

I think I can not change this in the templates settings and wanted to ask if anybody of you has an idea how to accomplish that?

Thanks a lot!

Unbenannt.JPG

Share this post


Link to post
Share on other sites

Not an answer to your question. Just pointing out a coincidence that an almost identical question was asked within the hour. Anyway, I am cross-referencing the two threads:

 

Share this post


Link to post
Share on other sites

I think you can probably do what you want by hooking into: ProcessPageListActions::getActions but unless you have a need to keep the Sektionen branch visible, I think the easiest option is to move it under the Admin branch where non-superusers won't have access to edit it.

  • Like 1

Share this post


Link to post
Share on other sites
5 hours ago, adrian said:

I think the easiest option is to move it under the Admin branch where non-superusers won't have access to edit it

IMHO this should be the default behaviour of a PageTable field. Having the PageTable pages as children of the page is confusing for editors and I've never understood the reasons why that should happen as the default.

Share this post


Link to post
Share on other sites
16 hours ago, adrian said:

I think the easiest option is to move it under the Admin branch where non-superusers won't have access to edit it.

But if it moved under the Admin branch the urls of the pages created via PageTable will include the /admin/ or no?

Share this post


Link to post
Share on other sites
Just now, PWaddict said:

But if it moved under the Admin branch the urls of the pages created via PageTable will include the /admin/ or no?

Yes - so it's only an option if you don't want the pages accessible directly, which is usually (although not always) the case with PageTable child pages.

Share this post


Link to post
Share on other sites
16 hours ago, adrian said:

I think you can probably do what you want by hooking into: ProcessPageListActions::getActions.

So I guess the only option is this but unfortunately I don't have the knowledge to do that hooking. Can you help if it's easy for you? All I want is to remove the "New" button from a specific page id.

Share this post


Link to post
Share on other sites

Something like this in your /site/init.php

$this->addHookAfter('ProcessPageListActions::getActions', null, function(HookEvent $event) {
    $p = $event->arguments[0];
    $actions = $event->return;
    if($p->template->name == 'aaa') {
        unset($actions['edit']);
    }
    $event->return = $actions;
});

Just replace the $p->template->name with your condition - whether it's a real template name, or change to $p->parent->id to get the parent of the page table items - whatever works best for you.

  • Like 3

Share this post


Link to post
Share on other sites
1 hour ago, adrian said:

Something like this in your /site/init.php


$this->addHookAfter('ProcessPageListActions::getActions', null, function(HookEvent $event) {
    $p = $event->arguments[0];
    $actions = $event->return;
    if($p->template->name == 'aaa') {
        unset($actions['edit']);
    }
    $event->return = $actions;
});

Just replace the $p->template->name with your condition - whether it's a real template name, or change to $p->parent->id to get the parent of the page table items - whatever works best for you.

THANK YOU :) Problem solved.

  • Like 1

Share this post


Link to post
Share on other sites
Just now, PWaddict said:

THANK YOU :) Problem solved.

Just be aware that this doesn't prevent someone from editing it if they manually enter the edit url. To prevent that you would need to hook into: Page::editable, but keep in mind that this will cause problems with the PageTable field being able to edit this pages (unless you also account for that), so I think what you have is likely the best compromise.

  • Like 1

Share this post


Link to post
Share on other sites
33 minutes ago, adrian said:

Just be aware that this doesn't prevent someone from editing it if they manually enter the edit url. To prevent that you would need to hook into: Page::editable, but keep in mind that this will cause problems with the PageTable field being able to edit this pages (unless you also account for that), so I think what you have is likely the best compromise.

I removed the "new" button not the edit one. Clients edit what they see in front of them so I doubt they will try to find that specific "new" url and enter it manually instead of just going to the PageTable page. I will also use your Restrict Tab View module to hide the children tab to avoid adding pages from there too.

Do you know if it's possible to also prevent loading the children pages on the page tree from that specific parent? The client should be able to see the total number of children pages next to it's parent but when they click on that parent it will NOT load the children pages.

Share this post


Link to post
Share on other sites

Sorry, I meant "new" whenever I wrote "edit". I spaced for a minute there :)

1 minute ago, PWaddict said:

Do you know if it's possible to also prevent loading the children pages on the page tree from that specific parent?

This starts getting a little more complicated. Have a read here: 

You can probably cobble something together from that thread and some of my linked gists.

  • Like 2

Share this post


Link to post
Share on other sites
14 minutes ago, adrian said:

Sorry, I meant "new" whenever I wrote "edit". I spaced for a minute there :)

This starts getting a little more complicated. Have a read here: 

You can probably cobble something together from that thread and some of my linked gists.

Ok thanks I will check them out.

Share this post


Link to post
Share on other sites

Hey.

I have a follow up question to this one:

Unfortunately, it is still possible for the user, to add pages via the "Children" tab in a page (see screenshot). I want to asure, that the user can create these Section-Pages only via the pagetable and not from somewhere else.

Do you know how to hook into this tab and remove/disable the button?

Thanks a lot!

Unbenannt.JPG

Share this post


Link to post
Share on other sites

Smart idea :-)

However, this module only works for non-superusers. I want to achieve this behaviour for all users including superuser. I just dont want anybody do mess with these pages.

You have a hint for me how to remove/disable this button OR remove the children tab for all users?

Share this post


Link to post
Share on other sites

Ok, fixed it using your RestictTabView module and just removed the two

71: if($this->user->isSuperuser()) return;
...
96: if($this->user->isSuperuser()) return;

cases :-)

Thanks a lot!!

  • Like 1

Share this post


Link to post
Share on other sites

No problem - don't forget to watch out for upgrades to the module :)

Btw, another approach to I think what you are looking for:

Currently it only works when the children and direct child pages, but it would be easy to customize to a different branch parent.

Maybe you prefer the approach you have and I think I agree with you for your use case, but this is just another option, maybe for a different project.

  • Like 1

Share this post


Link to post
Share on other sites

Great idea, this should be included (as default) into the module as it would fix almost all issues I had with pagwtables. 

Thanks! 

  • Like 2

Share this post


Link to post
Share on other sites

I tried this for a site, but the new button is still visible.

The template studbook can have a child with template animal. I have resticted a per page right edit rights for the studbook. On that page you can use the tab to add a new animal.

But all people can see the tree and now with every studbook there is a option for new. If this is not visible, only people with the right page rights you can add a child from the page...

I am using the current dev version of pw.

$this->addHookAfter('ProcessPageListActions::getActions', null, function(HookEvent $event) {
    $p = $event->arguments[0];
    $actions = $event->return;
    if($p->template->name == 'studbook') {
        unset($actions['new']);
    }
    $event->return = $actions;
});

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By SwimToWin
      The basic Processwire workflow assumes that I (as an Editor) want to save new Pages in draft mode - and therefore new pages are always set to unpublished by default. To publish the page, it is necessary to actively press "Publish", otherwise the Page will not be visible.
      The workflow is:
      Add new Page Status is now "Unpublished: Not visible on site." Press Publish - the page is now visible on site I want to publish pages right away (without having to press Publish).
      Where is that configured?
      ProcessWire 3.0.123
      Uikit v3 admin theme (0.3.0)
    • By Harmen
      I want to add a few pages to an AsmSelect Page field inside a repeater using the following code:
      $trialsPage = wire("pages")->get(28422); // Get the page $trialsPage->of(false); $newTrial = $ordersPage->trial_repeater_orders->getNewItem(); // Add item to repeater foreach ($selectedProducts as $selectedProduct){ $productPage = $pages->get("template=product, reference=$selectedProduct"); $newTrial->trial_selected_products->add($productPage); } $newTrial->save(); $trialsPage->save(); However, when I check the page where the field is located it doesn't have the new values as expected. The selected pages exist, the field is in the right location, made sure that the output formatting is turned off: $page->of(false); But it still doesn't work with a variable. No matter what I try, it doesn't work.
      It only works when I replace $selectedProduct with a hardcoded string. Am I doing something wrong here?
    • By David Karich
      The Page Hit Counter module for ProcessWire implements a simple page view counter in backend. Page views of visitors are automatically tracked on defined templates, with monitoring of multiple page views. This gives you a quick overview of how many visitors have read a news or a blog post, for example, without first having to open complex tools such as Google Analytics. This module quickly provides simple information, e.g. for editors. Or, for example, to sort certain news by most page views. For example for "Trending Topics".

       
      Works with ProCache and AdBlockers. With a lightweight tracking code of only ~320 bytes (gzipped). And no code changes necessary! In addition GDPR compliant, since no personal data or IP addresses are stored. Only session cookies are stored without information. 
      In addition, there are some options, for example filtering IP addresses (for CronJobs) and filtering bots, spiders and crawlers. You can also configure the lifetime of the session cookies. Repeated page views are not counted during this period. It is also possible to exclude certain roles from tracking. For example, logged in editors who work on a page are not counted as page views.

      Sort by hits and access page views (hit value)
      Each trackable template has an additional field called phits. For example, you want to output all news sorted by the number of page views.
      // It is assumed that the template, e.g. with the name "news", has been configured for tracking. $news = $pages->find("template=news, sort=-phits"); To output the page views of a tracked page, use:
      echo $page->phits; Example: Tracking a page hit via API and jQuery
      If you want to track a template that does not represent a full page to automatically inject a tracking script, you can define allowed API templates in the module that you can track. Below is an example of how you can track a click on news tag using jQuery. This will allow you to find out which keywords are clicked the most. For example, you can sort and display a tag cloud by the number of hits. Suppose your keywords have the template "news_tag". The template "news_tag" was also configured in the Page Hit Counter Module as a trackable API template.
      Example PHP output of keywords / tags:
      // Required: the data attribute "data-pid" with the ID of the template to be tracked. echo $pages->find("template=news_tag, sort=-phits")->each("<a href='{url}' class='news_tag' data-pid='{id}'>{title}</a>"); Example Tracking Script with jQuery:
      /** * Required: Data attribute "data-pid" with the ID of the news tag template * Required: Send the POST request to the URL "location.pathname.replace(/\/?$/, '/') + 'phcv1'" * Required: The POST parameter "pid" with the ID of the template */ $(function(){ if($('a.news_tag').length > 0) { $('a.news_tag').each(function(){ var tPID = $(this).data("pid"); if(tPID) { $(this).on("click", function(){ $.post(location.pathname.replace(/\/?$/, '/') + 'phcv1', {pid: tPID}); }); } }); } }); So simply every click on a tag is counted. Including all checks as for automatic tracking. Like Bot Filtering, Session Lifetime, etc.
      _______________________________________________________
      Background: This module is the result of a customer requirement, where the editors are overwhelmed with analytics or no tracking tools were allowed to be used. However, a way had to be found to at least count page views in a simple form for evaluations. Furthermore, by using ProCache, a way had to be found to count views of a page without clearing the cache.
      _______________________________________________________
      Pros
      Automatic Page View Tracking Lightweight tracking code, only ~320 bytes (gzipped) No code or frontend changes necessary Works with ProCache! Even if no PHP is executed on the cached page, the tracking works Works with browser AdBlockers No cache triggers (for example, ProCache) are triggered. The cache remains persistent GDPR compliant, session-based cookie only, no personal information Filtering of IPs and bots possible Exclude certain roles from tracking Ability to reset Page Views Works with all admin themes Counter database is created as write-optimized InnoDB API to track events for templates that are not viewable No dependencies on libraries, pure VanillaJS (Automatic tracking script) Works in all modern browsers Pages are sortable by hits Cons
      Only for ProcessWire version 3.0.80 or higher (Requires wireCount()) Only for PHP version 5.6.x or higher No support for Internet Explorer <= version 9 (Because of XMLHttpRequest()) No historical data, just simple summation (Because of GDPR) Planned Features / ToDos
      API access to hit values Since version 1.2.1 Possibility to sort the pages by hits (Request by @Zeka) Since version 1.2.0 Don't track logged in users with certain roles (Request by @wbmnfktr) Since version 1.1.0 Possibility to reset the counter for certain pages or templates (Request by @wbmnfktr) Since version 1.1.0 Better bot filter Since version 1.1.0 Disable session lifetime, don't store cookies to track every page view (Request by @matjazp) Since version 1.2.1 Option to hide the counter in the page tree (Request by @matjazp) Since version 1.2.1 Option to hide the counter in the page tree on certain templates Since version 1.2.1 API to track events for templates that are not viewable Since version 1.2.2 Changelog
      1.2.3
      Bug-Fix: Tracking script triggers 404 if pages are configured without slash (#3) Reported by @maxf5 Enhancement: Reduction of the tracking script size if it's gzipped (~320 bytes) Enhancement: Documentation improvement Enhancement: Corrected few typos 1.2.2
      New feature: API to track events for templates that are not viewable Enhancement: Documentation improvement 1.2.1
      API access to hit values Use $page->phits Bug-Fix: No tracking on welcomepage (Reported by wbmnfktr; Thx to matjazp) Bug-Fix: Tracking script path on subfolders (Reported by matjazp) Bug-Fix: Tracking on pages with status "hidden" Enhancement: Change database engine to InnoDB for phits field Enhancement: Option to disable session lifetime set session lifetime to 0, no cookies Enhancement: Better installation check Enhancement: AJAX Request asyncron Enhancement: Reduction of the tracking script size by ~20% Enhancement: Option to hide the counter in the page tree You can output the counter with the field name "phits" Enhancement: Option to hide the counter in the page tree on certain templates Enhancement: Option for activate general IP validation Enhancement: Reduction of tracking overhead up to ~30ms Enhancement: Better bot list for detection 1.2.0
      New feature: Sort pages by hits – New field phits Migrate old counter data to new field 1.1.0
      New feature: Exclude tracking of certain roles New feature: Reset Page Views Better bot filter and detection 1.0.0
      Initial release Notes
      By default, the page views are stored as INT in the database. This allows a maximum counter value of 4.2 billion views (4,294,967,295) per page. If you need more, change the type to BIGINT directly in the database. But I recommend to use Google Analytics or similar tools if you have such a large number of users.
      _______________________________________________________
      Download GitHub: ProcessWire Page Hit Counter (Version 1.2.3)
      PW Module Directory: ProcessWire Page Hit Counter (Version 1.2.3)
      Install via ProcessWire (Classname): PageHitCounter
      _______________________________________________________
      Update information
      If you have used version 1.2.1 from the DEV branch, please replace it completely with the new master version.
    • By SwimToWin
      I have a website that allows users to create their personal "website" (a page with sub-pages).
      Users shall be able to:
      Log in (frontend and/or admin), Edit "their" page(s) - I am using the "Page Edit Per User"-module (https://modules.processwire.com/modules/page-edit-per-user/) to grant access to the relevant pages Create child pages - possible? Users shall not be able to see other pages in the admin interface - "Admin Restrict Page Tree" may do the trick (https://modules.processwire.com/modules/admin-restrict-page-tree/)? Frontend editing shall be possible - I am considering "Fredi" (https://modules.processwire.com/modules/fredi/) for this. The challenge is that it takes a lot of modules and configuration.
      Is there a way to set this up that doesn't require a lot of configuration for each new user?
    • By benbyf
      not sure why but PW adds any uploads as permissions 600 (e.g. images wont load after upload unless i go in with the same server user and change permissions to 755 or similar). This ever happened to any one else?
×
×
  • Create New...