Leaderboard
Popular Content
Showing content with the highest reputation on 01/21/2013 in all areas
-
According to autocomplete documentation you'd have to do something like this (works). $('#search_query').autocomplete({ source: function(request, response){ $.ajax({ url: '/search/', type: 'get', dataType: 'json', data: { 'q': request.term }, success: function(result){ response(result); } }); }, minLength: 2 });2 points
-
Glad to hear that thanks for your kind comments, everyone. Well, I really fell in love once more with the simplicity and the workflow of PW. Just added an RSS feed. I definitely like how flawless things work together. As a former Drupal user I can say that it's really great to have such control about everything - that's exactly how I want the things to work - things should work without any unexpected behaviour and without too much extra effort.2 points
-
2 points
-
Hi guys, I'm kind of late to the conversation, but all of this sounds very exciting to me. As far as local sites go, I think the best way to go is to set up language-specific subdomains, as this will ensure a consistent identity across the board. One of the problems with setting up individual domains, in my view, is that it's virtually impossible to get hold of the same domains across languages, like 'processwire.de', 'processwire.fi', 'processwire.ch', etc. This would lead to a mess of independent domains that might confuse people. To be honest, I think we should put the emphasis on the languages themselves, not so much in the individual countries. For example, Spanish is the official language of 20 different countries, and we don't necessarily want to have a separate site for each of these countries. Simply having an 'es.processwire.com' subdomain will cater for them all. Just my opinion, though. As for setting up local forums, the danger here is fragmentation, as others have mentioned, and we certainly don't want that. Having said that, the idea of giving non-English speaking people the ability to express their ProcessWire-related ideas, suggestions, concerns, problems,… in their own language in an 'official' ProcessWire forum could be very effective, and shouldn't be underestimated. To lessen the risk of fragmentation, we could perhaps write a script that automatically pulls the most interesting discussions happening in the local sites to the main ProcessWire forum. We could do this by for example looking at threads with the label 'Hot'. We could then add a 'From around the world' section and within this language-specific subsections to the main PW forum, where all these interesting conversations would be included. It would then be just a matter of setting up automatic Google translations (not ideal but gets the job done) for this. I don't know, just a couple of ideas to throw on the table! By the way, I'd be more than happy to contribute to the Spanish local site/subdomain/forum/etc. I can provide translations, keep an eye on a future forum, manage contributors, etc. Claudio2 points
-
Perhaps php mail isn't installed or doesn't work. Can you try to mail with the following code? $to = "your@email.address"; $header = "From: {$to}"; $subject = "Test"; $body = "Test body"; if (mail($to, $subject, $body, $header)) { echo("Success"); } else { echo("Failed"); }2 points
-
Couple of recent sites I've created: http://www.theartofdining.co.uk/ - Pop up restaurant http://samhofman.co.uk/ - still life photographer1 point
-
I seem to be having some trouble here. I'm developing a site that must live at a staging web host during development, then move to its permanent home at launch time. During development, the site address is: http://74.52.58.162/~imageeff/ I've successfully installed PW, however, i'm not able to get to the PW control panel using: http://74.52.58.162/~imageeff/index.php/wire or this: http://74.52.58.162/~imageeff/wire ============================ ...later. Ok, although I had a suspicion that htaccess was the source of my problem, I hadn't dug deeply into it enough. 1. I had failed to notice the helpful comments in the PW htaccess file which noted a need to add a RewriteBase rule for sites including the tilde character. 2. I had foolishly not trusted the documentation which clearly noted that "http://74.52.58.162/~imageeff/processwire" would be my control panel url. NOT "/wire" as I had oddly assumed by looking at the directory structure. D'oh. Apologies for the false alarm.1 point
-
Hi Ryan, is it possible to hack something in PW, so it will work on two different servers? (staging AND live server) something like (pseudocode): $LIVE = (set_by_url) ? true : false; if($LIVE){ $db = 'hujul'; $db_user = 'user'; $db_pw = 'pw'; $db_server = 'this-one.com'; }else{ $db = 'staging-db'; $db_user = 'root'; $db_pw = 'root'; $db_server = 'staging.that-one.com'; }1 point
-
1 point
-
Hi all, I've just come across this Twitter conversation: I'm sure this has been discussed before, but hey, don't you guys think it'd be a good idea to have a list featuring websites built with ProcessWire? I think this could be a great selling point, as people unfamiliar with the system could see, at a glance, the kind of results they can expect to get with PW. The Symphony project, for example, has done this beautifully. Well, let's see what you think!1 point
-
We do need to setup something like this, and hopefully will soon.1 point
-
I agree Nico. However, perhaps this could be managed in a different way? It seems that a lot of the ProcessWire permissions are tied into the actual templates - hiding the true level of flexibility. Well, maybe the site templates should also be listed under 'Access -> Roles -> [Role]' with the ability to change permissions for those templates within the roles page (as well as the current way they are handled per template). Below is a screenshot of how Drupal handles permissions across its nodes (content types / templates) in one single screen for each role (columns in the table): I think that this would be a usability gain for site administrators.1 point
-
Radek, all the text you mentioned is now translatable. Also, the issue that caused it to miss text in Inputfield.php and Fieldtype.php should now be fixed as well (dev branch). Please confirm when you get a chance.1 point
-
1 point
-
Hey arjen, thx for the hint. I asked the provider and they told me,that I have to set a valid mail-address in the settings of my account The module is working fine now!1 point
-
Hi FuturShoc, try to flush your browser cache and it should work normally.1 point
-
I had the same error once: try removing the /wire/ folder and uploading it again: http://processwire.com/talk/topic/1492-processwire-23-features/?p=231481 point
-
1 point
-
this file is for setting multiple websites with a single wire folder. you point all the domains to the same ip, and create a "site-something" folder for each of them. then you just have to list the domains in that file and pair them with the correspondent folder.1 point
-
Aarrgghh! So frustrated that I need to build some functionality into another ecommerce system that would take 20 seconds in ProcessWire. I need to add a related products feature to a blog section - in the other software this means I likely won't be able to do it or will spend a week working it out. In ProcessWire it would be soooo easy. I'm going to make an effort this year to use ProcessWire for every type if site that comes my way - that way if I need to do some customisation I know it will be easy! I've now changed the title of this thread so I can vent my frustrations about whatever system I have to wrestle with to do what I need it to1 point
-
Adam, you should take a look at /wire/core/Pages.php, after that it's pretty obvious where to attach page-related hooks. And for the record, ___restore() and ___restored() are available too if you happen to need them1 point
-
1 point
-
@Adam, did you see the field-change-notifier module? It does pre + post checking on changed fields.1 point
-
Have you already checked this solution out: http://processwire.com/talk/topic/1067-accessing-previous-version-of-page-beforeafter-page-save/#entry9321?1 point
-
1 point
-
1 point
-
Someone added 5,000 more posts in 2 months since WillyC posted this So... if traffic just stays the same we're looking at 30,000 posts a year? That's neat, but I think by the end of 2013 we might be a lot closer to the 100,000 mark than the 50,000 mark.1 point
-
I must have been living under a rock recently, I've only just noticed the 'Form Builder' has been released. I will be getting this for sure. One quick question: will I have the ability to have multiple forms on a page? For example, a general contact form and a newsletter email capture form?1 point
-
Just catching up with all things ProcessWire lately and am excited by what I see being put into 2.3. The new traversal functions and LinkMonitor module and comments monitor look good. I also really like the concept of having $config->prependTemplateFile and $config->appendTemplateFile to reduce the need to call includes in template files.1 point
-
Hi guys, It's been a while since I was involved in the forums here. I've been away working with legacy Drupal, Joomla and WordPress systems due to client requirements. It's been a time hog and not all that enjoyable a process. I finally had a chance to use PW for a project again yesterday and what a breath of fresh air it has been! I had forgotten how easy, consistent and reliable querying pages was, no more temperamental WP_Query object in WordPress or complex render arrays in Drupal. It's great to see how the community has grown since I last checked in, as well as the improvements to ProcessWire overall. Ryan is steering forward in a very strong direction. I'm going to have to get the FormBuilder plugin I think, it looks to be fantastic. Anyway, I hope to be hanging around here more soon as a bit of work/life freedom approaches. Keep up the good work.1 point
-
I personally prefer the aesthetics and UX of Facebook, though I do realize that it's clearly not for everyone. Like Joss already pointed out, they've never been into eye-candy; each and every one of those little details, buttons and links serves a clear and mostly unique function. Another thing I admire is the fact that they've always been happy to make changes they believe will enhance that experience, no matter how risky or how many people they might annoy in the process. Not everything they do succeeds, but at least they have a vision and are not afraid to take the platform further -- something MySpace originally failed to do and one of the reasons it lost it's place as the top dog of social websites. New MySpace does seem like something that could offer real competition though, I guess we'll see how well that works out Regarding Facebook and PHP, they've definitely done a lot to development and reputation of the project by proving that it can be used for pretty big things and also by participating directly via enhancements and bug fixes. Then again, the vast amount of resources they possess have made FB pretty unique and not directly comparable with the rest of us; for an example they're the only company I've heard of that has built and is using their own PHP execution engine1 point
-
Hi Seuche, Welcome to the ProcessWire forums, and congratulations on a job well done! I used to practise Karate Shotokan when I was kid, and have been involved with other martial systems over the years, so your club's website is close to my heart .1 point
-
I always put these kind of things into the home template. If there are a lot of fields for a header or footer that I want a client to manage I stick them in a /FieldsetTabOpen/close set. So you end up with tabs in the home page edit screen with something like this: Content | Header | Footer | Children | Settings | View1 point
-
I think the main thing is that when you know there's an easier tool to work with it makes everything else a chore. I was a bit surprised about the SEO person's response from your post above, but I guess I shouldn't be and thinking about it I had a very similar conversation with someone earlier this year myself who was worrying about re-training to use PW. It can be a hurdle to adopting a new system when clients think there will be a massive learning curve and it's generally just because that's what they've cmoe to expect. I think the main point to get across is just how straightforward things can be when everything is laid out logically. We have the luxury (and it is a luxury compared to most other systems) of being able to have custom fields for everything, and being able to name your fields and order them how you like means it becomes very intuitive to the point where there isn't actually much training required. I'm the same with MODx now - used it for quite some years and going back to it is hard work sometimes. Most of the clients I have that still use it don't need new features though so it's just a case of occasional updates, but I do try and convert them when I can. With this current site I really shouldn't complain and should simply have done more research, but it's the case with most projects when you're taking something on that's already established that you will eventually run into something unforeseen - if you could afford to spend days checking out every aspect of a job before taking it on it would be okay, but you generally have to hit the ground running and get on with it. It helps to vent your frustrations sometimes It's another one to chalk up to experience, but I still don't want to work with anything other than ProcessWire again1 point
-
This inputfield uses the ProcessPageSearch AJAX API, which is accessible to logged-in users only that have administrative access. Meaning, it can't be used on the front-end of a site, unless for an administrative user. However, this Inputfield is mainly just a front-end to the jQuery UI autocomplete, with some tweaks to make it consistent with PW's admin style and offer some configurable options. So one could very easily implement the same sort of functionality on the front-end of a site by creating a page with it's own template to handle the ajax calls, translate them to a $pages->find() operation, and return the matches. It doesn't need to do any more than this: /site/templates/search.php <?php $resultsArray = array(); if($input->get->q) { $q = $sanitizer->selectorValue($input->get->q); $results = $pages->find("title*=$q, limit=50"); foreach($results as $p) $resultsArray[$p->id] = $p->title; } echo json_encode($resultsArray); From there, the rest is just jQuery UI autocomplete: http://jqueryui.com/demos/autocomplete/#multiple-remote1 point
-
What you suggest should work just fine. Using your example, here's how I'd code it in your /site/config.php: Solution 1: <?php // If your dev/staging isn't 'localhost' then replace it with // whatever $_SERVER['HTTP_HOST'] is on your dev server: if($_SERVER['HTTP_HOST'] == 'localhost') { // staging or dev server $config->dbHost = 'localhost'; $config->dbName = 'pw2_blank'; $config->dbUser = 'root'; $config->dbPass = 'root'; $config->dbPort = '3306'; } else { // live server $config->dbHost = 'something'; $config->dbName = 'db_name'; $config->dbUser = 'db_user'; $config->dbPass = 'db_pass'; $config->dbPort = '3306'; } Solution 2: Another solution, and the one I use is to maintain a separate config file called /site/config-dev.php. ProcessWire looks for this file, and if it sees it, it'll use that rather than /site/config.php. If you just keep this file on your staging/dev server, and not on your live server, then that solves it for you. I also added that file to my .gitignore file so that it doesn't ever get deployed, while /site/config.php does. To get started with this method, just copy your /site/config.php to /site/config-dev.php (on your staging/dev server) and change the database settings in the config-dev.php version.1 point