dragan

Sounds good from a first glance. We've started to establish Susy as the main (only) CSS-framework recently for new projects in our frontend boilerplate, but looking at the "Better than X" comparison table, we might reconsider our choice...

At my job I was forced to use Wordpress for a recent project (wasn't my decision of course). We had to use ACF Pro, and let me tell you - in terms of rendering time / flexibility, and performance, ACF is a mess. In a debug report, I found that 2/3 of the performance loss was created by the ACF plugin. Some pages use over 130 queries and take up to 2 seconds to render. The whole WP architecture is just not made for custom-tailored sites, and I still don't agree when some people actually call it a CMS; to me, it's an article management system. (but maybe I digress - there's a big WP thread elsewhere that covers all of that) oh - also.... ACF created a whopping 40k records in the wp_postmeta table. For a relatively small website (local business). wtf?

I'd be very eager to know how this app developed since your last post. If you have a few spare minutes, I'd very much appreciate some more "behind the scenes" infos.

Another strong vote for some kind of "file-type filter" option. e.g. only show .jpg|.png|.gif|.mp4|.pdf files

i scanned it (our company subscribed the mag)... if anyone wants to read it, let me know. The timing is right too, since i'm preparing a tech-hour to present in-house

What others should you do? "Powered by Awesomeness" maybe?

change the search type to %=$q (according to the docs, this uses the more precise SQL LIKE) instead of ~=$q http://cheatsheet.processwire.com/ > Selectors

Another question: For quickly importing a list of events, is there a way to also support datetime fields? Does PW internally store these values in Unixtime? ahem, I just need to be using the exact same date / datetime format as specified in the field definition (e.g. in my case, 2014-12-31 19:00:00).

Would it be very difficult to create a new version supporting multi-language support? Or are there any other tools I've missed? (i.e. I know how to create pages / populate fields via API, and also how to edit alternative languages, but it would be nice to have an automated import CSV tool for multilang sites). Perhaps a slight variation: An import tool for already existing pages, that inserts / updates one or multiple alternative language versions? If we'd declare the page ID as mandatory in the CSV, I guess this wouldn't be rocket science?

This may not be the right place to post, but I'll try anyway... I'm currently preparing a little presentation to introduce PW to our company. Most stuff we do development-wise, is strictly frontend. But every now and then, we do backend stuff too, which mostly (always?) ends with choosing Wordpress. "Because it's so famous", "because it's the only CMS our other in-house developers also know", "because there are so many plug-and-play themes/plugins"... There are a few medium-sized projects coming up where we won't only cover the frontend, so I thought it was time to introduce folks here that - yes indeed - there are worthwhile alternatives out there. I've got maybe 80% of the material together that I'd like to present, but I was wondering if there is a PW-profile of the hotel website which is shown in Ryan's video @ http://processwire.com/api/selectors/inputfield-dependencies/ (or any other similar profile / demo site which uses field dependencies). If possible, I'd like to walk through a demo-install with people, and maybe even let them play around themselves. Too many folks here actually have no clue when it comes to backend dev work. I'd like to show them how much can be achieved, with "out of the box" PW tools, even for heavily customized stuff. And certainly, Field Dependencies is such a corner-stone.

The _notes folder is probably from Dreamweaver: https://forums.adobe.com/docs/DOC-1671

Well, there is an Opencart API available, but it costs $99. If you really need that functionality, it's probably worth buying it, but nobody else will buy it just to experiment around with it. Also, if you need it just for displaying product categories, it's probably overkill. Perhaps you'll find a better approach in the OC forums. http://www.opencart.com/index.php?route=extension/extension/info&extension_id=18650

Fair enough, but you could at least copy the HTML, CSS, JS, strip all sensitive data (replace content with lorem ipsum, replace logos, links etc.) and post a copy somewhere? The description you gave is just too minimal. It's probably a CSS issue, but without more infos, I'm afraid no one can help you.

If you would post a link, I'm sure we could find the culprit...

I would let the visitor choose. Or at least make sure you have a scenario, what to show when somebody deactivates the geolocation feature.

Take a look at http://foundation.zurb.com/docs/components/interchange.html

I don't even know why you're so worried about switching from CMS a to CMS b. It's not you're rebuilding his old site. You're making a new site for him (or did I miss something?). Was he specifically asking you to build the first site with EE? In the end, you built a website, with whatever tools you've chosen at the time. Simply build his 2nd site now with whatever CMS you decide to use. If he even mentions something like "why a different backend this time?", list your arguments then. Everyone should know by now that our business is very fast-paced. Tools come and go, get better or worse; c'est la vie. He'll even be thankful you were trying to avoid costs for him in the long run (EE support), and as a business guy he'll appreciate that. I wouldn't mention that you probably would have to update lots of stuff for his old EE site - he could think that you didn't do your duty in the last two years and start to worry now. I also wouldn't mention that you would have to get up-to-date with EE, since that could be misread as "he doesn't care about keeping up-to-date as a developer".

Whatever you'll decide to use, don't use SAP. I had to develop some responsive emails for a client recently, which uses SAP. It's a dark narrow path of misery, pain (and even more pain). A little word of advice: You should test your emails/templates with a tool like Litmus. They can do tests on all possible email client varieties / devices. https://litmus.com/ Writing an HTML email (from scratch) in 2014 feels very weird - you're extremely limited due to vendors stripping out all kinds of tags and stuff. HTML tables for content is still the sad truth, with a bit of CSS icing on the cake, and lots and lots of hacks. Some reading material: http://alistapart.com/article/can-email-be-responsive

I don't get it. It's way too slow. Who wants to wait 10-15 seconds until you can proceed with a form? I'm not saying captchas are better, but this surely isn't the final solution to stop spammers / brute-force attacks either. Also, when using a bogus email-address @ http://wpdemo.hashcash.io/ it didn't detect it as such.

I'm interested to know more about your webcam setup. Do you use a special software to send pics in certain intervals via FTP to the server? Was that bundled with the cam hardware, or some manual setup? Is the text over the image generated by that software too, or did you write a PHP script?

if the JSON field can contain the search string, maybe use %= %= Contains the exact word or phrase (using slower SQL LIKE) [v2.1] http://processwire.com/api/selectors/#operators

Another error that Firebug shows is: TypeError: dropdownHover is not a function /wire/modules/AdminTheme/AdminThemeDefault/scripts/main.js?v=5 o_O

Well, I'm sorry to say, but the same JS error occurs again, albeit under a slightly different circumstance: I've got a relatively big template (approx. 80 input fields) in a multilang site, divided in 5 field tab groups. Some of them (downloads sections - all file-input types) don't work now anymore, with the a.m. JS error. Some more infos: - When I create a new page with the "product" template (or copy an old one and edit it), I can't open some of those input fields. I set them to only collapse when not blank, but changing these settings to "always open" didn't remove the error / bug. These input fields stay closed no matter what (although the tab area color changes to light blue) - I tried updating the jQuery core module from 1.8.2 to 1.9.1 - no luck. - I guesses that a recently installed module could be the culprit - but it's not even active on those buggy input fields (Teppo's excellent "Version Control For Text Fields" module), so that's ruled out. Any ideas? Somebody stumbled over similar issues? (PW 2.4 stable, everything else working normally)

Simply include translation_plain too in your search selector, e.g. $matches = $pages->find("title|translation_plain|data|body|summary%=$q, limit=50");