muzzer

A little out of my comfort zone here; Is it possible to replace a core method in PW: class ExtendedWireArray extends WireArray { public function findRandomTimed($num, $seed = 'Ymd') { // new code } } Reason: I have Suhosin apache security extension installed which means the findRandomTimed() method does not work correctly as php seeding is overwritten by Suhosin. I need to alter the function to use my own seeded random generator, but hacking the core is obviously not a good idea. Is a module the way this is normally done or can I simply extend the WireArray class somehow?

Thx @sforsman Yeh, shared host for this site so no php.ini access. Have tried setting this in .user.ini which also has no effect (although other settings - gd etc - can be set here successfully). Also tried in .htaccess, no luck. I'm wondering how widespread the use of suhosin is - fairly widespread I would guess. In which case perhaps the core function findRandomTimed() should use it's own randomising logic rather than php rand()?

yep, year or so ago it looked like Evo was dead and the "future" was Revo, which I could not stomach personally, Revo just never seemed ti hit me the was evolution did. I think a lot of users came to PW around that time as ongoing Evo support and security fixes were in serious doubt, leaving the platform as useless for commercial dev. Sad about missing Evo too, but so glad to be here at PW.

Hmm, I have this code working (changes order or listings daily) on my dev server but it fails on live server: $listings = wire('pages')->get('/listings/')->find('listingActive=1')->findRandomTimed(5); I'm using PW2.5. The result on live is a different order on every call, on dev the order changes daily as it is supposed to. I suspect the apache Suhosin extension on the live server is screwing this up as I believe it overrides PHPs rand function and changes seeding in some way. Anyone else seen this issue or have any ideas on making this work in conjunction with Suhosin.

Have to agree with diogo here. Where does it end? I'd like an invoicing and time-keeping aspect, perhaps a jquery gallery? Anyone else want some goodies? The beauty of PW to me is that the core is light, quick and is actually pretty easy to get you head around once you delve a little out of your comfort zone. The API is superb and allows you to do so much so easily, add modules and you have the perfect base. Please, it's not broken stop trying to fix it ;-)

http://processwire.com/docs/tutorials/ The only way to learn (that I know of) is to download, read up, and try out some code. Honestly, until you do this the amount of help anyone can offer is limited. Jump in the deep end bro.

Pressure huh? Have you thought perhaps it's time for a new GF? ;-)

Sorry, obviously did not explain that very well. The PW API is extremely good - as as a result some cases where you would install a module in modX there is simply no need in PW. It's been awhile since I used modx but from memory (as an example) there is a module "getField" to help get a page element from any page. In PW you would use a simple API call to get any element from any page, no added modules required. To me that just feels like the "right way" to do it. Martijn probably explained it better in comment #2 above. BTW, another thing to be aware of is that more modules is not always a good thing - lot of modules often resolves to more potential security issues. PW is extremely secure as far as I can tell and Ryan (main developer) vets most publically available modules too I believe. This is a definite plus for me.

I used modX heavily for 2-3 years and thought it was the bomb. When I found PW I realised modx was good but was not the holy grail I originally thought. Modules in PW seem to be a lot tighter than in modX - they just seem to work. But to be honest, I hardly ever reach for a module in PW - the core and brilliant API provide so much functionality that modules are often completely unnecessary for lesser complex sites. Community in both platforms is great, the difference is there is a core of extremely knowledgable people here at PW, and they are always willing to help. The willingness to provide assistance at the modX forum is also good and the users I found to be very friendly, but I found many users were not so knowledgeable and so the information provided was not of such a high standard. Sometimes actually just plain incorrect. These are just my observations, I hope they help. For the record, I really rate modX and it's developers, it's leagues ahead of many similar CMS/CMFs, but having now experienced PW for about a year I would not go back. No way. It's be like going back to using a 56k modem, so sad!

Thanks for all the replies guys, been a bit of an eye-opener for me. Some wonderful replies and perspectives. I'm definitely lagging behind developers in Europe/US in regards to design for mobile devices (and other screen sizes, thanks Teppo). Pete, I think you are right, New Zealand is certainly "laid-back" and probably a bit behind the times as a result. Most developers here still develop for IE7 (and some even IE6), which I suspect you guys don't stress over these days. Tablets etc are common here but certainly not to the extent of the US etc. Sinnut, Martijn etc, agree with your comments regarding CSS and frameworks and bloat. I've got some thinking to do regarding this subject. I'm now looking forward to attacking RWD, something I was always happy to avoid. It's great to hear what other developers are up to. I live in a small town in a country at the other end of the globe and as a result I don't get to mix with others in my field (other than in forums like this) so it's bloody good to get others perspectives on these thing. Cheers all

He he! Hey Bernhard. thanks for the honest feedback. Even my wife ain't "that" honest ;-) Unfortunately most tourism and business operators in NZ are "older" and a tad conservative - give them a modern theme and and older theme and they'll almost always go "ohh I like that!" at the older one. But thats ok, I gave up designing sites the way I would like them ages ago in favour of making a living! Also, I've found that often designs that designers think look great most other people often think look crappy. Re: responsive, yeah, again possible a locality thing, they aint that big here. And responsive sites are perhaps a bit over-hyped in my opinion. I probably should do the "responsive" thing (which BTW is easy enough, you don't need a downloaded theme to achieve this), maybe I'll have a think on this. Out of interest, anyone else out there want to comment on the responsive aspect Bernhard touched on? - how important do you guys think this is? Most users have tablets or phones which can display 960px sideways, so does a 960px site wide really need to crunch itself down width-ways and be 3 miles deep just to fit a portrait screen?

Added a few new sites from New Zealand to the PW directory. Real MTB Adventures Uncharted Wilderness Tours Springlands Veterinary Centre PW has made building these sites super-easy. Two of the above include tour booking systems made with PW pages and PW API, all very simple to implement. Loving working in PW. The above are very basic sites, but I'm especially enjoying developing more complex sites utilizing the slick API, creating and amending pages on the fly, dynamically creating PDFs, booking and listing systems, and credit/debit registers . It just works so nicely

hey joer80, Did something very similar to this recently. This link may be of some help.

Hey Adrian, I've got a merging of two PWs to deal with and I was wondering if this was possible with Migrator. PW Site One essentially contains client information (business data - names, addresses, descriptions etc) PW Site Two contains invoicing information - a site developed to track user billing and payment for the businesses in PW Site One. What I would like is to merge the two sites so the Site Two pages would become a branch of the Site One Tree, eg /invoicing/siteTwo However, it looks like Migrator is developed to migrate dev to live etc, so presumably page ids would be the same etc. What happens if a data page from Site Two has the same id as a invoicing page from Site One for example. Is this magically 'handled' or would a overwrite occur?

Solution was simpler than I thought (Thanks @Sumurai8 at Stack Overflow). Damn, .htaccess rewrites screw with my brain..... # rewrite the URL: folderTwo/* to http://domainTwo.com/* # as we want domainTwo.com/folderTwo to look like domainTwo/ # this works for any domain, so will rewrite: # http://domain.com/folderTwo/* # http://domainTwo.com/folderTwo/* etc # to http://domainTwo.com/* RewriteCond %{REQUEST_FILENAME} !-f RewriteRule ^folderTwo/?(.*)$ http://domainTwo.com/$1 [R,L] # redirects domainTwo.com to the PW /folderTwo folder RewriteCond %{HTTP_HOST} domainTwo\.com$ [NC] RewriteCond %{REQUEST_FILENAME} !-f RewriteRule ^(.*)$ /index.php?it=/folderTwo/$1 [L,QSA]

Thanks guys, I should have been clearer; I know how to set up tow seperate websites with addon domains in cPanel etc. But in this case both these domains need to use the same PW install/website. So the domainTwo.com which points to /folderTwo still needs to run the index.php in the root folder. @Nico, If I set up simply as a addon in cPanel wont this mean the root folder is bypassed completely? So /index.php will never be run so PW will never be initialised?

Hey, .htaccess is doing my head in. Any help from resident experts would be massively appreciated. Here's the PW structure; |--- home |--- folderOne |--- folderTwo |--- subfolderA |--- subfolderB |--- subfolderC |--- folderThree |--- etc I have two domains and want the following: domain.com should point to the root folder (home template) which it does, standard setup. domainTwo.com (addon domain in cPanel) should point to and render /folderTwo and URL should be http://domainTwo.com the page /folderTwo/subfolderA should be accessable from http://domainTwo.com/subfolderA. I would have thought the following: RewriteCond %{HTTP_HOST} domainTwo\.com$ [NC] RewriteRule ^$ /index.php?it=folderTwo [L,QSA] This is driving me nuts, Anyone?

If you can get this module going it would be pretty sweet and I'd be happy to pay for this functionality. In my experience with client-editable sites and local development the process usually follows a pretty regular pattern; Most updates are relatively minor, eg they may take perhaps 1 hour to 1 day max. In these cases its a matter of downloading the database from live (phpmyadmin), import into dev database (again phpmyadmin), do the alterations locally and then reverse the previous import/export back to live. Tedious but manageable To make this process easier two modules would be adequate in my mind: an easy export/download of the PW database from live (one-click from within the admin, not from phpmyadmin) and an easy import (again from within admin) of the download PW tables into the dev database. A simple method to temporarily block all clients ability to login to the live site while development is underway, to prevent overwrites. If clients do try to login then a message "Sorry, you cannot login at this time as development is underway.You will be notified by email when this is complete. The estimated completion of development from now is 3 hrs and 14 minutes". Any client who tries to login will be added to a list and those clients automatically emailed when development is complete and the login block removed. To enable the block the admin (perhaps this could work in conjunction with the download module in 1 above) would simply enter a estimated time required for development and hit "Block clients" button. The estimated time would be used to advise clients who try to login of how long they will likely need to wait before they can login Just my two cents. I had a similar setup in the past in modx sites and it worked well for me.

Thanks for that Can, You're right, images do seem to float, unfortunately when I replace the image with a div it fails. Looks like all pdf classes have similar issues and this is obviously not an easy thing to get working reliably <div> <div style="float:right;width:100px;height:100px"> <p>Small div text</p> </div> <p>text in here should wrap floated internal div. When internal div is replaced with a floated image it works, but as a div it fails. Bummer</p> </div>

Yeah thanks Can. Only thing I'm coming unwound on is wrapping text around a right-floated image. Looks like this is something that cannot be done with mpdf. If anyone has an solution to this I'd love to know. Cheers

Dude! I've always wanted to do on-the-fly PDF brochures of some pages on a site I have, but have always put it off as thinking I don't have enough spare time to justify it, and don;t really want to fight stupid PDF libraries to get a decent result.. Well, after reading your tut I decided it looked easier than I have previously thought. In about 2 hours this morning I've nailed this with some outstanding results, sooo easy! I thought there would be issues getting PDF data to display right etc (these things are never straight-forward) but no, mpdf is the bomb! So thanks for the enticing post that got me going with this, and guys, if you like me think PDF generation will be more trouble than it's worth, I encourage you to give it a go.

Hey Teppo, love the module, very smooth. I did have problems setting the name for the "to" header, ie $mail->toName = $name, or $mail->to( $addr, $name ). Neither seemed to work for me. I've replaced the top of the ___init() function as follows to make this work, may be of some use to you: public function ___send() { foreach( $this->to as $k => $v ) $toAddr[$k] = $this->toName[$k]; // create the message $message = Swift_Message::newInstance() ->setTo($toAddr) ->setSubject($this->subject); Thanks again for the module

Wow, very thorough instructions Ryan. As you say it's unlikely PW will be exploited in a DrumlaPress manner, but still, this is a really great writeup largely relevant to cleaning any hacked website. Should perhaps be pinned?

Looks cool, but am I correct in saying you need shell access on your hosting server to use this module as you need to install jpegoptim?

Hey Ryan, Thanks for the extensive response. I'll download and try the dev branch and see how that goes, looks like some great improvements. Regarding boot times for processwire; I appreciate that PW is doing a lot of work initially to provide the great API, and I put a lot of the processing time down to this, it's well worthwhile to get the API PW provides. With regards to Modx (Evo) I think modx is definitely more 'basic' than PW but I have to say it also seems blazingly fast. I always wondered if this was simply down to the database style - having all page fields in one page record rather than pulling 30 different field values from 30 different tables when selecting page data. I don't know enough about how you do the database magic in PW to know if this is a point of difference, and my knowledge of SQL is good only to a certain level - modx style. I appreciate we are only talking about milliseconds here, and even 100ms is almost impossible to notice. But from an SEO/pagespeed point of view it is important. I guess the reason I've got a bit pedantic about this is I've converted a modx site to PW and seen it slow down which is not the result I was after! The slowdown was quite extensive until I started using Markup Cache which is so simple to use and so effective. Now with caching the site is loading probably 200ms slower than essentially the same site on Modx, which I'm happy with. Markup Cache: This seems to be a little known and underrated tool. There is not a lot in the documentation or forums about this module. When I get a moment I'll write up a page about markup cache as it seems to me it is not used by many PW users but I've personally found it to be incredibly useful. It's taken some of my heavier pages from sluggish to quick while allowing me to keep dynamic pages dynamic "in part" rather than serving a completely static page using other caching methods. This allows me to collect stats, log views of certains part of a page etc. Keep up the good work bro, you are an inspiration.