Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 04/29/2015 in all areas

  1. Hey, I finally finished the website of the agency I worked for. The agency is Berlin based and called "DOJO" (because it's founded by Dominic and Joachim). It looks like this: Here is a link: http://dojofuckingyeah.de It was a lot of work and I still have to do some bugfixes. But anyway it's online at least If you have questions, comments or found a bug: just let me know
    7 points
  2. Not an easy task. The bigger they are the dumber they get... Because it's late and I'm sleepy, I will answer directly to those points: This won't be an easy one. If I look at the developers directory there are only two PW Devs in Porto <- On the left it's me, and on the right it's you. You can state that PW is growing fast, supported in factual statistics preferably (you would need them, of course). You can also argue that ProcessWire has a lower learning curve than other CMSs for an experimented developer. And, of course, they're not forced to hire someone in Portugal in case something happens to your company (make sure you keep the comments on your code and all namings in English, which is good practice anyway). If you think it can help, point them here http://www.cmscritic.com/dir/products/processwire/ and tell that even their website is built with PW. That's an easy one! You don't have to look for a long time to find recent examples of security holes in WP. As for Drupal, a quick googling brought this up http://brightlemon.com/blog/community-pulls-together-drupal-highly-critical-security-announcement. As for PW, you have tis http://www.reddit.com/r/webdev/comments/2zzo0t/any_reason_i_cant_find_anything_about_processwire/ Can't look for it now, But there are one or two posts where Ryan talk about this subject. Anyway. Processwire is Open Source and was forked hundreds of times. There are already a lots of great devs depending on it to earn their living to be sure that, whatever happens, PW won't go anywhere. Show them how active PW's development on github is.
    7 points
  3. You might want to show them the Canton speakers site done with PW that was introduced lately and also announced in PW weekly newsletter. This is a worldwide brand. If they trust in PW, why shouldn't your potential customer. EDIT And cmscritic.com might serve as an example. Their article ProcessWire vs WordPress has some good arguments for PW and against WP. Then there is this article about PW in the german IT magazine c't: "German computer magazine c't has just published an article about ProcessWire, and Tuts+ has announced they are going to commission tutorials on ProcessWire" (taken from PW weekly #43). Some ideas for your points 2 and 3: - you could offer free updates for a period of time since it is so easy to do - if you have the capabilities, you could offer a free port of the system to WP or Drupal in case PW development will stop in the future. This will underline your total confidence in PW And, if you have the opportunity, you could show them the PW backend and how easy it is for editors to work with.
    6 points
  4. The fact that I got all this input overnight is in itself a good argument. I intentionally omitted what I already did in the meeting to defend PW, and it's nice to see other people mentioning the same things: Told my personal experience, not being a backend coder, I have built my personal site completely from scratch and didn't get stuck even once; After my experience, brought PW to my engineering department, asked them to build one of our client's site with PW and got such good input that it's now our dev platform for small to medium projects (cases such as Volvo's CRM we use our own platform); Showed him hands on how easy it is to make changes to my own website, added a field to my portfolio section, customized it and had it output on the frontend (under 5mins); Demonstrated that PW doesn't make any assumptions whatsoever as to what you're going to build, being a blog, products catalogue, news magazine, etc; Mentioned that it's been around for 7 years (is it?) with regular updates and we have a new major update coming this week; Explained the learning curve: any programmer that picks up PW will be building a website the next day. Still, great extra arguments here. I owe you guys a beer!
    4 points
  5. Best way would be to show them in real time. Take your laptop and show them, depending on who you are dealing with: admin, editor, end-user, site owner, techie or non tech, etc., the part they are going to do on the website: a) setup b) admin c) pagetree (editing and maintenance) Now compare that to the others in time, learning curve, easiness, etc. Speaks for it self so never try to convince them. They should convince them selves.
    4 points
  6. Made a small update so that InputfieldChosenSelectMultiple now respects the "Allow pages to be added" setting. Without it one cannot add tags anymore.
    3 points
  7. On a side note: Working with PW for more than 2 years and only now making the first forum post/question. This must be a testament to PW's ease of use, power and great docs!
    3 points
  8. Version Bump to 1.3.0 - Important Upgrade Release Notes: Debug Mode now logs each wildcard in a jumplink. Important fixes for zero/null timestamps. You can now make slashes optional with /? or [/] instead of just the latter. Classes are now only imported when needed. Each jumplink now remembers when it was last hit and notifies you if it has gone stale, as discussed above. 404 Monitor, as discussed above. Turned off by default. Schema version bumped to v4 to accommodate timestamp fixes and the new 404 monitor. If you come across any bugs with this release, please open an issue over at GitHub. Docs will be updated shortly.
    3 points
  9. Have a look at this: https://github.com/ryancramerdesign/ProcessWire/pull/1128
    3 points
  10. A little update on timing (of 0.4.0): Right now I'm drowning in client work and simultaneously many PR's are coming in (which is totally cool!). Since there's a public holiday mid-May here in Germany, I hope to find the time to release 0.4.0 then, together with a microsite containing better documentation (which is necessary as the last posts here proove), some info on contributing, gathered knowledge especially on Windows and MAMP/Mac usage. Also, clsource has raised the totally valid point of testing. While Symfony Console is more than ready I'm not sure how to mock/fake/implement the ProcessWire API layer (but also I'm kind of novice in testing). Has anyone an idea of how to do so (maybe it's much easier than I think)? Either way - thanks on input!
    3 points
  11. First of all, the screenshot is showing CKEditor and not TinyMCE. You can set custom options for it in the field's settings. Here you'll find how the options look like: http://stackoverflow.com/questions/12464395/how-do-i-programatically-set-default-table-properties-for-ckeditor
    2 points
  12. I'm afraid technical arguments won't count pretty much. From my experience it's references that matter. I would show them off the most prestigious sites I could find in the showcase section. The Canton site mentioned above is a very good start in this respect. If it comes down to a more in depth discussion I would point out the following: PW is plain PHP in a way. No template language etc. Every PHP developer may still maintain it even if development is discontinued easy straightforward admin, no expensive tutorials etc. required for editors best choice for managing large amounts of structured data as shown in the skyscraper profile (if this matters for your client of course). Again this makes up for an easy to use admin (single point of entry for data etc.) low development and maintenance cost thanks to straightforward system architecture If this all doesn't convince them, I recommend a WP install with a ton of rubbish plugins and a good maintenance contract for you - kind of a revenge and after-sales-satisfaction (for you, not for them)
    2 points
  13. http://processwire.com/about/background/ The PW 2 line has been around since somewhere in 2010 i think, so about 5 years. A complete rewrite but built on the concept, ideas and experiences of its predecessors.
    2 points
  14. Great site Nico! Feels ok to me. And I think this is css animations on hover, there's no Nico can do to change it without switching to js. There's this problem though Maybe it would be worth to use js to reduce the size of the font on large words. If you Germans wouldntwritelikethis this wouldn't be such a problem
    2 points
  15. Looks really nice. One thing I noticed. When I circle over the projects with the mouse the hover effect falls behind, which leads to a quite unresponsive feeling. Also dat ascii art (I think you know what I mean )
    2 points
  16. This is a Leaflet version of Ryans Google Maps marker module. @Github
    1 point
  17. Like most newbies (I suspect) I am now exploring different Modules. To be honest some of them leave me wondering "how and when would I use this?" I bet most of you have favorites, a few oft deployed modules, that you reach for most of the time. I wonder if the most used modules would be the same for most of you? Anyways, I am interested (maybe others as well) in learning what modules you guys reach for most of the time... Thanks!
    1 point
  18. The Background Early in December 2013, the National Geographic Traveller India team at Amar Chitra Katha, called Pigtail Pundits over to help them build their website. Till then, the NGTI site was a poorly cobbled together, pale shadow of the publication in html and css, comprising, mainly content from the offline magazine articles. It was formatted too plainly, and didn’t carry the richness of imagery, gloss and character that you’d associate with anything from the National Geographic stable. The Brief NGTI had an ambitious remit for the revamped website. It will contain the offline magazine, in full, with each issue richly illustrated with some 35 odd travel stories and encrusted with glorious pictures The past issues of the magazine, some 15 of them so far, would have to be imported into the new system gradually It will carry have articles written exclusively for the web, by a separate editorial team It must have the ability for accepting photos from amateur travel enthusiasts, every day It must showcase the images from National Geographic Traveller in all its glory through on-page galleries and sliders It must have a workflow for the editorial to schedule articles into the future It must be fitted with rich tags to describe/ cross-tag the articles, the ability for browsers to comment and search ability built into it What’s more, it must come close in feel and richness to the National Geographic mother site in the US. That site incidentally, was in Beta at that time, and used some really fancy, jaw dropping scripts and effects. We were wondering as to what technology it was built on. But, there were a lot of challenges to tackle before we even reached to the front-end effects. To Drupal, or to Processwire? The Million $$ choice. We took on the challenge of the revamp. Thinking through and rationalising the different and varying content types in the magazine was our first task. We noted 13 different types. The trick was to winnow this down to just one content type that could fit all types of articles. Then, in fitting this content type into the system, we had to take a few calls. We argued that the system must have the flexibility to allow editors to embellish their articles - with drop caps, pull quotes, captions, guides and other style ornamentation that was singular to the National Geographic Traveller. In order to do this effectively, we would have pre-styled codes in the system that could be invoked using short codes as the editors saw fit. This was a whole sight better and more flexible than putting text into pre-styled boxes that would constrain the editorial. Drupal CMS was our first choice in putting this system together. We had worked with Drupal for several years now and we knew a thing or two about customising it too. The only challenge was to get a young team at Pigtail Pundits behind Drupal. The learning curve for Drupal was always daunting and that was a concern. We started work on Drupal in early January 2014. We cobbled together an internal team that would work on the project. After about a month into Drupal, we had almost everything ready for a demo to the client, save for styling. In early February, we had a rethink. We were working on some projects and testing out Processwire, internally in parallel with the NatGeo project. We found PW to be a fast, flexible, efficient system, without either the bloat and the learning curve required of Drupal. We had to take a call. Drupal, for all its goodness, still made heavy weather of its modules. Drupal optimisation alone required a lot of modules at the application level. Plus a few on the server - memcache, ably supplemented with server processing speed and memory in fair, generous helpings. But optimisation itself was just one of the many things that troubled us about Drupal. There were a heap of other modules, each adding weight and extra lumber to the ponderous system. Besides there was image heavy content. We had serious doubts as to the conditions under which the site would run well with Drupal, both immediately, and in the long run. We had to take a call. Time for a few seditious thoughts Could we now change the NGTI project to Processwire from Drupal? What would be the implications? For us, for NGTI? We had to grapple with a whole bunch of fallouts of this. How do we come clean with the client on this? Would that decision to shift hurt us? What if the client were to say no to the shift? What about getting our internal team that was already on Drupal, come to grips with Processwire? How long would that take? The reasons to shift to Processwire were clear. Speed, flexibility and scalability given the volume of content that was going to be part of the magazine and web editorial, the features we required, and the potential traffic on the NGTI site. The decision had to be made now. We decided to make an early switch to PW. And in retrospect, it was probably the best decision we took. We had to instil confidence in the client that this switch to Processwire was the right thing to do. If we relayed the news too early, it could have worked against us. We had to prove that PW was a better decision. So we went ahead and simulated all that we’d done in Drupal into Processwire without asking the client, or giving them a whiff of what we were up to. We worked in parallel on both the systems. It took us about 15 days to get everything in Drupal into PW. Mercifully for us the client was hunting for a design team that would do justice to the Nat Geo design pedigree and that took some time. Along with the fact that the new web editorial team was still being formed. We used this lull effectively to make the switch. Remarkably, our Drupal team picked up PW twithout any issues. It took them a week to grasp it and get going. That was a record of sorts as we’d folks who struggled with Drupal even after 3 months on a project, still coming to grips with techniques and modules. But PW was a cinch. The Processwire Miracle We put together the first cut of the site in Processwire. Rationalized content types for magazine articles were in One magazine issue was fed in so that we could slap on some styling Hannah code was used generously to style the content within the editor, without getting in the way of content, or trapping this into pre-styled text-area boxes. Magazine captions, guides, block-quotes, drop caps were driven by Hannah to facilitate the editorial hoopla Gallery and slider scripts were quarried for the demo The demo date was decided in early April. We showed off the system, its speed, and ease of use, live to the client. It was only after the demo that we told them that the system was not Drupal, but Processwire. They were already sold by then. The real intensity on the NGTI project however started in June 2014 when the designer Matt Daniels was brought in by NGTI. We were privy to the early designs of the Home Page, Landing Pages and Detail Pages. But were anxious as to how things would play when the entire design was complete. After all the design was not in our control. Luckily, everything went off well. There were a few challenges, and these were taken up and resolved. Javascript for the galleries, sliders had to be rewritten from scratch to conform to the design requirements Editorial came up with a list of how they wanted articles to be featured on the Home Page in blocks and we had to program this accordingly. We managed to queue the articles and then lop the old off, when the new were published Destination page required maps by default and then of city/ country being searched. This was programmed using Google APIs. Marketing came up with the need for ads - leaderboard and sidebar and we had to fit these in An Events Calendar was programmed from ground up, as per the design for Events The import of prior issues was debated, captured into excel sheets, reviewed, and reviewed some more. Scripts were written for import. Scripts were written to test the integrity of the data input before import. And everything came together in August, 2014. 6 magazine issues were imported before the launch was announced on August 14. The NGTI team went in and styled these quickly using the tools we had built for them. The final build had 20 different templates. In retrospect, we could have rationalised these too to fewer. But these came in bit by bit for the build and there was little we could do there as we couldn’t see the whole, before it arrived. The NGTI team was trained on the backend operations as part of the build itself, so by the time we had completed the site, they were up and ready to input. The project is still in beta for a few days. Optimization using just compression of CSS & JS works fine for speed. The site works like a charm now. Thanks everyone Thanks are due to Processwire and the amazing system and set of modules that are in place. Thank you Ryan Cramer. We don’t have to tell you how much we enjoy working with this system, after coming from Drupal and WordPress. Thanks to all the lovely folks on the PW forum who had answers to niggling issues we had. Key Tools, Systems used: Processwire 2.4 CMS with Foundation 4.0 framework Hannah Code for short codes in the editor for style application Event Calendar was coded ground up Form Builder was used for front end forms CK Editor, for text area editing with Image extra for description and tags ProCache - for server level caching Video Embeds and Images used field uploads Image Captions & Tags using image extra fields Scheduler, for advanced date publishing AIOM - for compressing JS and CSS for speed improvements MailChimp Integration for Newsletter Disqus Integration for Comments Integration of Facebook, Instagram, Google Maps via API Integration and customisation of Google Search Integration of DoubleClick and Adsense for advertising
    1 point
  19. Some time ago I developed a module (FieldtypeImageExtra) which extends Fieldtype Image with the ability to add custom fields to an image. This worked well but it had a somehow restricted applicability and did not meet all of our needs. There of course are other useful image modules like CroppableImage or ImageFocusArea, but up to now there was no possibility to combine image cropping with custom fields support. So you had to decide whether to add image cropping or the possibility to add custom fields because each of those modules sets up their own field type (and input type) which cannot be combined. The new module ImageExtra allows you to have both functionalities. You can get the module from GitHub. For more informations have a look at this blog post. If you notice any problems or unexpected behaviour please let me know.
    1 point
  20. Comunity unite! Today I tried to convince a "quite high profile client" to have a new site built with ProcessWire. He's not completely convinced. This is a well known, nation-wide brand with a big audience. They've invited a few agencies to show them what they've got, requiring an open-source platform "such as Wordpress or Drupal". We've of course introduced them to the wonderful world of PW but, since they've never heard of it they weren't quite comfortable and insisted on either the W or the D. It's a basic known vs unknown dilemma. Their main concerns: Support / Community - finding other devs in case my company shuts down Security - don't want to get hacked Guarantees - as in they feel comfortable that WordPress and Drupal won't go anywhere and keep getting updates, but what about PW? So help a brother out: If you had to answer "Why should I buy as website built with ProcessWire instead of Drupal or Wordpress?", what would you say? Thanks, HC
    1 point
  21. Today I had to output notes in a form at the frontend. This little code snippets show you how it can be done via the API: 1) One language site: $notesofmyfield = $page->fields->get("myfield")->notes; echo $notesofmyfield; 2) On a multilanguage site if ($user->language->name != 'default') { $notes = "notes{$user->language}"; } else { $notes = 'notes'; } $notesofmyfield = $page->fields->get("myfield")->$notes; echo $notesofmyfield; Happy coding!!
    1 point
  22. Hi, I wrote a little function for get last modified date from pages. What is this function making ? You can get last modified page modified date from given id, parent or from all pages. What can you do with last modified date? You can use it for caching pages. Here is little function and some example usages. /** * Get last modified page modified date from given $id, $parent_id, $templates_id or from all * * @param bool $id * @param bool $parent_id * @param bool $templates_id * @return mixed|string */ function getLastModified($id=false, $parent_id=false, $templates_id=false) { if(!is_null($id)) { $where = ""; if(is_bool($id) != true) { $where = " WHERE"; $where .= ($parent_id) ? " parent_id = {$id}" : " id={$id}"; $where .= ($templates_id) ? " AND templates_id = {$templates_id}" : ""; } $results = wire('db')->query("SELECT MAX(modified) as modified FROM pages{$where}"); if($results->num_rows > 0) { $result = $results->fetch_assoc(); $search = array(' ', '-', ':'); $replace = array('', '', ''); return str_replace($search, $replace, $result['modified']); } } return ""; } Gist : https://gist.github.com/trk/a9d7e01ecfa6e40b65bcExample Usages : <?php echo $cache->get("top-navigation" . getLastModified(true), function($pages) { echo renderYourNavigation(); }); ?> Here we are checking all pages and getting last modified date from database. With this way you don't need a cache time. If you update any page from your site, your cache file will be updated also. <?php echo $cache->get($page->name . getLastModified($page->id), function($page) { echo $page->title; // Do what you want... }); ?> With this usage : you can use $page->name + last modified date as cache name and you page will be cached and to be updated always.. <?php echo $cache->get('news-' . getLastModified(1234, true), function($pages) { $pages->get(1234); // Print out your news... }); ?> If you set second parameter as "true" function will check pages if have parent_id = 1234.
    1 point
  23. Usually I add the following lines in my htaccess files. Would be nice to have this or something similar in the core packages. Maybe somebody find this useful. # ----------------------------------------------------------------------------------------------- # OPTIONAL: Redirect users to the non 'www.' version of the site # For example: http://www.processwire.com/ would be redirected to https://processwire.com/ # ----------------------------------------------------------------------------------------------- RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC] RewriteRule ^(.*)$ http://%1%{REQUEST_URI} [L,R=301] # ----------------------------------------------------------------------------------------------- # OPTIONAL: Force a redirect to SSL # For example: http://processwire.com/ would be redirected to https://processwire.com/ # ----------------------------------------------------------------------------------------------- # RewriteCond %{SERVER_PORT} !^443$ # RewriteRule ^(.*)$ https://%{SERVER_NAME}%{REQUEST_URI} [L,R=301]
    1 point
  24. Just spotted a blog post about this subject. May be of interest/help.
    1 point
  25. After going through everything, looks like it's gonna be Vanilla. It looks to me like the only reasonable PHP option. I have tried every search term I could think of under the sun and even looked at some "Social Site" & "Community" software offerings. Nothing seemed to fit the bill. Vanilla is open source, responsive, & Fast and seems to cover the majority of my needs. Also has a phpBB importer and migration service that I think will save me a lot of time. Good conversation - like always on here
    1 point
  26. You need to be aware, that assets need to be synced, or images will show up as unavailable in the installation they weren't added to. Also CroppableImage does make the chosen imagefield unusable on your production site as the used fieldtype is saved in the database. I don't know if it will throw any errors as long as you do not access this field, but it certainly will if you try to access it on the production site.
    1 point
  27. https://processwire.com/talk/topic/4383-how-to-set-language-active-via-api/
    1 point
  28. Looks nice! It seems like a funny place to work: http://www.dojofuckingyeah.de/contact/ Btw, images on the bottom (JOBS section) have watermarks.
    1 point
  29. Have a look at how this is done in the Skyscraper's profile. Download the profile and look at the code, especially the search.php file. https://processwire.com/talk/topic/2491-skyscrapers-profile/ http://demo.processwire.com/ http://modules.processwire.com/modules/skyscrapers-profile/ You also need to sanitize (and maybe whitelist) all inputs (even if they are coming from HTML select options).
    1 point
  30. Seems like you're still getting an array of images, even though it should just return the single image with this field settings. Try using "$user->userimage->first()" or using Format = single for a temp. fix. Additionally I think you need to use "$img->url" in the echo line. The field not returning a Pageimage, but Pageimages seems to be a bug. It would be nice if you could report this on Github. "Method Pageimages::size" The error says enough.
    1 point
  31. @dparul: Never heard of most of them... Are they custom made by you? Or could you post a link for all of them?
    1 point
  32. Looks like quite a few people have been looking and coming to similar conclusions! Few of my random thoughts- Vanilla probably should be favourite but I just can't get on with their website mixing links to the open & commercial versions - you just don't know which version you are reading about. Discourse is lead by Jeff Atwood (stackoverflow etc) and it shows. Now that's not necessarily a bad thing, but it is maybe a bit too radical a departure. And a complete resource hog with an unhelpfully non-php backend. There are responsive (or very nearly responsive) skins/templates for quite a few forums (SMF & phpBB for example), although there are still hundreds of table based ones. There is a distinct lack of integration tools available out of the box for the vast majority of forums.
    1 point
  33. Hey, uhm, not a nice situation. Here is a case study where a agency was able to go another way: https://processwire.com/talk/topic/7494-case-study-the-triumph-of-national-geographic-traveller-india-in-processwire/ They should build a big website with one of the other systems, they switched to PW but ommitted a conversation with the client in the first place, ...
    1 point
  34. Been working in pw for nearly 5 years and it's still receiving constant updates and getting better and better. (While some other cms' have fallen by the way side). Show them some of the other agencies using pw and refer to the security supports tickets (I am yet to have had a security issue with pw which hasn't been server not application level). Also tell them Drupal is verbose and painful to template and create modules for, and Wordpress is shit for most things... Both are the case
    1 point
  35. Let's throw another comparison table into the mix https://en.wikipedia.org/wiki/Comparison_of_Internet_forum_software
    1 point
  36. Exactly . The features were actually sponsored by someone who don't wish to reveal the name .
    1 point
  37. Hi Hari, ah, ok. That's great. So I can pass it the path to a custom profile in a zip archive to install this instead of one from the PW distribution. Thanks for making it.
    1 point
  38. I missed the possibility to download a module from github if it doesn't exist in the ProcessWire module directory or if you need a specific branch. Added.
    1 point
  39. I soft-launched this site a few weeks ago and it's still being refined, however most of it is complete: http://brakhax2.com/ Brakha X2 is a production company headquarted in Los Angeles. They handle many large ad campaigns for well known brands. The bulk of the site consists of the image galleries (/advertising/, /editorials/, /silent-pictures/, etc.). The images in these galleries are not coming in via a typical images field since the images are really more like artwork pieces with it's own set of data. Therefore, I decided to create a template called "image" and a field in it called "image" (max upload of 1) in with some other fields (title, tags [not being used yet], body, etc.). These images then get assigned to each image_gallery in a Page field I created called image_items. By allowing each image / artwork piece to have it's own page, it allows for: a specific URL for each artwork piece page (example: brakhax2.com/images/name-of-the-piece/) fine control when people share images via social media (OG tags) the ability to re-use the entry in Page fields There's some fancy stuff going on in the frontend. I didn't use a CSS framework since it wouldn't have been a good match. I ended up using the following packages: Packery: this takes care of the masonry-style layout on the gallery pages ImagesLoaded: this allows the gallery images to show only after all the images have been loaded. it will show the loading graphic until everything is loaded Featherlight: this is a simple lightbox which is being used for the bios on the contact page Slick.js (aka Slick Carousel): this is being used for the video galleries (/spots/, /inside/) Fresco: a great commercial plugin that powers the lightboxes for the images and videos Responsive-nav: this takes care of the mobile menu logic Animsition: this takes care of page-to-page fade animations There's a few other little techniques/approaches being utilized on the site, but that covers all the major stuff. Eventually I will work in a Gulp workflow so that the CSS and JS is packaged and minified. Jonathan
    1 point
  40. Thanks for the pull request. If you have multi language support activated there is no label for the description field (but I want to have one) and I want to add some padding. So I check whether it's a multi language installation - but one line didn't make it into the right area. It's corrected Default: missing label and padding for description
    1 point
  41. For anyone interested this was the only way I could get it working. <? $page->of(false); $desc = $page->images_single->description; $page->of(true); echo $modules->get('TextformatterMarkdownExtra')->format($desc);
    1 point
  42. 1 point
  43. Hi there, just a small update on this for those who are interested. Finally I've got my script / download proxy up and running. This is the code that generates a list with downloadable files (in this case logos) through a repeater field. <?php foreach($page->logos as $logo) { echo "<p><a href='{$config->urls->root}download.php?pageid={$logo->id}&file={$logo->logo_file}'>{$config->urls->root}download.php?pageid={$logo->id}&file={$logo->logo_file}</a></p>"; } ?> So a download links then looks like this: http://www.domain.com/download.php?pageid=1057&file=hi_res_100_percent_pure_logo.zip Here is the download.php: <?php // bootstrap PW include("./index.php"); // make sure user is logged in if(wire("user")->isLoggedin()){ $fn = wire('input')->get->file; $pid = wire('input')->get->pageid; $filepage = wire("config")->paths->files; // put together the complete path to the file $filename = $filepage.$pid.'/'.$fn; if(!$filename) die("download not found"); // send file to browser wireSendFile($filename, array('exit' => true)); } else { wire("session")->redirect("/"); } ?> Everything works great now. However I still wanted to protect the original path of the files (assets/files/...) allthough nobody would know the exact location. To do this I modified to the .htaccess to suite my needs to block all unwanted access to files with the most common endings for downloads (e.g. zip, rar, pdf, etc.) So the part in my .htaccess which takes care of that is the following: <FilesMatch "(^#.*#|\.(htaccess|htpasswd|ini|phps|bak|config|dist|fla|in[ci]|log|psd|pdf|zip|rar|sh|sql|sw[op])|~)$"> # Apache < 2.3 <IfModule !mod_authz_core.c> Order allow,deny Deny from all Satisfy All </IfModule> # Apache 2.3 <IfModule mod_authz_core.c> Require all denied </IfModule> </FilesMatch> I found that part during my research for .htaccess modifications and finally I ended up with using that part of the HTML5 Boilerplate. I know that might be a bit strict and I don't know yet if there are any issues with that but so far everything seems to work fine. Thanks to all the helpers (especially Horst) for guiding me that way to get my solution to work.
    1 point
  44. There are a few different ways to do this, including htaccess rewrites, but this code from willyc is a good option: http://processwire.com/talk/topic/1799-routes-and-rewriting-urls/ A few other posts worth reading: http://processwire.com/talk/topic/4847-redirect-in-htaccess/ http://processwire.com/talk/topic/3275-hide-parent-page-from-url/ http://processwire.com/talk/topic/4521-how-to-customize-urls/
    1 point
  45. It sounds like you are talking about from the API side. You can work with repeaters just like any other pages, but you just have to know where to find them. Your repeater items are going to be using a template with the name of your repeater field pepended by "repeater_". So if you've got a repeater field called "slideshow", then pages within that repeater are going to be using the "repeater_slideshow" template. As a result, you can query them like this: $pages->find("template=repeater_slideshow, ..."); Repeaters are kept in the admin structure, so if your code needs to do it's thing on the front-end of your site, then you'll also want an "include=all". Note that unpublished+hidden repeaters are considered unpopulated "ready" pages, so you can safely skip over them.
    1 point
  46. I think you first have to check where you are in the tree. If you have different templates for the pages p and subpages this is easy, but if you have not, you have to check for parents and childrens. Something like: if( count($page->children) > 0 ) { $url = $page->children->first()->url; } this is true if you are on p1 or p2, then you want to go to the first child-page. If the current page has no children, you want to go to the next page, but you also have to check if there is a next page or if you are allready on the last one: if( 0 != $page->next->id ) { $url = $page->next->url; } else { $url = $page->parents->next->url; } If it's the last one you want go to the next sibling of your current parent. But you also have to check if your current parent is the last one and there is no next one too: if( 0 != $page->next->id ) { $url = $page->next->url; } elseif( 0 != $page->parents->next->id ) { $url = $page->parents->next->url; } else { // do something when on last page, hmm, - yeah ok: $url = $page->parents->first()->url; } So, this is written in the browser and not tested, but something like this will work.
    1 point
  47. Two possible ways to do this: 1) Use the Site Profile Exporter Just install it on the local installation, run it and then install Processwire with the new created setup on the new host. Don't forget to copy your templates. 2) Manual by exporting the database and import it again. Copy your local files to the Webserver. Don't forget, that some folders need write permissions for Processwire to work(/site/assets /site/config.php, ...). You should have a phpmyadmin installed on your local machine. Use it, to export the database. Then import the database on your server(again, you could use phpmyAdmin). Check, if the database connection is possible with the login details saved in the /site/config.php. You might also have to delete the session and cache files in the /site/assets directory. By reinstalling a fresh PW, you would have to create the fields and template and page stuff again. You can copy the templates but the content will be missing .
    1 point
  48. i.am first you can puut this in your head.inc tamplate or some includeded file before.u are doing $page->url $pages->addHookAfter('Page::path', null, 'hookPagePath'); function hookPagePath(HookEvent $e) { $page = $e->object; if($page->template == 'article') $e->return = "/blog/$page->name/"; }
    1 point
×
×
  • Create New...