netcarver

Hello & welcome to the forum Radek! It was really nice to meet you on IRC a few days ago too -- I hope you will join us regularly.

<$0.02> Re: CDNs. Take a look at ScaleEngine; they have a specific product (OWS) for deploying scalable PHP/SQL applications. </$0.02>

@Matthew What I had in mind here was really to encourage more regional meetups first, a bit like Linux User Groups (not just Linux, I'm sure there are other groups that are similar) and if there are enough people using PW near one place then even "local" user groups might be possible. That said, if we do manage to arrange some meet-ups here in the UK, I can't imagine that we'd turn away any PW user who can make it. @Joss Sounds interesting but the date's a little further out than I was initially thinking. Perhaps that would be suitable for a "national" level PW meet-up? But there's certainly room for flexibility here. Going by what people have declared in their forum profiles there are a number of PWers in the London area (such as Panictree, ffub, selfthinker, Lars282, antknight & potentially others) and there is another "cluster" around the Manchester area (Gazley, Pete, DaveP, Onjegolders, myself & maybe some others.) For traveling convenience this sparked the regional meetup idea but if that spreads us too thinly then opening it up wider might well be better.

Just bumping this as we have several new UK-based members posting in the forum now. For what it's worth, I'd still be interested in meeting up with some PW folks in the Manchester/Birmingham/Bristol area but perhaps there are now enough UK based users to allow for something like regional PW user groups? There are several folks based along the West Coast "corridor" (M5/M6) and another cluster in the London area. Whilst Ryan's conference is on hold, perhaps we should arrange some meetings of our own in 2013 -- even if they are mainly social events with little additional planning.

You could try bit-scraping your filesystem for whatever you can get. You might still end up with nothing though.

Ouch

Restore from backup?

Also, are you sure line #53 of your gist is getting called?

<guess> Looks like you are asking PW to hook a static method but the method isn't declared static nor is it called as static. Could you try adding the hook directly to your singular module's processIpn() method instead? Like so... $this->modules->get("PaymentGatewayPayPal")->addHookBefore("processIpn" , ... ); </guess> Aside: Paypal IPNs are interesting beasts. You still need to apply business logic after you get a valid result back from the IPN service though -- particularly checking the transaction ID hasn't been used before so as to avoid potential replay attacks.

If you do use SSL certs for parts of the site, and if those parts are not 'public' you could try using self-signed certs as you probably don't need to go to the expense of getting anything fancy from a "trusted" third party.

@nik, perhaps Pete can add a "love this" button

Hi Nicole & welcome to the PW forums, I've not written any FieldType extensions yet but does making this change help?... public function ___getConfigInputfields(Field $field) { $inputfields = parent::___getConfigInputfields($field); ... // rest of this method's code as per your original getConfigInputfields() code.

Hello again vanni, I think many of the TxP folks who have migrated over to PW have been in the same position. Take Tom Reno (renobird) for example; he's become very capable with PHP thanks to having to learn PW templates in a short period of time. There are good resources to help with this; template documentation on the main site, clear code examples on the forum (just browse for a while or google for them), an amazing blog profile for PW with lots of templates to use, an IRC channel and tools like Soma's cool API cheat sheet. Whilst TxP's parsed template tags are easy to use if you are used to writing X/HTML documents, you often have to spend time digging into the tag or plugin documentation to find out which attribute does what. With PHP you will have to learn some new things too, but once you know them you will have additional flexibility for your template handlers that isn't available without custom coding stuff in TxP and you will have a transferable skill which you won't have if you are putting time into learning TxPs unique tags. In addition, using PHP as the template language means the templates don't need to go through an additional parser.

The v2.5.1 version of textile just gained better support for responsive layouts by optionally omitting dimensions from images. I'll have to work out how to make the TextileTextformatter modules configurable before I can add a control into the module for this feature. I'm beginning to think that I might just make omitting the dimensions the default in PW for now.

Hi vanni & welcome to the PW forum. Yes, that's correct, in PW the equivalent of TxP forms & pages are file based so you get to edit them with the editor of your choice and/or version control them all. There are differences in terminology between PW and TxP too and "template" is one of them. Attached is an image that might help explain some of the PW terminology (with props to SiNNuT for the starter idea.) If I remember correctly, there is also a module for PW that allows you to edit your template files via the admin interface but I haven't used this myself and I may have that wrong. Another major difference between TxP and PW is that PW uses PHP as the template file language whilst TxP has its own tag system that it has to parse. Hope that whets your appetite a little and that you enjoy trying out PW.

Just updated these formatters for textile v2.5.1 which was released about an hour ago. HNY!

Here's the box on my "desk"*. Still hanging in there. * Actually a salvaged door.

Hi Pete, Interesting to hear about your use/planned use of one of the Amazon data feeds & PW. I run a little shop listing about 50k items on Amazon at present, some custom coding but mainly using a commercial, closed source, product that I'm now working on replacing as it is too inflexible & expensive for our processes. I've been looking at libraries for the replacement work and found another link you might want to consider if you have pro-merchant account access; this fork of guzzle-aws includes an implementation of Amazon's MWS API. If you don't have a pro merchant account, sticking with the product advertising API feed is free. BTW, the link I've included is for source code that is driving a live shop and seems to have very recent activity. I'm just about to start using it. If you do store data locally just be aware that the terms of service for the APIs have a max cache-time clause to keep price info fresh (24 hours max IIRC.)

Were those results obtained over an internet connection, your local lan, or testing on localhost? I did some benchmarking of my own a while back and as part of that I benchmarked static file serving times on Apache2 and nginx. I was getting times in the order of 56μs per read from Apache2 and far less on nginx but that wasn't over the internet. FWIW, here are some apachebench results for default installs of PW on Apache2... ...the "failed attempts" are false-positives as the default site homepage has a random image. (Apachebench assumes all reads will lead to the same sized data and flags all following reads that return different size pages as "failed requests".)

Hello kongondo & welcome to the PW forum. Whilst I agree that Ryan's produced an amazing product in ProcessWire I think it goes beyond just the software. Of the CMS devs I've been involved with Ryan's the one project lead who has been the most open, from first contact, to meaningful contributions towards the site, docs, forum and code. Some others have been open, most friendly, but none to the same degree. Consequently he's attracted a welcoming, talented & professional group of people to the project and I've learned a lot from being involved here.

Hello DDV and welcome to the PW forums. As far as I know, 1902 is the earliest date you can represent on any 32-bit unix-like system that uses "unix time" to represent dates. This is not a limitation with ProcessWire per-se but because the time data is stored in "unix time" which is an integer representing the number of seconds before (negative) or after (positive) the "unix epoch" which is 01-01-1970. This allows +/- 68 years around the epoch year, meaning the earliest year you can represent is 1902. More information about this issue on Wikipedia (esp. the section on "Representing the number"). If you do not need to perform any manipulation of dates, you could just keep them as strings.

Looks like Packt Publishing have another ebook offer on, valid until the 3rd January. All their e-books are US$5(£3) each but you have to buy a minimum of two for this to work.

Very nice.

@moreweb any chance you could put that code in a gist over on github, or on paste-bin or something? Removing the leading whitespace will also make it more readable. I can't make head nor tail of it on the forum

Hmm, 22 chars is what ircmaxell's PHP5.5 compatibility library uses for bcrypt salts.