Pete

Coming in a bit late to the party, but I think I found this on StackOverflow and modified it for my needs - matches most if not all of YT's many URLs: preg_match('%(?:youtube(?:-nocookie)?\.com/(?:[^/]+/.+/|(?:v|e(?:mbed)?)/|.*[?&]v=)|youtu\.be/)([^"&?/ ]{11})%i', $page->video, $match); In fact, here's the solution (second post) with all the URLs it matches: http://stackoverflow...sing-preg-match Matches the following: https://youtu.be/dQw4w9WgXcQ ... https://www.youtube.com/embed/dQw4w9WgXcQ ... https://www.youtube.com/watch?v=dQw4w9WgXcQ ... https://www.youtube.com/?v=dQw4w9WgXcQ ... https://www.youtube.com/v/dQw4w9WgXcQ ... https://www.youtube.com/e/dQw4w9WgXcQ ... https://www.youtube.com/user/username#p/u/11/dQw4w9WgXcQ ... https://www.youtube.com/sandalsResorts#p/c/54B8C800269D7C1B/0/dQw4w9WgXcQ ... https://www.youtube.com/watch?feature=player_embedded&v=dQw4w9WgXcQ ... https://www.youtube.com/?feature=player_embedded&v=dQw4w9WgXcQ ...

Hi Marc No probs - I'll dig it out soon (honest ). I was testing a newer version today and it had a few unwanted side-effects so I'll have to sort those out first.

No problem ryan - it was easy enough for me to work out in the end as I knew the repeater page was being created so there was only going to be one reason why it wasn't showing. $newRepeater->status = Page::statusOn; That's a bit easier - thanks!

I'm glad you stressed that as depending on what you were after I might have suggested other ways of doing a community site (the easiest being using something like the community suite - forums, CMS etc - here: http://www.invisionpower.com/ since they're pre-built and function together well. But then you'd be at the other end of the scale from PW in terms of customisability and ease of use if you wanted to do anything outside of what the core package handles). To learn PW, my aim was to rebuild StrategyCore in PW as I could see how to do everything in my head and it was just a case of working it all out. It really helps to have a project in mind that you've got no set deadline for when you're learning something new, as long as you've got the time to do it. I ended up spending about 3 months' of evenings on that site, but I'll stress that easily half of that was just trying to get the forum software integrated in terms of article comments and user logins, so PW was the easy bit, including importing all the content from the previous system. The beauty of having done that is that I now have a decent code-base for those projects in my head that are mostly community-based sites with core functionality something along the lines of ryan's sites. I ended up with quite a lot of code in my head.inc file that's used on various different templates. I just pulled all of that out as it was getting quite messy and stuck it into a global.php file instead in the templates directory. If you have code specific to different templates that you don't want to clutter up the template itself the you could easily create a "controllers" subdirectory and put it in there. Theoretically the easiest way to go about it would be to create that "controllers" subdir and put in a file for each for your templates with the same name, then in head.inc do something like: include('controllers/' . $page->template . '.php'); And you've successfully split out most of the code from your templates with minimum effort That's the thing about PW - you can work pretty much any way you like with it (and I honestly wish I'd thought of the above sooner - oh well, next time!). What I've just suggested above would be desirable on my website because I have so many templates that it would have been better to split it all out a bit and not have so many loops or selectors happening in the template itself. Instead I could have separated much of that out as I honestly scratch my head a few times when looking back through some older templates I'd made. That said, it depends quite a bit on how complex the project is and what your preferred method of working is. For a simple website I wouldn't bother doing the above, but for a site with section-specific, complex structure then it could well be worth it. If you're working in a team of one, then it's up to you how you go about it and I often find myself falling into the bad habit of mixing and matching ways of working within a single project as I learn new things - fine for my own stuff, but crazy if someone else has to work on a project (fortunately they don't). I think that after watching the video on the PW homepage it was that site, plus tripsite.com (another of ryan's creations for a client) were the things that really drew me in to PW. I've got so many projects in my head along those lines and I just need time to work on them. Some of them might even make some money if I stop working on hobby sites

Got it When creating a page in the API its default status is published, whereas items entered into a repeater in the API seem to be unpublished and hidden. As such, you need to do the following to each item in the repeater: $pageid = [your page generated via the API that contains the repeater] - must be saved before adding the repeater items in order to get the page ID $repeaterpage = wire('pages')->get($pageid)->repeater_field->first(); $repeaterpage->removeStatus(Page::statusUnpublished); $repeaterpage->removeStatus(Page::statusHidden); $repeaterpage->save(); The code above only does it for the first item, but for my needs each repeater is only being imported with a single item for now and other items will be added over time - if you had more items in the repeater you would need to iterate through them of course. Just needed some sleep and a morning coffee for this one I should have 600+ files imported from a third-party file management script by the end of the weekend now - just got a wedding to go to in the meantime else I'd have this all wrapped up by lunchtime I reckon

I think it might be that the created repeater item isn't published? Not sure though...

Cheers - I'd be nowhere without your wrapper though To be honest I can't envisage many scenarios where I wouldn't use PW, unless it was for something very specific like forum software (and even then apeisa has made a forums module). I personally never got into MVC as I found it too rigid for my liking, though that does potentially lend itself to a cleaner workflow when you're part of a team (it still depends on how well documented and presented each team members' code is though ). I suppose I don't mind mixing my code up a bit as it's only generally going to be me working on a site and I know my way around PHP, HTML and JavaScript so it doesn't bother me that they sometimes get mingled in a bit. I would say that the answer to your question depends greatly upon what sort of application you are looking to build. Can you give us any examples? Using some real world apps as examples: If I was building something like Freshbooks I'd use custom tables for the invoice data, but I'd be tempted to use PW for user accounts, and store additional user data with that account data. The bulk emails could easily be handled by Flourish. If I were doing something more specific like creating a project management system like ActiveCollab I reckon I could do it in PW despite the complexities of what you can do in AC, but why reinvent the wheel? If I was building a portal for estate agents like RightMove (and the thought has crossed my mind) then that would be ideal for PW (and a bit of Flourish) and I'd just need to create a front-end interface for the estate agents to log into and manage their own property's which, again, is relatively easy with PW. The front-end of the site would then be pretty similar to something like this site ryan created: http://www.villarental.com/

I'm using this example from earlier on in this thread: $repeater = wire('fields')->get('my_repeater'); $item = $repeater->type->getBlankRepeaterPage($page, $repeater); $item->title = 'Test item'; $item->summary = 'This is just a test item'; $page->my_repeater->add($item); $page->save(); I notice that when I go to edit the page created via the API via the admin area that the repeater is showing the "Add" link and not the item I added to the repeater. It does however show my entry when I click the "Add Item" link, so it works in that it's been saved into the the system, but for some reason until I save that page by clicking Save when editing it in the admin, it doesn't realise that the repeater has an entry. Any ideas? (As I'm a glutton for punishment, one of the fields inside the repeater was a file field, so I had lots of fun there with the file field being able to accept multiple files and the repeater being able to accept multiple sets of that field ).

Funnily enough I do have this in a later version that I've not quite polished up yet, so I'll take a look at it soon. My requirement was that articles (which would produce the tweet) could be linked to various categories or companies, each of which had their own field for hashtags/DM's etc. There was also some code to prevent it posting duplicate hashtags and so on. I'll dig out the code hopefully tonight.

Seems like a lot of people are having similar ideas which is good because so am I Soma - that module looks very handy and I'm sure I'll be referring back to it further down the line.

That'll be fine - I'm off tomorrow through til Monday to finish decorating the house but I definitely don't want to be doing that all day every day so I'll have time to set this up. As long as we don't plan on using it forever I'm fine with it - it can become a bit of a resource hog over time and we would need to keep an eye out for spammers but this server should definitely be able to handle it. My knowledge is reasonably good in terms of setting it up but a bit flakey in terms of day to day operation so if nothing else it'll be a learning experience

ryan - MediaWiki does have a lot of initial settings to tweak and there are quite a few recommended addon modules to install to prevent it becoming a spammer's paradise so I'm happy to set this all up. I'm not sure about the bridge requirements, but it should be fine with being on an isolated subdomain as the database host will still be at the same IP address (depending on servers sometimes using "localhost" in the DB connection on a subdomain doesn't necessarily give you access to the parent domain, which would be required for the bridge to work of course). If all else fails it could go under processwire.com/wiki (or guide or whichever name we're going with) instead, but I'm pretty sure we can make it work fine on a subdomain.

Have you moved to Australia or have you been working on a time machine recently? I know, unnecessarily picky

Wiki.processwire.com I think. There used to be a "bridge" for Mediawiki that integrated the IPB logins but that was a long time ago. I can look into it as that would be useful. Edit: here it is - works for version 3.2 of the forum software do very likely works for 3.3 too: http://www.ipbwiki.com/ Edit2: I need to upgrade the forums - I hate reading what I think is the last page of a topic on my phone and it's not - I end up repeating other people you'll be glad to know the latest version jumps to the last unread post in a topic on the mobile version - I just need to test it before upgrading (hopefully later today).

Cheers for the links Charlie. Thanks Ray, I'll definitely be doing a case study at some point, just got a few other projects on the go at the moment.

I think you would have to have your-url/?test=1 or something like that, otherwise if you add it to the end it will look for that URL as a page first, unless you turn on URL segments for every page too. I could be wrong though and it could be pretty simple as a module that runs before page render and intercepts the URL.

My main concern is another bit of software to maintain - I've got experience with MediaWiki but it's definitely not fun to run when it reaches a certain size. I also don't like having different logins for different software on the same website - it should be as easy as possible for users to contribute with just one login, which is where a lot of this falls down unfortunately. Is there not something we could do with ProcessWire? I mean, how complicated are we thinking of going with the manual? I get that wikis are great because you can discuss the page that's being edited, plus there is a revision history, but aside from the revision history (at the moment!) this sounds like something you could achieve with a PW install and the comments module. In terms of a login system it should be easy enough to tie in the forum logins with PW users. I'd actually say that we shouldn't rush into this. I like the ideas and the momentum but I would hate for us to use the wrong software for the job (not saying my suggestion is right either, I just don't really like MediaWiki as it's old and slow - there are likely other, newer systems out there that should be considered if we were to go down the wiki route). Edit: I was only really reading the last post so I didn't spot all the other comments saying "why not use PW?" until just now

It says you're a senior member now - you must be getting older

That's good to know ryan, even though I'm not sure if it's doing any harm with that many files. I was just curious as to why it needed so many empty files. Is it more of a "just in case" thing in case any session vars get set or something?

I think this is a common scenario here I think it's fair to say that as a community there are PHP programmers at all levels here - I still wouldn't consider myself an expert by any means and I like the fact that ProcessWire not only gets you started quickly but also that if I enjoy working with something I'll learn more about the languages that it uses - I've learned a lot more PHP in the last few months than in the last few years I think as well as some neat things about jQuery that I didn't know, and being able to go through clean, well thought out code definitely helps the learning experience.

Good work, glad you got it sorted and thanks for posting your working code - that's always useful If you're posting more code in future though, could you use the code tags button (looks like this in blue: <> ) just makes it a bit easier to read - thanks! I've just tweaked your posts to make it a bit easier to follow for others.

Indeed - basic editing is the key. Everything from logging in, creating pages, editing and deleting pages, TincMCE fields (just the basic set of buttons would be great) and other common fields from a standard installation would be great. If we decide to go a bit further and write instructions on how to deal with date fields etc then that's not a problem as anything that's not relevant can be deleted on a per-client basis, but takes longer to add it every time

Welcome back, and well done for resisting the urge to check in

For the majority of areas where things would be the same this makes sense, but as soon as you come across custom templates (most non-basic websites I guess) then there will obviously need to be some work - that said I do like the idea of a collaborative base manual from which to customise.

I think it might be due to some JavaScript - I was trying to figure out the bed way to stick the footer to the bottom if te screen but I guess the code (or possibly my CSS) isn't that great. Thanks for the kind words folks. I'm still hoping to do that case study at some point, but I suspect it'll be a week or two as I've still got other things to tweak. It was a long process, but very enjoyable (and it helped that pretty much every feature I thought I needed at any given time during the planning ang the build magically materialised in ProcessWire - like Ryan was reading my mind!). The other good thing is that I also have a lot of code handy now to use on other sites, and might have a module or two to release at a later date too I've got a site a bit like one of Ryan's holiday villa sites to build at some point (but for camping - the other end of the scale ) - another personal project.