Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 07/18/2016 in all areas

  1. http://webdesign.tutsplus.com/tutorials/a-beginners-introduction-to-writing-modules-in-processwire--cms-26862 Based on work from here:
    13 points
  2. Metadata Exif Version 0.9.0 (currently a WIP) for PW 2.8.+ / 3.0+ This is a new attempt to add easy EXIF reading support to ProcessWire. It should be an easy and less error prone API task. Thats why the module internally uses lowercase key names for all EXIF keys and all of your requested key names. But you are not forced to use lowercase key names, you can use any mixed chars for it as you like. You will get back an array or object with keynames / properties named the same (casesensitive) way as you have passed them in with your request. API The module adds one hook to the Pageimage: getExif($options = null) Without any $options passed to the method, it returns all EXIF data in a RAW multidim array. Passing a simple list with requested key names as array to it returns an array with only the values of those requested keynames. If you want change the output from array to object, you can use the a boolean "toObject" set to true. Additionally to this and / or any other option, you need to put your requested keynames list to the option "keys". $rawArray = $image->getExif(); $options = array('Whitebalance', 'Flash', 'ISOSpeedRatings', 'FNumber', 'UserComment'); $array = $image->getExif($options); $options = array('toObject' => true, 'keys' => array('whitebalance', 'flash', 'isospeedratings', 'fnumber', 'usercomment')); $object = $image->getExif($options); Possible options are A working example $options = array( 'keys' => array('ISOSpeedRatings', 'FNumber', 'Flash') ); echo "<table><tr>"; foreach($options['keys'] as $key) echo "<th>{$key}</th>"; echo "</tr>"; foreach($page->images as $image) { $exif = $image->getExif($options); echo "<tr>"; foreach($exif as $value) echo "<td>$value</td>"; echo "</tr>"; } echo "</table>"; This will output something like: With the boolean option "unformatted" passed as true, the output would look like: For some keys, that only store something like integer values, what are not very meaningful to most of us, the module contain xyzFormatted methods. This way, it is easy to enhance and maintain the module in the future. Help wanted It would be nice if some of you test the module and report back if the intended API suites your needs. And you are very welcome to post suggestions for which keys you want to have a ...Formatted method. Thank you! https://github.com/horst-n/MetadataExif
    7 points
  3. Hi. I have a lot of white and transparent png images and its quite difficult to find needed one: For now I can use Admin Custom Files module to change background of some div, but it not so elegant solution. Maybe there is some other workaround about this issue? Ideally it would be nice to have some kind of background switcher near the grid swithcer
    4 points
  4. PHP isn't running in parallel (besides using ReactPHP), so if it's affecting anything it's certainly not your fault
    4 points
  5. You can and should add the option in the config file inside your site directory. The wire/config.php has the defaults and the site/config.php has your custom config which overrides the wire ones.
    3 points
  6. Check out advanced mode in config.php and you'll have this for each template: Maybe doesn't take care of everything you need, but remember that the status can also be changed from the Page List view via the extended (after the arrow) action buttons.
    3 points
  7. I made a new color style for the default theme PW 3.0.25. I just copied the default theme's folder to site/modules, changed Default to DefaultExtra so it doesn't conflict with the default one and added an extra css file.To install unzip archive to site/modules, go to modules page, hit refresh, install theme, choose style (Clear Sky), go to profile and activate DefaultExtra. AdminThemeDefaultExtra.zip
    2 points
  8. $f->flags = Field::flagGlobal; $f->set('flags', Field::flagGlobal); $f->setFlags(Field::flagGlobal); Use what you like best.
    2 points
  9. Thanks! Would you mind adding this in brief as a comment to the tutorial? I'm sure it'll be useful to people.
    2 points
  10. Wow awesome am gonna take some information from your tutorial.
    2 points
  11. Thanks for writing this. It's surely a place where the current docs are a bit lacking in details. You could clarify a bit more that the hooked function (___save()) does need to have those three underscores, whereas the function executed by the hook (helloMessage()) does not (but can). Also getModule() is not really often used in processwire's docs, I'd rather use $modules->get('FrontEndRender') and even this would work $modules->FrontEndRender
    2 points
  12. Do you have "return $out;" at the end of the function? If not, is there any generated markup? Or is any js or 404 error in the debug console (browser Inspector)?
    2 points
  13. I think changing the output formatting will be the most reliable way to check if a field is working like our file fields as it's working no matter what you throw at it. I'd imagine anything else being dependent on the actual implementation of each of those fieldtypes.
    2 points
  14. Wow. That's fantastic. Just installed and worked through the options. I think I mostly understand it. Seems extremely powerful. Thank you for making it! On a related note... your ProcessPageFieldSelectCreator module was instrumental in me *finally* understanding how Pages work! Specifically... that they're not just "pages." With much frustration, I almost gave up on PW several times yesterday because it just wasn't making any sense. But experimenting with your module provided me with a much-needed light bulb moment. After that, a lot of stuff has 'clicked' for me. So thank you again.
    2 points
  15. No problem - actually, you don't want to modify the wire/config.php - you just use that as a reference and copy any options you want from it to the site/config.php and modify as required. BatchChildEditor module is also helpful if you need to make changes to lots of child pages at once. EDIT: Beaten by @fbg13
    2 points
  16. I can only support @tpr. nette/forms is a really nice package if you don't need a UI. With some upfront time you can really cater the markup to your needs and it'll still be easy/fast to configure new forms. But probably the best part of it is the one-time config for server and client side validation, which is even extendible even though I never needed to add anything. It doesn't come with so many prebuild sets of fields as alpaca forms (I've even seen table editing ), but I've added a few custom Inputfields to my nette/forms installation and it's not to hard to do.
    2 points
  17. Nette Forms: I have a very beta module of it. It doesn't have a UI to build forms and I don't plan to add such so it may not suit for everyone. I can send a copy to check, though as I wrote it's not quite ready for production.
    2 points
  18. I have committed some significant updates to the Mail and Event Interceptor panels over the last couple of days. Both now store the data they have captured in a session variable so new items captured will be added to the list in the panel. This also removes the need prevent redirects in the code just to see the data. @tpr has been a great help in debugging several things - thank you! I think the Mail panel is now working very reliably and should prove a great help in testing/debugging form emails and the like. The Event Interceptor appears to be working fine, but I have noticed that it can be quite destructive if you're not careful - one example I noticed when I had the Pages::save hook setup in the admin was that some pages ended up having the trashed status, but their parent was still listed as "1" (ie the home page). I still like the power this panel offers - especially when you want to prevent the creation of new pages when submitting test forms, but I am wondering whether it should be limited to front-end API actions only (to reduce possible damage), or whether it might be useful to have a "Capture Only" option which means that it won't prevent the event, but will simply capture the object and arguments to display in the panel. I need to think through this a little more, but would also really appreciate any thoughts from those of you who have tried it out.
    2 points
  19. This module facilitates quick batch creation (titles only or CSV import for other fields), editing, sorting, deletion, and CSV export of all children under a given page. You can even provide an alternate parent page which allows for editing of an external page tree. http://modules.processwire.com/modules/batch-child-editor/ https://github.com/adrianbj/BatchChildEditor The interface can be added to the Children Tab, or in a new dedicated tab, or placed inline with other fields in the Content tab. Various modes allow you to: Lister - Embeds a customized Lister interface. Installation of ListerPro will allow inline ajax editing of displayed fields. Edit - This allows you to rename existing child pages and add new child pages. It is non-destructive and so could be used on child pages that have their own children or other content fields (not just title). It includes the ability to quickly sort and delete pages and change page templates. Also allows full editing of each page via a modal dialog by clicking on the page name link. This is my preferred default setup - see how it replaces the default Children/Subpages with an easily addable/editable/sortable/renamable/deletable list. Note that the edit links open each child page in a modal for quick editing of all fields. Add - adds newly entered page titles as child pages to the list of existing siblings. You could create a list of pages in Word or whatever and just paste them in here and viola! This screenshot shows the editor in its own tab (name is configurable) and shows some of the CSV creation options. Update and Replace modes look fairly similar but show existing page titles. Update - Updates the titles (and any other fields if you enter CSV data) for the existing pages and adds any additionally entered pages. Replace - Works similarly to Add, but replaces all the existing children. There are checks that prevent this method working if there are any child pages with their own children or other content fields that are not empty. This check can be disabled in the module config settings, but please be very careful with this. Export to CSV - Generates a CSV file containing the fields for all child pages. Fields to be exported can to fixed or customizable by the user. Also includes an API export method. Populating fields on new pages In Add, Update, and Replace modes you can enter CSV formatted rows to populate all text/numeric fields, making for an extremely quick way of creating new pages and populating their content fields. Predefined Field Pairings Like the field connections setup from Ryan's CSV Importer, but defined ahead of time so the dev controls what columns from the CSV pair with which PW fields. This is especially powerful in Update mode giving editors the ability to periodically import a CSV file to update only certain fields on a entire set of child pages. These pairings also allow for importing fieldtypes with subfields - verified to work for Profields Textareas and MapMarker fields, but I think should work for most others as well - let me know if you find any that don't work. Access permission This module requires a new permission: "batch-child-editor". This permission is created automatically on install and is added to the superuser role, but it is up to the developer to add the permission to other roles as required. Config Settings This module is HIGHLY configurable down to setting up custom descriptions and notes for your editors. You define one config globally for the site and then optionally you can define completely custom configurations for each page tree parent on your site. There are too many settings to bother showing here - you really just need to look through all the options and play around with them!
    1 point
  20. Hi guys so currently am writing a detailed tutorial about creating Modules, I have never created a module because i don't know all the classes and interfaces required, so this is like a detailed research for me, this is how i learn things by writing articles. However I might make some mistakes so i decided to make it on Google Docs to get comments and feedback, before posting on my website and Processwire tutorial site, this is going to be one heck of a detailed tutorial. Here is the link I will be updating it https://docs.google.com/document/d/1VA_WK-5qbnq3Ux_EOW3p92IcjbAcVZJ0aewIiFxmv2Q/edit# However I wanted to get a clear picture of the following Process Class and ConfigurableModule i noticed some modules require it and some don't My interpretation is that Modules with admin setting pages uses ConfigurableModule and Process are modules who require access to $this->pages and that sort Thanks all
    1 point
  21. @Zeka Simple and good idea! However, we should not leave the checkerboard option out. Better yet, probably all shade versions should still be checkerboards, a dark one, mid range and a light one. We should still signal that these are transparent images. BTW, this thread should be moved to https://processwire.com/talk/forum/5-wishlist-roadmap/ I suppose.
    1 point
  22. I forgot the "echo $out;" at the end. Now I feel a little stupid. My only excuse is that its monday morning without coffee Everything is working now! Thank you for this module and your patience with my problems!!
    1 point
  23. Glad you are finding those modules so useful - especially the page select creator - it is definitely a time saver - it can be a little time consuming and confusing to get the template parent/child permissions correct.
    1 point
  24. Oh geez. Of course, I didn't know that. Now I see that warning at the top of the /wire/config.php file. Appreciate the heads up.
    1 point
  25. Thank you, Adrian. I checked and rechecked my config.php file for that setting. Couldn't find it. I didn't realize there are 2 different config files. Ha! (for anyone else reading this, the Advanced Mode setting is in the /wire/ directory, not /site/.) Your screenshot was very helpful. Also, I didn't know about the hidden status/unpublish buttons on the Page List View. That's a great time saver! Thanks for the tip.
    1 point
  26. I forgot to attach a file from the old (no longer online) ProcessWire Wiki, just in case you do not have a copy of it. This is somewhat outdated, but you might still find useful info in it. See: "Module Creation - Wiki.html.zip" Module Creation - Wiki.html.zip
    1 point
  27. Hello, guys! I've prepared an extract of my latest work for public usage: Template for ProcessWire with Stylus and PostCSS. It simplifies the development of the stylesheet and JS files with CSS preprocessors, autoprefixes and browser reloading. I hope it can be a good kickstart for your next project! https://github.com/leonidlezner/pwtemplate Released under MIT, no credits or copyright notices are necessary, so feel free to do with it whatever you want Update: Template works with 3.x too! And now with German Tutorial http://leogo.es/qvxul
    1 point
  28. @Juergen To setup a cronjob is really easy, but you have to understand some basics first. The cronjob past has nothing to do with ProcessWire. It is a separate program running on your server which is able to run commands at a certain time. It is either configured in your hosting admin panel (easiest, ask your hosting provider) or you can set-up it yourself through the command line. You can follow this example if you're running a Linux based server. You need to understand that you can execute a PHP file from the command line. Teppo has provided us with such a script that will activate the link checker. The file is "/ProcessLinkChecker/Init.php". This is the one the cronjob needs to run. If you are unsure what the correct path is you can ask your hosting provider or login into the shell and navigate to the "ProcessLinkChecker" folder and type "pwd". That will give you the current path. It will be something like: /srv/username/apps/appname/public/site/modules/ProcessLinkChecker/ Combine the path with your new knowlegde from the tutorial and you can set it up. p.s. If you are on Windows you need to create a "Task" in "Windows Task Scheduler". p.s. 2 You don't have to wait to test if the link is working since you can test the script by running: /usr/bin/php /path/to/site/modules/ProcessLinkChecker/Init.php >/dev/null 2>&1 p.s. 3 this whole timing stuff can be pretty confusing so use a tool like crontab.guru. p.s. 4 after proofreading this post now it seems pretty hard , but believe me after a few times you can set it up in a few minutes.
    1 point
  29. Try this: foreach($albums as $album){ // if there's no thumbnail no need to do anything if(!$album->thumbnail) continue; // save srcset tag to a variable $srcset = $album->thumbnail->srcset('thumbnail', 'lazyload my-class inline-block', array('quality' => 80)); $out .="<a href='{$album->url}' class='item {$album->thumbnail->tags} {$album->thumbnail->orientation}'>"; if($album->images){ $out .="<img $srcset alt='{$album->thumbnail->Alt}'>"; } $out .="<div class='item-info'><h3>{$album->title}</h3><h4>{$album->thumbnail->tags}</h4></div>"; $out .="</a>"; } It's written in browser so double check the syntax.
    1 point
  30. Ok, the Mail Panel is now available! I have also added a new related panel called "Event Interceptor" that let's you define any Hook that you want to intercept. Much like the Mail panel, this new panel prevents the chosen hook from being executed, but instead, returns that contents of $event->object and $event->arguments in the panel instead. This may be useful for debugging all sorts of things, but my primary motivation for adding this is to prevent pages from being created when testing form submissions, by using Pages::save. Both of these panels (unlike most of the other custom ones - because there is no point, not because it's not possible) also work via AJAX calls - note that both their icons appear in the AJAX bar in the screenshot below. Note that the Mail panel will be active and intercept emails sent while it is enabled. The Event Interceptor will only work if there is a hook entered and "Set Hook" is clicked. To clear it, click "Remove Hook". Hooks need to be entered like so: Pages::save Both of these panels should be considered alpha at this stage, so please don't use on a live site just yet. Mail Panel icon colors: Green - no emails intercepted Red - at least one email intercepted Event Interceptor icon colors: Green - no hook set Orange - hook set, but nothing intercepted Red - hook set and event intercepted As I mentioned above, please consider these two panel alpha at this point, so please test carefully and give me your feedback - I expect the functionality of these to possibly change significantly based on everyone's ideas.
    1 point
  31. To supplement @John the Painter's answer: 1. Update InputfieldMapMarker.module to get your API key however you're managing it: public function init() { $apikey = // get my api key $script_path = ($this->config->https ? 'https' : 'http') . "://maps.googleapis.com/maps/api/js?key={$apikey}"; $this->config->scripts->add($script_path); return parent::init(); } 2. Enable 'Google Maps Geocoding API' in your Google API Console for your site's API key: https://console.developers.google.com/apis/api/geocoding_backend/overview You may need to enable whichever other individual APIs (places, geolocation, etc.) from Google's API library for the client side if you use the same API key: https://console.developers.google.com/apis/library Updating the MapMarker module will remove these changes if this file is affected by the update.
    1 point
  32. I would say a ProcessModule for the AJAX request. That module should extend Process and Make sure the config array contains 'permission' => 'page-edit'
    1 point
×
×
  • Create New...