Jump to content
adrian

Admin Actions

Recommended Posts

Thanks for the report @szabesz - I have now overwritten the PHP time limit for these actions, so that should take care of your timeout issues.

Regarding the duplicate names problem - I have committed a new version which adds logic to check for duplicate usernames and also checks against users already in the system. This all occurs before it adds any users, so it should make for a much nicer experience.

If you have a chance to test, please let me know how it goes.

 

Screenshot showing when duplicates are detected

59c175c1dfd54_ScreenShot2017-09-19at12_52_58PM.thumb.png.2e74b6df45584c9ea8dfb65e6d9f038e.png

 

Screenshot showing when existing users are detected

59c178405679d_ScreenShot2017-09-19at1_03_11PM.thumb.png.d75fe4b14fe020e7e12c3b34718b0190.png

  • Like 1

Share this post


Link to post
Share on other sites
On 9/19/2017 at 10:06 PM, adrian said:

If you have a chance to test, please let me know how it goes.

I'll get back to this on the weekend and report my findings. Thanks a lot as always!

  • Like 1

Share this post


Link to post
Share on other sites

@adrian I had some time to test the new version. My findings are:

  • usernames with space make the import fail with error (Unknown Selector operator). Previous version worked by trimming space from the beginning and from the end, and at the same time converting spaces to dash found in-between.  I did not notice the latter until now, so last time I got two users with dashes in them. At least now I know I need to fix those manually :P
  • I still got timeout issue with 134 users on MAMP Pro but 32 user were ok to import. Note that current version of MAMP is rather buggy, it might be related to that or it might not. I do not really know.
  • Otherwise duplicate user warnings were ok.

For the first time (and only for the very first time) I had an issue reverting back to a database backup after the failed user import because of spaces. I used the core Revert to Backup feature and afterwards the – local staging – site was throwing a lot of:

Warning: Invalid argument supplied for foreach() in .../site/assets/cache/FileCompiler/site/modules/TracyDebugger/TracyDebugger.module on line 1257

I tried clearing the cache directory but it did not help, things got worse, the site was brought down by:

User Error
Exception: You do not have permission to execute this module - ProcessPageView (in .../wire/core/Modules.php line 1236)
#0 .../wire/core/Modules.php(1141): ProcessWire\Modules->getModule('ProcessPageView')
#1 .../index.php(53): ProcessWire\Modules->get('ProcessPageView')

I replaced the database with the one from the production site and all was good afterwards. As I said, it happened only the first time, subsequent reverts in the admin did not produce this.

  • Like 1

Share this post


Link to post
Share on other sites

Thanks @szabesz - I have fixed the username issue in the latest version.

I am not sure what to do about the timeout - I used PHP's set_time_limit to remove the time limit - maybe it's a weird MAMP thing?

Not sure about the backup restore - I am using the core WireDatabaseBackup class to run the restore. Maybe let me know if you come across this again and I'll try to replicate.

Thanks!

  • Like 1

Share this post


Link to post
Share on other sites

Thanks @adrian!

43 minutes ago, adrian said:

I am using the core WireDatabaseBackup class to run the restore.

I have not yet tried your restore feature, I just made backups with ProcessDatabaseBackups and used those to restore the DB. Anyway, your action helped me a lot as I did not have to write a single line of code and all the users are imported :D Thank  you!

  • Like 1

Share this post


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

I have not yet tried your restore feature, I just made backups with ProcessDatabaseBackups and used those to restore the DB.

The automatic backup that occurs when you run an Admin Action is probably best restored with the "Restore" option from the Setup > Admin Actions > Restore menu item. That way you are restoring from just before the action was run giving the best chance of a clean undo.

3 minutes ago, szabesz said:

Anyway, your action helped me a lot as I did not have to write a single line of code and all the users are imported :D Thank  you!

You're welcome - thanks for helping to improve it - hopefully now it will be better for others also.

  • Like 1

Share this post


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

The automatic backup that occurs when you run an Admin Action is probably best restored with the "Restore" option from the Setup > Admin Actions > Restore menu item. That way you are restoring from just before the action was run giving the best chance of a clean undo.

I see, however when the process is aborted with error the only way to revert is to use something else, or am I mistaken? Also, first I tested the import process on my local environment in order to make sure it will probably work in production as well. Also, I always make batch changes to the production site around 5-6AM when actual users are very rare. Our VPS can be automatically restored in seconds provided I made a restore point in advance, of course. I'm always trying to be extra precautious :) 

Edited by szabesz
precautious :)

Share this post


Link to post
Share on other sites

Hi @adrian,

Is it possible to include a File field in an action for this module? What I have in mind is uploading a CSV that is then parsed and used as data in the action.

I saw that the Create Users action has a textarea field where you can paste data in CSV format so that is one alternative, but sometimes I think it would be easier to upload an existing CSV file. Ryan's ImportPagesCSV module makes use of a File field so I guess there is a way to use files temporarily in a Process module (I haven't looked into how). If Admin Actions doesn't already support this would you consider adding it?

Also, I noticed a couple of issues while exploring the module. On install I get a PHP notice:

2017-10-10_223844.png.cb9cd3584a9c676961c1ea7bfcedc2e5.png

And when I attempt to open the "Ftp Files To Page" action I get an error:

2017-10-10_223954.thumb.png.deb887e9348946d597366f9a7fbff0b2.png

Share this post


Link to post
Share on other sites

Hi @Robin S - I have fixed both those bugs you reported - thanks for that.

As far as using a File field - actions can use any PW code, so this is certainly possible. You could make use of a FieldtypeFile field using the same approach that Ryan uses in his ImportPagesCSV module, or you could use a Markup field and add a "manual" <input type="file" /> field - whatever you prefer really. I don't think the main code in AdminActions needs any adjustments to support these, but let me know if there is anything I can do.

  • Like 1

Share this post


Link to post
Share on other sites
protected function defineOptions() {

    return array(
        array(
            'name' => 'csv_upload',
            'label' => 'CSV upload',
            'description' => 'Upload a CSV file.',
            'type' => 'file',
            'extensions' => 'csv txt',
            'overwrite' => true,
            'maxFiles' => 1,
            'required' => true,
        )
    );

}

protected function executeAction($options) {

    // If there was a file uploaded (Pagefiles object)
    if(count($options['csv_upload'])) {
        // Get the file (Pagefile object)
        $file = $options['csv_upload']->first();
        // Parse the CSV data
        $handle = fopen($file->filename, 'r');
        $count = 0;
        while(($row = fgetcsv($handle)) !== false) {
            $count++;
            // Process each $row
            // ...
        }
        fclose($handle);
        // Delete the uploaded CSV file (or else you will get an error next time you upload)
        unlink($file->filename);

        $this->successMessage = "$count CSV rows were processed.";
        return true;
    } else {
        $this->failureMessage = 'Please upload a CSV file';
        return false;
    }

}

 

Edited by Robin S
Changed example to use fgetcsv for better handling of new lines within values
  • Like 1

Share this post


Link to post
Share on other sites

Hi @adrian, a few ideas for tweaks to AdminActions...

  • How about adding a $title option inside the action class? To specify a title rather than deriving it from the camel-case in the action class name. It doesn't look quite right if there is a capitalised acronym in the class name.
  • Maybe new actions should be automatically enabled for the superuser role? To save having to visit the module config and enable each manually.
  • The "Actions" tooltip appears when hovering any part of actions list in the module config (it comes from the title attribute on the inputfield wrapper). This is a bit distracting so maybe remove that?

2017-10-14_113927.png.8711288b5c302391e49690113a74ecfa.png

  • Like 2

Share this post


Link to post
Share on other sites

Hi @Robin S - thanks for those reports/ideas.

  • I have added a new $title variable to actions. This is optional, but recommended.
  • I have fixed the annoying "Actions" title on hover.

But, regarding having new actions automatically enabled for superusers, I am not so sure. I purposely don't enable any actions for anyone by default. There are a lot there and there will potentially be many more in the future. My thought is that the list could become overwhelming and many/most devs might actually prefer to just enable those that they will use on a semi-regular basis. That said, I am willing to hear more arguments from others in support of this :)

Cheers!

 

 

Share this post


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

I purposely don't enable any actions for anyone by default.

I thought all the bundled actions were enabled for superuser by default on install, but now I see that superuser is preselected for all the actions but this doesn't actually take effect until you save the module config.

Maybe that is intentional in Admin Actions, but in general I think that is something it's better to avoid. Users might navigate away without realising they need to save to confirm the settings on screen. And even if they later return to the module config, there is nothing to indicate that the settings they see on screen are not actually live. It can be a problem for the module dev too if you are expecting those default config values that show on screen to actually be available in the module. It's caught me out a few times in my own modules - I've learned now that a better approach is to define the config defaults in the construct() method so that the config that users see is what is actually in effect, right from the moment of install.

Anyway, I see where you're coming from regarding the activation of actions, although personally I don't see any downside to having all the actions active and listed on the Admin Actions page (for superusers) so they can be explored. It's the step of adding actions to the menu where I would be limiting it to just regularly-used actions. 

  • Like 2

Share this post


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

My thought is that the list could become overwhelming and many/most devs might actually prefer to just enable those that they will use on a semi-regular basis.

+1

Share this post


Link to post
Share on other sites

Just a quick update - I went to use the Email Batcher for the first time with a complex HTML template and realized that ACF and Purifier were getting in the way, so these are now disabled so now you can build complex email templates and preview them right in the CKEditor body field.

  • Like 1

Share this post


Link to post
Share on other sites

Hi @adrian,

I noticed that in the datatable that lists the actions (at Setup > Admin Actions) the title is not being taken from the $title variable. In the module config datatable it is working.

Config:
2017-11-28_210921.png.a73be47607a9d463a1f6f063a4309e8b.png

Setup > Admin Actions:
2017-11-28_210935.png.4cb982088a63c47a8ba6ab5b8b39b578.png

Share this post


Link to post
Share on other sites

Hi @Robin S - it's late here, so need to sleep, but quick questions - is this only a problem for custom "Site" actions? Is it fixed if you save the module config settings page?

Let me know and I'll sort it out in the morning.

  • Like 1

Share this post


Link to post
Share on other sites

This is a really minor issue so no hurry at all.

2 minutes ago, adrian said:

is this only a problem for custom "Site" actions

No, it affects all actions. I dumped the $info array in the getActionTitle() method and it seems there is no 'title' item present when the actions table is rendered at Setup > Admin Actions.

Share this post


Link to post
Share on other sites
8 hours ago, Robin S said:

This is a really minor issue so no hurry at all.

No, it affects all actions. I dumped the $info array in the getActionTitle() method and it seems there is no 'title' item present when the actions table is rendered at Setup > Admin Actions.

Something unusual going on here. This is what I see. You can tell I am at Setup > Admin Actions and a bd($info) on line 552 definitely contains a "title". Any chance you could trace it back to find why it's not working at your end please?

5a1d960a8a1e8_ScreenShot2017-11-28at8_59_06AM.png.8dd18411909afaa73875704cb0ef1236.png

  • Like 1

Share this post


Link to post
Share on other sites

Thanks Adrian, I have sussed it out now.

It's because changes to any of the things that make up the actions info don't get applied until the user revisits the module config page and saves.

What makes it confusing (and this is not a criticism of anything you have done - it's just the way PW treats module config values) is that the updated values are shown in the module config screen, they are just not actually applied. It's the same thing I was whinging about above. I think the PW module config system needs some way to visually indicate which values displayed on a module config screen are saved values and which are not. Because otherwise the expectation is that when you view the module config screen you are viewing actual applied values.

Share this post


Link to post
Share on other sites

Thanks for the follow up. 

One option is that I could parse the content off all "action.php" files when loading Setup > Admin Actions, but I want to prevent the need to parse all files every time that is loaded, or the Setup > Admin Actions submenu is triggered (assuming you have some actions checked to show in the submenu). That is why that page grabs the $info from the module config settings, rather than the action.php file. I think this is probably still a good idea. 

Correct me if I'm wrong, but the issue you are seeing is only because you created an action, save the config settings page, and then later added a $title but didn't save again after the change? If that's what happened, I don't think we need to worry too much about this - what do you think?

If you feel strongly about that other issue, I am willing to reconsider, or if you feel like submitting a PR with the changes you'd like to see.

Speaking of PRs, am I going to get one with some of your custom actions? If I don't get some soon, I think it's time to ditch all those author info fields - right now that table makes me look like an egomaniac :)

 

 

Share this post


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

Speaking of PRs, am I going to get one with some of your custom actions?

I will certainly contribute any actions that would be useful to others, but I only have two so far (the ones you see in my screenshot) and one is a work in progress. The first just an interface for uploading a CSV file, but I don't think this is useful as an action to bundle with the module because the action doesn't do anything by itself - it requires code to process the CSV lines, which would depend entirely on what the user wanted to do.

The second is part of an exploration of how to resize existing images to save on disk space. I have a lot of older sites from before client-side resizing was introduced, and users have uploaded massive images that waste a lot of disk space. I'd like to upgrade PW on these sites and then loop through all the oversized images and replace them with smaller versions. I've worked out how to do this, but again I don't think it makes for a useful action to share. Firstly, for a large list of images this should be broken into smaller jobs that run on a LazyCron (or maybe the new Tasker module) to avoid a timeout. And secondly this is a destructive process that has the potential to do a lot of harm if used incorrectly, so I wouldn't want to put this out there and maybe contribute to a disaster.

 

2 hours ago, adrian said:

Correct me if I'm wrong, but the issue you are seeing is only because you created an action, save the config settings page, and then later added a $title but didn't save again after the change? If that's what happened, I don't think we need to worry too much about this - what do you think?

Yes, that's what happened. No need to change from using the module config data to populate the table - I can understand why it wouldn't be good to parse all the files every time the list is loaded.

But as a more general issue I think that perhaps module developers should rethink how values are populated to the module config page. Currently nearly all modules, mine included, set default/fallback values for config inputfields by just setting the value for the inputfield as it is added to getModuleConfigInputfields() (or one of the many equivalent methods for defining config inputfields). There is probably a tutorial somewhere that started this practice.

The problem with doing this is that when viewing the module config page, there is no way for the user to distinguish between values that are actually saved to the config and values that will be saved to the config if the config form is submitted. I'm sure I'm not alone in expecting that when I view the module config page I am seeing the config values that do exist, not ones that will exist if I submit the form.

Each time I think about this I get different ideas about what the best solution would be. Currently I'm thinking that we module developers should be saving the config values that we want to be the default config as part of the module install method. Then we don't set any default/fallback/other values in getModuleConfigInputfields() besides those coming from the saved module config. That way the user can have confidence that whatever they see in the module config page is data that actually exists in the saved config. And if the module does display config values that are not actually saved yet these should be highlighted in some way. Any thoughts on this?

  • Like 1

Share this post


Link to post
Share on other sites

@Robin S - no worries re your custom actions - I totally understand if they are not ready/relevant for public consumption.

I also understand where you're coming from regarding module default settings. Generally I don't find it an issue because if the settings page hasn't been saved, then the defaults will be used when running the module so effectively what the user sees is what they will get. But, there are exceptions, and this module is certainly one of them. I have a couple of others as well and I do a settings save on module install to solve this - maybe this should be the standard approach? I can't see any downsides, although I wonder if it is safe to actually remove defaults - what if the module was installed, but the settings db data fields was somehow emptied? I guess you'd have to uninstall and reinstall, but it might be a mess of notices in the meantime, but maybe that is ok as this is not a likely scenario.

Not sure how to get everyone on this page though?

 

  • Like 1

Share this post


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

have a couple of others as well and I do a settings save on module install to solve this

It would be good if PW did this by default on module installation. Maybe there is some downside but I can't think of any situations where you want the module config data to look populated (by setting default inputfield values) but not actually be populated.

1 hour ago, adrian said:

I wonder if it is safe to actually remove defaults - what if the module was installed, but the settings db data fields was somehow emptied? I guess you'd have to uninstall and reinstall, but it might be a mess of notices in the meantime

Default values could/should still be set in the construct method so there wouldn't be any notices necessarily. But if the config data was removed from the DB then the config page would appear empty despite default values still being used, which is a different kind of misleading I guess.

I'll ponder it some more.

  • Like 1

Share this post


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

I think it's time to ditch all those author info fields - right now that table makes me look like an egomaniac

Please do not! Don't be like Apple who keeps removing useful features from the system :P Jokes aside, this module has not yet received the attention it deserves but things can improve any time. For example as soon as I have the time to implement something useful I will surely contribute.

  • Like 1

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 Robin S
      After forgetting the class name of the wonderful AdminPageFieldEditLinks module for what feels like the 100th time I decided I needed to give my failing memory a helping hand...
      Autocomplete Module Class Name
      Provides class name autocomplete suggestions for the "Add Module From Directory" field at Modules > New.
      Requires ProcessWire >= v3.0.16.
      Screencast

      Installation
      Install the Autocomplete Module Class Name module.
      Configuration
      Choose the type of autocomplete options list: "Module class names from directory" or "Custom list of module class names". The latter could be useful if you regularly install some modules and would prefer a shorter list of autocomplete suggestions. The list of class names in the modules directory is generated when the Autocomplete Module Class Name module is installed. It doesn't update automatically (because the retrieval of the class names is quite slow), but you can use the button underneath when you want to retrieve an updated list of class names from the directory. The "fuzzy search" option uses custom filter and item functions for Awesomplete so that the characters you type just have to exist in the module class name and occur after preceding matches but do not need to be contiguous. Uncheck this option if you prefer the standard Awesomplete matching. Custom settings for Awesomplete can be entered in the "Awesomplete options" field if needed. See the Awesomplete documentation for more information.  
      https://github.com/Toutouwai/AutocompleteModuleClassName
      https://modules.processwire.com/modules/autocomplete-module-class-name/
    • By teppo
      MarkupMenu is a markup module for generating menu trees. When provided a root page as a starting point, it generates a navigation tree (by default as a HTML "<ul>" element wrapped by a "<nav>" element) from that point onwards. If you've also provided it with current (active) page, the menu will be rendered accordingly, with current item highlighted and items rendered up to that item and its children (unless you disable the "collapsed" option, in which case the full page tree will be rendered instead).
      Modules directory: https://modules.processwire.com/modules/markup-menu/ GitHub repository: https://github.com/teppokoivula/MarkupMenu Usage
      As a markup module, MarkupMenu is intended for front-end use, but you can of course use it in a module as well. Typically you'll only need the render() method, which takes an array of options as its only argument:
      echo $modules->get('MarkupMenu')->render([ 'root_page' => $pages->get(1), 'current_page' => $page, ]); Note: if you omit root_page, site root page is used by default. If you omit current_page, the menu will be rendered, but current (active) page won't be highlighted etc.
      A slightly more complex example, based on what I'm using on one of my own sites to render a (single-level) top menu:
      echo $modules->get('MarkupMenu')->render([ 'current_page' => $page, 'templates' => [ 'nav' => '<nav class="{classes} menu--{menu_class_modifier}" aria-label="{aria_label}">%s</nav>', 'item_current' => '<a class="menu__item menu__item--current" href="{item.url}" tabindex="0" aria-label="Current page: {item.title}">{item.title}</a>', ], 'placeholders' => [ 'menu_class_modifier' => 'top', 'aria_label' => 'Main navigation', ], 'include' => [ 'root_page' => true, ], 'exclude' => [ 'level_greater_than' => 1, ], ]); Note: some things you see above may not be entirely sensible, such as the use of {menu_class_modifier} and {aria_label} placeholders. On the actual site the "nav" template is defined in site config, so I can define just these parts on a case-by-case basis while actual nav markup is maintained in one place.
      Please check out the README file for available render options. I'd very much prefer not to keep this list up to date in multiple places. Basically there are settings for defining "templates" for different parts of the menu (list, item, etc.), include array for defining rules for including in the menu and exclude array for the opposite effect, classes and placeholders arrays for overriding default classes and injecting custom placeholders, etc. 🙂
      MarkupMenu vs. MarkupSimpleNavigation
      TL;DR: this is another take on the same concept. There are many similarities, but also some differences – especially when it comes to the supported options and syntax. If you're currently using MarkupSimpleNavigation then there's probably no reason to switch over.
      I'd be surprised if anyone didn't draw lines between this module and Soma's awesome MarkupSimpleNavigation. Simply put, I've been using MSN (...) for a number of years, and it's been great – but there have been some smallish issues with it, particularly with the markup generation part, and it's also doing some things in a way that just doesn't work for me – the xtemplates thing being one of these. In many ways it's less about features, and more about style.
      In MarkupMenu I've tried to correct these little hiccups, modernise the default markup, and allow for more flexibility with placeholder variables and additional / different options. MarkupMenu was built for ProcessWire 3.0.112+ and PHP 7.1+, it's installable with Composer, and I have a few additional ideas (such as conditional placeholders) on my todo list.
      One smallish and rather specific difference is that MarkupMenu supports overriding default options via $config->MarkupMenu. I find myself redefining the default markup for every site, which until now meant that each site has a wrapper function for MarkupSimpleNavigation (to avoid code / config repetition), and this way I've been able to omit that 🙂
      Requirements
      ProcessWire >= 3.0.112 PHP >= 7.1.0 If you're working on an earlier version of ProcessWire or PHP, use MarkupSimpleNavigation instead.
    • By Robin S
      Repeater Images
      Adds options to modify Repeater fields to make them convenient for "page-per-image" usage. Using a page-per-image approach allows for additional fields to be associated with each image, to record things such as photographer, date, license, links, etc.
      When Repeater Images is enabled for a Repeater field the module changes the appearance of the Repeater inputfield to be similar (but not identical) to an Images field. The collapsed view shows a thumbnail for each Repeater item, and items can be expanded for field editing.
      Screencast

      Installation
      Install the Repeater Images module.
      Setup
      Create an image field to use in the Repeater field. Recommended settings for the image field are "Maximum files allowed" set to 1 and "Formatted value" set to "Single item (null if empty)". Create a Repeater field. Add the image field to the Repeater. If you want additional fields in the Repeater create and add these also. Repeater Images configuration
      Tick the "Activate Repeater Images for this Repeater field" checkbox. In the "Image field within Repeater" dropdown select the single image field. You must save the Repeater field settings to see any newly added Image fields in the dropdown. Adjust the image thumbnail height if you want (unlike the core Images field there is no slider to change thumbnail height within Page Edit). Note: the depth option for Repeater fields is not compatible with the Repeater Images module.
      Image uploads feature
      There is a checkbox to activate image uploads. This feature allows users to quickly and easily add images to the Repeater Images field by uploading them to an adjacent "upload" field.
      To use this feature you must add the image field selected in the Repeater Images config to the template of the page containing the Repeater Images field - immediately above or below the Repeater Images field would be a good position.
      It's recommended to set the label for this field in template context to "Upload images" or similar, and set the visibility of the field to "Closed" so that it takes up less room when it's not being used. Note that when you drag images to a closed Images field it will automatically open. You don't need to worry about the "Maximum files allowed" setting because the Repeater Images module overrides this for the upload field.
      New Repeater items will be created from the images uploaded to the upload field when the page is saved. The user can add descriptions and tags to the images while they are still in the upload field and these will be retained in the Repeater items. Images are automatically deleted from the upload field when the page is saved.
      Tips
      The "Use accordion mode?" option in the Repeater field settings is useful for keeping the inputfield compact, with only one image item open for editing at a time. The "Repeater item labels" setting determines what is shown in the thumbnail overlay on hover. Example for an image field named "image": {image.basename} ({image.width}x{image.height})  
      https://github.com/Toutouwai/RepeaterImages
      https://modules.processwire.com/modules/repeater-images/
    • By EyeDentify
      Hello There Guys.

      I am in the process of getting into making my first modules for PW and i had a question for you PHP and PW gurus in here.

      I was wondering how i could use an external library, lets say TwitterOAuth in my PW module.
      Link to library
      https://twitteroauth.com/

      Would the code below be correct or how would i go about this:
      <?PHP namespace ProcessWire; /* load the TwitterOAuth library from my Module folder */ require "twitteroauth/autoload.php"; use Abraham\TwitterOAuth\TwitterOAuth; class EyeTwitter extends WireData,TwitterOAuth implements Module { /* vars */ protected $twConnection; /* extend parent TwitterOAuth contructor $connection = new TwitterOAuth(CONSUMER_KEY, CONSUMER_SECRET, $access_token, $access_token_secret); */ public function myTwitterConnection ($consumer_key, $consumer_secret, $access_token, $access_token_secret) { /* save the connection for use later */ $this->twConnection = TwitterOAuth::__construct($consumer_key, $consumer_secret, $access_token, $access_token_secret); } } ?> Am i on the right trail here or i am barking up the wrong tree?
      I don´t need a complete solution, i just wonder if i am including the external library the right way.
      If not, then give me a few hint´s and i will figure it out.

      Thanks a bunch.

      /EyeDentify
    • By dimitrios
      Hello,
      this module can publish content of a Processwire page on a Facebook page, triggered by saving the Processwire page.
      To set it up, configure the module with a Facebook app ID, secret and a Page ID. Following is additional configuration on Facebook for developers:
      Minimum Required Facebook App configuration:
      on Settings -> Basics, provide the App Domains, provide the Site URL, on Settings -> Advanced, set the API version (has been tested up to v3.3), add Product: Facebook Login, on Facebook Login -> Settings, set Client OAuth Login: Yes, set Web OAuth Login: Yes, set Enforce HTTPS: Yes, add "http://www.example.com/processwire/page/" to field Valid OAuth Redirect URIs. This module is configurable as follows:
      Templates: posts can take place only for pages with the defined templates. On/Off switch: specify a checkbox field that will not allow the post if checked. Specify a message and/or an image for the post.
      Usage
      edit the desired PW page and save; it will post right after the initial Facebook log in and permission granting. After that, an access token is kept.
       
      Download
      PW module directory: http://modules.processwire.com/modules/auto-fb-post/ Github: https://github.com/kastrind/AutoFbPost   Note: Facebook SDK for PHP is utilized.


×
×
  • Create New...