Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 12/13/2015 in all areas

  1. Hi, I've hit this problem before. I started out as WordPress developer. WordPress is immensely popular to the point where plenty of clients think WordPress = CMS. If you mention another system they will think "they wont be able to edit it". WordPress is very much do-it-yourself and plenty of clients like that. However working in an agency it's a nightmare. You will find that they always break things, or use dodgy shortcodes and your often trying to provide support. When building a bespoke website in WordPress, I often used ACF to make sure it was locked down, no Visual Composer to play around with elements. But all it gave me was headaches. The API is allover the place and not to mention each plugin has it's own set of functions you have to worry about (WooCommerce). I've been using WordPress for years and I'm still always searching stuff like "How to get category image as thumbnail size", which turns out you have to call about 20 functions and pass it through the eye of sauron before it spits out just a url with the image size. With WordPress there is no guessing. ProcessWire I learnt the rules of the API and from there, I could guess how to do things and often it worked! This is a signature of a system that works for you, and not you having to work for the system. jQuery is a lot like this and the reason I love jQuery, I know I get the with .width() so the height should be .height(). Simple. So that's everything my side, how about the clients? Well, I always found convincing clients was very easy when the subject of security came up. I often tasked them to find a hacked ProcessWire site, then do the same for WordPress. Obviously we knew who the clear winner were there. After that is speed. All my ProcessWire sites run lightning fast. But I just think morally it's better to go with ProcessWire. WordPress is now taking up roughly about 20% of the web, this calls for a very unsafe web. That's 20% of websites with known vulnerabilities coming out almost every week. It's got so bad, Google now scour websites and report hacked sites on their search results. ------- Here is an example we had recently; A potential client came in thinking he had an audience of about 30,000 per month. He was using his cPanel's analytics and always went off those. He decided with that amount of viewers he should invest in marketing. We hooked up Google Analytics to see demographic, page views, user journey etc. to discover he was only getting 2,500 per month. After accessing his analytics we found that he had 27,500 hits per month to /wp-admin/admin-ajax.php
    5 points
  2. I understand how you feel. It's quite sad that so many people have closed their minds to platforms that either don't live up to their promises, or just fail on their backsides at almost-regulated intervals. Luckily, my experience hasn't been so bad - guess I just have an open-minded client-base. There have been several instances where WordPress was brought up, and an explanation of PW's benefits was required. However, all of these went smoothly, and not one client has forced WordPress into the equation. They're all happy with PW, and have outstanding things to say about it. I prefer to not argue with people, and so would say to a potential client insisting on WordPress that it shouldn't be used just because everybody else is using it, "but, if you insist, here are a few designers and developers that would be happy to help you." (And then proceed to list the 5999 designers and developers here in SA that use it religiously.) It's not easy, I know - but your preference of ProcessWire is exactly that: your preference. And so, it isn't easy to make your clients feel about it the way in which you do. I guess my initial experience was along the lines of my client relying on me and trusting me extensively - to the point where they just ran with it (instantly).
    5 points
  3. @Beluga I like the approach of discussing and agreeing project requirements with your client and then recommending a suitable platform and selling a solution instead of disqualifying WordPress immediately. Hitting directly on WP is probably the wrong approach, especially for clients who only know WP and have no technical experience.
    3 points
  4. Despite praising the flexibility and advantages of using ProcessWire as a CMS, I am currently loosing a lot of business, because clients insist on using WordPress, which we all know is a pain to go back to if you once enjoyed the clean API of PW. Many times I get the impression that people don't buy what they don't know. How do you go about this? Do you simply give in and implement it in WordPress? I think it would really help if the official ProcessWire site had an attractive landing page that explains the advantages of using ProcessWire for non-technical users. Probably without bashing WordPress, but making a strong point...
    2 points
  5. Hiting directly on WP (or other systems) always has it's bad feelings for the client - ranting on other systems is always no good way to sell your own product. Personally i'm in a position that most of my few clients are really non web affine and they have no clue about different tools or how to use them...but they know wordpress, too. But i show them the last half year security problems (without knockin down WP and stay ojective as far as i could) and we are ready to go one step further with PW and no other system...but i could imagine the problems with business clients that have dangerous ssuperficial knowledge that makes your life harder! Best regards mr-fan
    2 points
  6. You will enjoy reading the thread One at a time (PW Vs WP)
    2 points
  7. Sorry, but I really cannot follow what you are asking for. As I could understand from reading here, there was a change in PW, related to security, to not support single and double quotes in URLs per default anymore, as it was done in the past. That's a good thing, I think. And there is an option to (re)activate the old behaviour, for those, who need it. Conclusion: new behaviour + old behaviour ? what more do you need ? or what is the part that I do not understand here ? Also please refer to the according RFC 3986, where is described which characters are allowed to be present unescaped in an URL. Quotes and doublequotes are not in, or I may have overlooked it? Also the example you have posted is wrong coded and cannot have worked before too: You cannot wrap single quotes around an URL if the URL itself contains (unescaped) single quotes! Please, first fix your syntax and maybe, second, try to use more RFC conform URLs. (I know that browsers also work with malformed URLs, but since you now know that this is malformed, you shouldn't use it anymore).
    2 points
  8. So after some smalltalk to Luis and some xmas madness...it's all there as kind of little christmas present. A OS siteprofile released under MIT so it should be easy possible to use parts of that profile in own projects and keep credits to the original creator. Github Repo: https://github.com/mr-fan/Officesuite Thanks again to Luis for his permission to release it to the community. Best regards mr-fan
    2 points
  9. it might work, but you could also try page table - might be a little cleaner UI
    1 point
  10. I´m a happy customer of padloper thanks for all your work apeisa
    1 point
  11. Thanks! The documentation for Klarna seems to be good. If the connection is possible i will definitely use this for projects in the future!
    1 point
  12. Tom, sorry that field was behind a showIf dependency for the inline edit fields checkboxes, like Adrian mentioned. It's actually only supposed to apply to those checked fields, which is why it didn't appear. I was replying from mobile before and was forgetting this. That particular setting really is only meant to apply to those checked fields, so your $page->edit() wasn't working as a result of a bug, which I have pushed a fix to 3.0.2 just now. You should now be able to use $page->edit() with any field regardless of page. There's no concern about performance hit here. The reason it's recommended off is only as a default setting. For instance, let's say you've got a "summary" field in your page and you are rendering search engine results that include that summary. You probably don't want the summary to be editable in all those search engine results, whereas you do want it to be editable when you are actually on the page. So the setting is just there to reduce confusion since chances are, most of the time you'll only want to have a field editable when you are on the page it is owned by. None of this is meant to apply to options B through D since you are already in control of it all from the API side. I don't think there's much we can do about it, if that image is not part of your field there. However, if it's a concern, you may be able to add something like this to your css file to adjust the cursor: #your-container img.your-image { cursor: pointer; }
    1 point
  13. That selector doesn't give quite the right results. There's no AND component to it, so it would match any page that has cat OR dog OR 1234 OR 4321. I think the selector in my third post... $pages->find("foo=(text_field*=cat), foo=(page_field=1234), bar=(text_field*=dog), bar=(page_field=4321)"); ...might be as succinct as it gets. And nothing wrong with it, I just thought there might be something simpler I was overlooking. It's also totally possible to use the $items->add approach you suggested initially, just a bit more involved to deal with the pagination. Found a great post from Soma that spells it out.
    1 point
  14. Thanks. I considered the $items->add approach but it makes sorting and pagination more difficult than with a single find operation.
    1 point
  15. shorter. Your solution is correct. // will find pages with text_field*=cat OR dog OR page_field=1234 OR 4321 $items = $pages->find("(text_field*=cat|dog), (page_field=1234|4321)"); // will find pages with text_field*=cat OR page_field=1234 dog AND text_field*=dog OR page_field=4321 $items = $pages->find("(text_field*=cat), (page_field=1234)"), $items->add("(text_field*=dog), (page_field=4321)"); // similar to $pages->find("foo=(text_field*=cat), foo=(page_field=1234), bar=(text_field*=dog), bar=(page_field=4321)"); Well explained here: https://processwire.com/api/selectors/ Edit: Correction of correction ...
    1 point
  16. <?php foreach ($page->children as $child): echo "<div class='my-class-$child->id'> $child->body"; endforeach; ?> echo doesn't need (), this should also give each instance a unique class if you are looking for that
    1 point
  17. I don't think that option is relevant for modes B, C & D, because they require you to manually specify the page that the field is on or they just don't work. eg, <edit field="image" page="<?php echo $other_page->id; ?>"> I am not sure about the performance issue - will wait to hear what Ryan says.
    1 point
  18. Parse Error: syntax error, unexpected '}' (line 109 of /var/www/html/site/templates/systemcheck.php) This error message was shown because you are logged in as a Superuser. Error has been logged. PHP Version 5.5.9-1ubuntu4.14 sorry, no time to investigate this on my own for the time...
    1 point
  19. Updated the module with a newer chosen release (security related) and fixed the hardcoded admin location in the warning about wrongly configured fields. @kixe There's already a warning if you're using a multi-page field with the wrong inputfield (because it changed from the first versions of the module). I've added a note about installing it beforehand. But there's also no * in the inputfield select for the field, which should indicate that the inputfield is not meant to be used for a multi page field.
    1 point
  20. Daniel, Padloper uses ProcessWire PaymentModules, which I have open sourced. It is very simple "wrapper" for different kind of payments, which makes it possible to use implemented payment modules in any PW project. More information here: https://processwire.com/talk/topic/8959-payment-base-class-paymentstripe-paymentpaypal/ How much work depends a lot about how good API klarna supports and how deep integration is needed. I think Stripe took 1-2 hours and PayPal 3-4 hours to implement (Paypal is so messy).
    1 point
  21. There's that idea for a social site (hard to come up with a correct term without giving too much away) I've been carrying around for ages. One thing that has always held me off was knowing that I'd need a tightly integrated forum. I've plugged a few forums onto existing sites and always regretted taking the job. So now that I've discovered PW, I decided to do it the other way round - build the forum on PW, then add everything else on top. I'm planning it to be highly interactive, so it's not something done in a week, yet it's simply incredible what PW allows you to do in a matter of a few days. Here's what I have so far (don't look to closely on the design, if I really go live with my idea, I'll have someone else with appropriate skills do the visual design). And don't mind the naming, I've only used PWForum as a working title in lack of inspiration. Start page (dynamic menu, sidebar configured using selectable widgets) It's reasonably responsive, not something I have experience with, so it's a learning curve I already asked you to overlook the visual issues, didn't I? (but hey, things are there and it validates) There's already a bunch of features like friends and badges built through page fields, but lots of the frontend logic still has to follow. A working private chat (jquery ajax polling) is already there. This is probably going to make it into the modules directory, even if it's just as proof-of-concept. Doing that I learned about the different ways of "magically" including scripts and styles. For production use, I'll have to implement some kind of memory caching in front of the webserver for all the ajax calls, which is also a new playground. Both chat and forum messages use bbcode-like markup. I'm building my own textformatter and editor bundle for that to get it lean and flexible enough. The textormatter already allows you to configure smiley patterns in the backend. There are going to be a lot of profile settings. I'm sure I'm going to have to add more than one tab. This is just a project I'm doing for fun, so I don't have a timeline, it's more about toying with things and finding clean solutions. If things work out, I hope to have everything worked out some time around Easter and bundle it as a site profile for others to disassemble
    1 point
  22. Update: Ryan has already pushed a fix for the Textformatter issue to dev. I've put together a small module that encodes relevant parts of a URL using parse_url and rawurlencode. If anybody wants to have a look, I'd be happy to get some feedback. It can be found on github.
    1 point
  23. I just looked at this, as umlauts and other funny characters in URL paths are going to be on the table in one of my next work-related PW tasks next year, and I'm pretty sure that FieldtypeURL currently ignores all assigned textformatters. I've already filed a bug. Also, HTML Entity Encoder is probably the wrong tool for that task. The way to go would IMHO be to rawurlencode all path components in the URL, encoding all non-reserved non-ascii characters to their percent encoding in line with RFC 3986.
    1 point
  24. @justb3a had some issues; spent about 2 hrs trying to get this to work; some of the documentation does need improvement, for example it should say to echo the module, or the module should echo. for one, there should be a way to disable the whole spam thing, besides putting in the ip address. makes it hard to test; sometimes i'm trying to test this and it's redirecting to the homepage, sometimes the form just shows again with the fields filled in, i have no idea what is wrong; and then i'm trying to do a simple form and change the markup but it either seems to break, or it triggers the spam thing. the message area should be a textarea; seems that changing from input to textarea also was messing things up; i appreciate all of the hard work that went into this, just seems that it could use some additional improvements and some better documentation.. for now i'll have to stick with formbuilder for this site, but have somee friends who need to use this; so we'll have to sort out this textarea thing, and also how to completely disable the spam thing. plus i can fill out a form in way less than 1 minute, so how can that be a real spam prevention technique; doesn't make so much sense; maybe consider some simpler spam prevention like honeypot... thanks for listening.
    1 point
  25. THen there's this $a->setTotal() $a->setLimit() $a->setStart() on page arrays we can use to configure built in MarkupPagerNav to work with merged page array in memory. Kind same as my above example but much simpler. /** * here is a example with using the built in pager * we can use $a->setTotal($n) to configure page array to work with pager */ // create new page array for storing pages $pa = new PageArray(); $res1 = $pages->find("template=mytemplate"); $res2 = $pages->find("template=house"); // import the found pages $pa->import($res1); $pa->import($res2); // configuration for pagination needed $limit = 10; $total = $pa->count(); $start = ($input->pageNum-1)*$limit; // example output with limited list we filter from the complete page array foreach($pa->filter("sort=-created, limit=$limit, start=$start") as $p){ echo "<p>$p->title</p>"; } // page array let's you set the parameters for pagination manually $pa->setLimit($limit); $pa->setTotal($total); $pa->setStart($start); // now the renderPager() on the page array works as usual echo $pa->renderPager(); Added this to the previous gist snippet here https://gist.github.com/somatonic/5420536#file-paginator_manual-php
    1 point
×
×
  • Create New...