Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 07/16/2015 in all areas

  1. The most flexible solution would be three branches: Categories, Branches & Products. Each would hold the single items of their content type and you'd link projects to branches / categories via page fields.
    2 points
  2. We use DigitalOcean with a ServerPilot managed layer so you can easily add additional users and apps. Works great and we never had any outage or unexpected downtime and support from ServerPilot is really good.
    2 points
  3. One particular case I had to deal with recently was using PageTable for configurable page layouts, i.e. dropping in blocks/widgets. In most cases, there were many different block types, but in some cases only one. In this case, I would've preferred to use template labels consistently, not making the client guess what this "new" block is that will be added. Could've solved this by field naming or descriptions, but this particular implementation was supposed to be as dynamic (and consistent) as possible, hence the need for "action" buttons to behave same way everywhere, regardless of field settings. Generally speaking convention over configuration is fine by me, but in my opinion current behaviour is far from "obvious". It's consistent with some other features in ProcessWire, but not consistent in the scope of PageTable itself. Additionally PageTable is one of those parts in ProcessWire where "convention over configuration" might not be the best approach after all; it's already being used for a lot of different purposes, and while that's a strength (no doubt about that), it does boost the importance of being configurable. In fact I've meant to post some additional suggestions related to labels, per-template settings, modal/view settings, and such; still trying to figure out whether to do that or simply fork PageTable. PageTableExtended is not exactly what I'm looking for either, even if it does already do some of the things I've had in mind. Anyway, that's a subject for another discussion
    2 points
  4. A client recently asked me to make a simple utility that they could use to upload files for public downloads. One of the requirements, for some reason or the other, was clean URIs. Thought it best to do it with PW. Too much of a mission anywhere else, really. Called it Dispo, which comes from Content-Disposition. Sharing in case anyone else may find it useful. This is generally for use on a subdomain - client wants it installed at files.example.com. In config.php, there are two options to set: one for the domain of the main website (Dispo will redirect there when the home page or 404 is hit), and the other for the name the company or, whatever. Best to set these as they default to localhost and ABC & Co., respectively. Create files using the downloader template, specifying a title for the file (this, along with the company name as set in config.php, will be used for the downloaded file name). When the entry (Page) is requested, its file will be downloaded. To view the file instead (if the browser is capable of it), add ?view to the URL. Download below: site-dispo.zip
    2 points
  5. Hey @valan - sorry about that - it was a bug in Hide mode. I just committed a new version that should fix things for you.
    2 points
  6. Martin, that is fixed already. I really need to figure out how to distribute upgrades... Can you send me an email and I'll send you latest release back?
    2 points
  7. Hi everyone, Here's a quick little module that I hope you'll find useful. NB It requires PW 2.5.16 (or late 2.5.15 - this is the exact commit) It allows you can control display of the various Page Edit tabs by user permissions. So if you want to always hide the Settings tab for users of a particular role across all templates, this should come in handy. http://modules.processwire.com/modules/restrict-tab-view/ https://github.com/adrianbj/RestrictTabView You can approach this from two directions - hide from all users unless they have View permission, or show to all users unless they have Hide permission. It's up to you to create the permissions and assign them to roles. Let me know if you have any problems or suggestions for improvements. BTW - I am not sure how much use the Delete and View options really are in most situations, but they are there if you want them. PS Thanks to @LostKobrakai for the code in this post: https://processwire.com/talk/topic/8836-how-to-manage-delete-tab-for-user-groups/?p=85340.
    1 point
  8. What does autojoin do? Using the 'autojoin' optimization can increase performance on fields that get used a lot. Not using it can reduce the page's memory footprint. What is more desirable in each instance depends on your situation. What sites should use autojoin? Autojoin is most applicable with larger sites. On smaller sites, there may be no benefit to using it or not using it. But it's good to know what it's for regardless. Where do you control autojoin? Autojoin is controlled per-field. You can turn it on by editing each field under Setup > Fields > [your field], and you'll see it under the 'Advanced' heading. When should you use autojoin? Autojoin causes the field's data to be loaded automatically with the page, whether you use it or not. This is an optimization for fields that you know will be used most of the time. Fields having their data loaded with the page can increase performance because ProcessWire grabs that data in the same query that it grabs the Page. Autojoin is a benefit for fields that are always used with the Page. This is best explained by an example. Lets say that you have a template for individual news stories called news_story. The news_story template has these fields: title date summary body sidebar We'll assume that when you view a page using the news_story template, all of the fields above are displayed. Fields that should have autojoin ON: Now consider a separate news_index template that displays ALL of the news stories together and links to them. But it only displays these fields from each news story: title* date summary In this case, the 3 fields above would be good to autojoin since they are used on both the news_index and news_story templates. If your title, date and summary fields didn't have autojoin turned on, then ProcessWire wouldn't go retrieve the value from the database until you asked for it it (via $page->summary, for example). Because the news_index template displays all the stories at once, and always uses the title, date and summary fields, it will perform better with title, date and summary having autojoin ON than with it OFF. In this case, it reduces the query load of the news_index template by 3 for each news story. To take that further, if it were displaying 20 news stories, that would mean 60 fewer queries, which could be significant. Fields that should have autojoin OFF: Now lets consider the body and sidebar fields, which are only used on the news_story template: body sidebar It would be desirable to leave autojoin OFF on those fields because there is no reason for the body and sidebar to be taking up space in memory when they are never used on the news_index template. While it might mean 2 fewer queries to view a news story, that is not significant and certainly not a worthwhile tradeoff for the increased memory footprint on the news_index template. Keeping autojoin OFF reduces a page's memory footprint. Conclusion Using the 'autojoin' optimization can increase performance on fields that get used a lot. Not using it can reduce the page's memory footprint. What is more desirable in each instance depends on your situation. But if your situation doesn't involve lots of pages or data, then you don't need to consider autojoin at all (and can generally just leave it off). Additional Notes Not all fields have autojoin capability. You won't see the option listed on fields that don't have the capability. *The title field has autojoin on by default, so you don't need to consider that one. It was included in the examples above because I thought it's omission might cause more confusion than it's inclusion. Be careful with multi-value fields that offer autojoin capability (page references and images, for example). Because MySQL limits the combined length of multiple values returned from a group in 1 query, autojoin will fail on multi-value fields that contain lots of values (combined length exceeding 1024 characters). If you experience strange behavior from a multi-value field that has autojoin ON, turn it OFF. If you want to play it safe, then don't use autojoin on multi-value fields like page references and images.
    1 point
  9. Hello everyone, greetings from Belo Horizonte / Brazil. I'm on the process of converting a site from WP to Processwire, this one: http://www.ricardo-vargas.com I needed a simple Flickr Gallery and tried to find a way to create album pages via API and download the images to the local filesystem (just a few, for cache purposes). So I created yesterday a simple script that, given an album ID, download its data using cURL and save the photos to a temp dir. After that, add them to a new page under /pictures/ Feel free to comment on the code, I'm a designer, not a developer, and this is my first time using PW API You can grab it on GitHub: https://github.com/sjardim/processwire-simple-flickr-album Instructions Download the files Put the templates/get_flickr_sets.php on your templates/ folder. Create a page on Processwire using this template Create or edit the page where the albums will be created. In my case it was /pictures/ IMPORTANT: Add guest edit/create permissions to this /pictures/ page, otherwise the script won't work Create a temp dir on your server and set it on the previous file Get a Flickr API on https://www.flickr.com/services/apps/create/ Add one or more Flickr album IDs on get_flickr_sets.php Open the page using the get_flickr_sets.php template on your browser <?php include "../lib/curl.class.php"; // You will need to get a Flick API Key // Get it here: https://www.flickr.com/services/apps/create/ // Load it on the file below include "../lib/flickr_album_utils.php"; function download_file($url) { // Save the image on local filesystem (You need to create this folder first) // On your server it can be /var/www/name_of_folder/ $tempdir = '/Users/XXX/phpFlickrCache/'; $fp = $tempdir . basename(parse_url($url, PHP_URL_PATH)); // if we already downloaded the images for some reason (like testing), just return it if (!file_exists($fp)) { $fh = fopen($fp, 'wb'); $curl = curl_init($url); curl_setopt($curl, CURLOPT_FOLLOWLOCATION, 1); curl_setopt($curl, CURLOPT_RETURNTRANSFER, 1); curl_setopt($curl, CURLOPT_BINARYTRANSFER, 1); curl_setopt($curl, CURLOPT_FILE, $fh); curl_exec($curl); curl_close($curl); fclose($fh); } return $fp; } // Get some public album id to test $albumID = ["72157636029541784"]; //$albumID = ["72157649576832173", "72157633296236495", "72157644132091553", "72157636029541784"]; // Load ProcessWire API $pages = wire('pages')->get('/pictures/'); /* -------------------------- GET ALBUM INFO FROM FLICKR -------------------------- */ foreach($albumID as $album) { // Via GET, return album and its photos info $album = fa_get_album($album); // create a new post $page = new Page(); $page->template = 'picture_album'; $page->parent = $pages; // disable page output formatting $page->of(false); $page->name = wire('sanitizer')->pageName($album['title'], true); $page->flickr_album_id = $album['id']; $page->title = $album['title']; $page->generic_integer = $album['total']; //total number of photos on flickr album – OPTIONAL //My client albums descriptions have two phrases, one in English and other in Portuguese // let's separate then by the period, but sometimes there is no period, so the PT description will remain blank $description = explode('.', $album['description']); $en = $languages->get("default"); $page->summary->setLanguageValue($en, $description[0]); $pt = $languages->get("portuguese"); $page->summary->setLanguageValue($pt, $description[1]); $page->set("status$pt", 1); //activate portuguese page $page->save(); // We need to save the page BEFORE adding images /* ------------------------------------ DOWNLOAD AND SAVE IMAGES FROM FLICKR ------------------------------------ */ $images = array(); $i=1; $maxImages = 11; foreach($album["all_images"] as $f) { //we do not want all the photos, just a little bit if ($i >= $maxImages) break; // mount the flickr photo url using its attributes $photo_url = 'https://farm'.$f["farm"].'.staticflickr.com/'.$f["server"].'/'.$f["id"].'_'.$f["secret"].'_b.jpg'; // download and return the image file in the filesystem $images[$album['id']][$i] = download_file($photo_url); // add images to the current page in the loop $page->images->add($images[$album['id']][$i]); $i++; } $page->save(); echo "<p>Created page for album: <strong>".$album['title']. "</strong></p>"; // Tip: Now, after we saved the images to ProcessWire /site/assets/files/, we can safely delete them from the $tempdir if needed } print "<pre>"; print_r($images); print "</pre>"; Admin Screenshot
    1 point
  10. Just in case anyone missed it... https://letsencrypt.org/2014/11/18/announcing-lets-encrypt.html The headline is: Let’s Encrypt is a new Certificate Authority: It’s free, automated, and open. Arriving Summer 2015 Extract: Let’s Encrypt is a new free certificate authority, built on a foundation of cooperation and openness, that lets everyone be up and running with basic server certificates for their domains through a simple one-click process. Mozilla Corporation, Cisco Systems, Inc., Akamai Technologies, Electronic Frontier Foundation, IdenTrust, Inc., and researchers at the University of Michigan are working through the Internet Security Research Group (“ISRG”), a California public benefit corporation, to deliver this much-needed infrastructure in Q2 2015. The ISRG welcomes other organizations dedicated to the same ideal of ubiquitous, open Internet security.
    1 point
  11. Hey, after having Lightwire Skin more or less ready for some months now I finally created a little module to make the installation easier. I hope you like it. Please report issues directly on Github: https://github.com/NicoKnoll/LightWire-Skin A cleaner and nicer CKEditor Skin using fontawesome:
    1 point
  12. Neat. You learn something new about ProcessWire every day
    1 point
  13. Yes. Scenario 1: Let's say you want to show a field on all pages that are the child of a certain page. In the visibility settings put: parent_id=id-of-parent-page-here Scenario 2: Let's say you want to show a field on a specific page. In the visibility settings put: id=id-of-page-here
    1 point
  14. As long as the field isn't set to "autojoin", there would be no performance/overhead issue at all, I don't think. Is it possible to use visibility settings to show a field on a specific page?
    1 point
  15. @Juergen, You are correct, that doesn't work (yet). Pete requested this for the superuser quicklinks, and I didn't get around to adding it until now. I'll submit this and a bunch of other little updates to Ryan today. This won't work until these changes are added to the dev branch, but you can now define link attributes like so: $newItem[] = array( "class" => "my-class", "label" => "<i class='fa fa-asterisk'></i>", "link" => $config->urls->root, "attrs" => "target='_blank' rel='foo'", // whatever attributes you would like to set here, other than class. "children" => array( // The key/value for the children now accepts an array for the value. // if the value is an array, the first item is considered the link, any other items are considered attributes. "Google" => array('http://google.com', 'target="_blank"', 'rel="foo"'), "Github" => array('http://github.com', 'target="_blank"', 'rel="foo"'), "ProcessWire" => "http://www.processwire.com" // non-array value works as well. ) );
    1 point
  16. That was it! Seems like it's always something easy like that after I've spent hours trying to troubleshoot Thanks a bunch!
    1 point
  17. Hi tpr I've just passed through the same problem. The solution is to give the location/name of your twig file as the second parameter. Ex: {{ __('my_string', 'home') }} for templates/home.twig or {{ __('my_string', 'includes/header') }} for templates/includes/header.twig
    1 point
  18. You're welcome. It isn't on GitHub - I don't really have plans to make many changes. If I land up expanding on it, I'll push it to GH. Too true - I shall no longer reduce the lifespan of your mouse.
    1 point
  19. This is just great and shows the endless ways of "everything is a page".
    1 point
  20. A very simple portfolio site for photographers, designers, textwriters. When its infished Ill upload the source to share with ya'll.
    1 point
  21. You need to edit the ProcessProfile module. There you can chose out of the template's fields which one are visible.
    1 point
  22. I don't have a migration script, because I've implemented this before starting the project But should not be hard, I would do a command line script, bootstrap ProcessWire and then code something like this: <?php // Bootstrap Pw // Make function wireMove, function mostly copied from wireCopy function function wireMove($src, $dst) { if(substr($src, -1) != '/') $src .= '/'; if(substr($dst, -1) != '/') $dst .= '/'; $dir = opendir($src); if(!$dir) return false; if(!wireMkdir($dst, true)) return false; while(false !== ($file = readdir($dir))) { if($file == '.' || $file == '..') continue; rename($src . $file, $dst . $file); $chmodFile = wire('config')->chmodFile; if($chmodFile) @chmod($dst . $file, octdec($chmodFile)); } closedir($dir); return true; } // Start migration - Loop your pages // You could split by templates and use limit/start to get this done in multiple iterations. // Limit depends on your server memory $pages = wire('pages')->find('template=shibby,limit=2000'); foreach ($pages as $page) { $old_path = wire('config')->paths->files . $page->id . '/'; $new_path = PagefilesManager::makeCustomPath($page); if (wireMove($old_path, $new_path)) { @unlink($old_path); } } Please only use on a copy of your installation, there will for sure be bugs as I've written it in the browser. You will need to make some modifications, but maybe it helps you as a starting point. Cheers
    1 point
  23. And I was not here! Very nice example of usage of ProcessWire modules. Even after months, I love it!
    1 point
  24. I suggest not extending the User class, and instead plugin to it with a module class UserExtended extends WireData implements Module { public static function getModuleInfo() { /* return your array here */ } public function init() { $this->addHook('User::sendThankYou', $this, 'sendThankYou'); public function sendThankYou($event) { /* do something */ } } The above would add a sendThankYou method to all User instances. Your sendThankYou method can gain access to the $user the method was called on like this: $user = $event->object; Your sendThankYou method can also have one or more arguments if you want it to: $arg = $event->arguments[0]; If you want your sendThankYou method to return a value, do it like this: $event->return = 'value you want to return'; Looks like Antti beat me to it.
    1 point
  25. /site/modules/UserExtension.module <?php class UserExtension extends WireData implements Module { public static function getModuleInfo() { return array( 'title' => 'User Extension', 'version' => 101, 'summary' => 'Extends $user object.', 'singular' => true, 'autoload' => true, ); } public function init() { $this->addHook('User::sendThankYou', $this, 'sendThankYou'); } public function sendThankYou($event) { $user = $event->data['object']; $event->return = "Thank you, $user->name"; } } Usage is dead simple: <?php echo $user->sendThankYou() ?>
    1 point
×
×
  • Create New...