Leaderboard

Second click has to be a bit for the right

Thanks Nico, this is basicly what I do. Though I got other github url to deal with (though it could be easily changed) but good to know github api.. I actualy also looked at your module when creating my module. New update 0.0.8 I commited a new update yesterday. Added additonal check for "allow_url_fopen" and throw error if not enabled. I changed to use copy() instead of curl. I tested it locally and on a low budget hosting and a good one, now it works on all without problems (though locally I got permission problems though not relevant). I found that using copy or file_get_contents would work better, curl gave me "open_basdir" (low budget shared hosting) error on which would cause problems if not configured correctly on server. So this should be better now. Not sure about other restrictions and limits (size?). Also improved the remove function to recusively remove the extracted folder after content is copied, it now also deleted .* files like .htaccess. If you already got it installed just click "refresh" then "update" the module. Oh and let me know if any issues arises. Edit: Heh, just refreshed and new categories and modules pop up! Love it.

Hi all, Been getting into Processwire for the past couple of days, it’s simply amazing, very nice work there (Ryan)! I’ve got a short question; I’m trying to make a field where you can input a vimeo url or vimeo video id (just as a text input), and have it load the video beneath the text field when the field loses focus. This is something that can easily be done with some javascript, but I’m wondering if I should make a custom field (module?) for this, or what the best approach would be to get this in the existing ProcessWire structure? I know that there is a module that converts urls to embed codes and displays them in a (tinymce) field, but I’d rather separate display and input here. I appreciate any insights, and thank you in advance for reading / thinking along! Best regards, Thijs

(Formerly "Two useful things I found today") When building forms, I've always liked having placeholder text in certain fields. I like my search boxes to say "Search" in them for example and have used jQuery in the past to make the text disappear when the field has focus and reappear if it loses focus but no text was entered. I was stunned a while back to find out that I'd been missing a trick in that you can simple add a placeholder attribute to your input field, but don't like that the placeholder attribute doesn't work in IE and can be flakey in other browsers. As an example for those that aren't aware, copy and paste this code into a HTML page than then in a browser other than IE, then click in the field and then back out of it: <input type="text" name="test123" placeholder="this is some placeholder text" /> Fortunately my prayers were answered today when I looked at using placeholders again instead of lots of custom jQuery code when I found this jQuery plugin: https://github.com/m...ery-placeholder It basically lets you just use the placeholder tag as above and in browsers that don't yet support it it adds workarounds to mimic that functionality Wow, I do ramble on a bit eh? Could have just posted a link there and saved burning off my fingerprints with all this typing The other thing I found today was a decent PHP class to show differences when comparing code: https://github.com/c...oulton/php-diff - it's worth a look and has basic highlighting all set up if you download it and check out the demo. Just thought those two things might be of interest to someone at some point

Cheers for the update Soma - changing from curl to copy() fixed it so that it will now download files on a default installation of XAMPP. Before that it was erroring as I don't think CURL is turned on by default in XAMPP, so whilst it's easy to change the PHP.ini file it's also great that it now works out of the box

Just thought I'd bring up one thing that sort of slows me down in the admin-interface. I think it's fair to say that the sitemap in PW is the "heart of the beast" - and as such, I feel that this could be improved in the following way: I'd like to see the sitemap (and possibly the primary admin shortcuts) stay docked on the left side of the screen - and have the sitemap maintain state, e.g. avoid reloading it on every request, and avoid having the sitemap "forget" what was open and closed. For the most part, the admin interfaces leave plenty of horizontal screen real-estate - and if the sitemap was permanently docked on the left and would collapse to a thin vertical ribbon, you could still use 98% of the page width for the admin-interface. This would probably also reduce load-time on admin pages somewhat, as the individual screens would no longer need to render the primary navigation and traverse the sitemap. Perhaps this is a theme-job. If so, I'd like to hear from someone who has written a theme, do you think this is feasible without making changes to the core? Can a theme diverge from the usual workflow in this way? Thanks!

Soma, Thanks, I forgot about that approach. I'll take a closer look at it now. This site is almost like 3 distinct sites in one, without using subdomains. I need to do something before it gets too out of control.

I think everybody thought about this. SInce I use delegate approach, one main.php that "all" templates use, I have a include to /views/basic-page.inc so it's pretty nice. More possibilities are there using includes.

The subfields on page references update is now committed in the core so that you can do these types of queries (as mentioned above): referenced_pages.title*=$query Also want to mention a limitation: You can't do this with in-memory selection (at least not yet). So the find(), filter() and not() in WireArray/PageArray won't recognize this… just the PageFinder ($pages API var). I'm guessing it'll be awhile before someone even tries it, but just wanted to mention it. I think so. It was a pretty simple matter supporting the subfields of page references, so I think the same would go for parent. I will look into it here more and hopefully get this added soon. Seems like a very nice thing to have. This bug should now be fixed and committed to the core. It sounds like MadeMyDay mentioned this issue too (?), but somehow I missed that message. Thanks to both of you for tracking it down and sorry I missed the message about it the first time around.

That's the ticket. Thanks Ryan. You've probably written the equivalent of a Steven King novel by now just answering the questions of people like me. I hope you never get tired of it. It's appreciated.

There are a lot of useful polyfills like this jquery plugin out there. Have a look here: https://github.com/Modernizr/Modernizr/wiki/HTML5-Cross-browser-Polyfills I like especially the web forms polyfills. Nearly every html5 form feature can be used now in every browser! Thanks for mentioning php-diff - could be useful for an upcoming project.

Awesome! I hadn't seen HTML Kickstart before, looks really cool. I've used Skeleton and Bootstrap quite a bit, both are great.

@SiNNuT either here or GitHub is fine. But since we're here, might as well just submit it here. I did commit a few updates this morning, including a fix for the /site/profile/ vs. /site/templates/ typo. I honestly have no idea where I got /site/profile/ from… I need to get more sleep.

I would go ahead and do the redirect that you are talking about. Most likely your output is getting generated before your $page->save(), so the redirect should solve that issue. It also prevents a 'reload/refresh' from re-submitting the form. Basically, there are a few good reasons to redirect after a save, and that's also what PW does in it's admin. You don't necessarily have to redirect to another page, you could just redirect back to the same page, right after you complete the $page->save(), i.e. $page->save(); $session->redirect('./');

Joshua's HTML Kickstart is excellent if you want some neat stuff out of the box and the files are split up nicely if you only need a few things as well. I've got some things I'd like to use that for. At the other end of the scale, I'd quite like to use Skeleton for a project I'm starting soon as it doesn't make too many assumptions and gives you a bit of a head start whilst doing some of the boring stuff for you (setting up base classes etc). I think though that like ryan has done on the ProcessWire blog profile that I'll tweak it to scale a bit wider than its default. As yellowled quite correctly points out though, it all depends what you're after.

Nice Job Pete. Before GitHub for Windows i was using SmartGit, which has more features and power but also can be quite confusing at times. So for my basic needs GitHub for Windows works fine. I would recommend adding a small section about contributing to existing projects. It's not that hard an can be useful, even if all you did was correct some typos or indenting in the PW codebase, like i've done in the past being the coding lightweight that i am. All little things count. In a nutshell: Fork - Go to https://github.com/r...ign/ProcessWire - Click the "Fork" button in the top-right corner - Visit your own PW fork page if your not already taken there automatically (https://github.com/MY_USERNAME/ProcessWire) Clone - Click "Clone in Windows" in the top-left corner. - This will open up "GitHub for Windows" and after a short wait you will see a local repo of your fork.Configure remotes Configure remotes This allows you keep in sync with changes made to the original codebase (e.g. Ryan's repo) - In "GitHub for Windows" local repositories view, right-click and choose "open a shell here" - This will open a shell already in the right directory. Type the following commands: git remote add upstream https://github.com/ryancramerdesign/ProcessWire.git # Assigns the original repo to a remote called "upstream" git fetch upstream # Pulls in changes from the original repo not present in your local repository, without modifying your files. Allows you to review first. git merge upstream/master # merge fetched changes into your working files. Syncing and pull request If you've merged upstream changes you can then sync them with your GitHub fork via the 'sync' button. The same goes for changes you made yourself. If you think PW would benefit from these changes you can send a pull request. Go to your fork on GitHub and click the button "Pull Request". - out of time - Anyways, you've put it in pdf but is it an idea to put it on wiki.processwire.com as well?

Attached is an update to /wire/modules/Fieldtype/FieldtypePage.module that lets you do this, once you replace your existing file with the one below. You should be able to specify just about any native or custom page field after the dot, like above (where we're using 'title'). If anyone can test it out to confirm I'd appreciate it. I'll commit to the source after testing a little more locally too. FieldtypePage.module This type of syntax is already used by repeaters. But if you mean something like: "repeater_field.referenced_pages.title%=$query", I don't think the attached update would let you do that, though havent' tried. If it doesn't, it's probably not much of a stretch to support it though.

It's possible that there is some site out there using ProcessWire with hundreds of thousands of pages, but if there is, I don't know about it yet. I haven't gone above ~50k pages myself, though I don't think it would be a problem to scale as large as you need it to. It's not like an odometer on a car where there is a max upper limit and the higher you get, the more you are taxing the system. Whether your site has 100 pages or 100k pages, ProcessWire itself isn't dealing with any more data at a given time (only MySQL is). Scale should not affect the performance of the admin UI either. I actually think that the admin lends itself very well to large scale, and the larger scale you go, the more you'll appreciate some of the ways it does things. That's what it was originally designed for after all. As scale increases, you just have to be more careful about how you develop things. You need to be conscious of calls like $page->children and be sure you are placing limits on quantity of results returned from such functions, i.e. $page->children('limit=50'); More about that here. When dealing with high traffic, you need to consider caching at various levels. Know when to use template caching and markup caching. Optimize some situations with autojoin fields. You might also investigate FieldtypeCache to potentially reduce page load times and increase the speed of multi-field text searches. Make sure your PHP is running with an opcode cache like eAccelerator or APC. I'm also working on an htaccess/rewrite cache for ProcessWire (like WordPress W3C Supercache), but it's not done yet. The advantage of this will be that you can direct some pages to be delivered directly from the markup file (via some complex rewrite rules), bypassing PHP, MySQL and ProcessWire completely. I don't have anything to add about multi-server setups, but interested in hearing if anyone else has experimented here.