Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 08/24/2014 in all areas

  1. I need to do some more slider images and get some more up to date content, but the bulk of the work is done. I did a blog, and google calendar. Responsive since I used Bootstrap 3. Feedback is appreciated! Thanks! http://www.trinitytxk.com/
    4 points
  2. Oh I'm just going to install that $6 forum plugin later today that allows for Google search since I can't find time to look into Sphinx search right now
    4 points
  3. Why are you refering to the paths inside the template folder? This would return an error even if you wouldn't call it via AJAX. Try: url: '<?php echo pages->get('/logincode/')->url ?>'
    3 points
  4. It sounds like maybe filtering showcase entries by certain categories might help - I'm working with a design agency right now for a reasonably complicated site for a corporate client in the USA that would make an interesting case study when it's done. What I've found fascinating in this particular case is that the chap I'm working with saw Processwire, watched ryan's video I think and was sold on the concept without going much further than that. He also had little problem convincing the client to use it. I think that a lot of the work can be down to dev/design agencies and how we're marketing it ourselves in meetings to clients. It's making me think it's less likely that large organisations would start out by looking at a solution themselves until their dev has suggested something and then they might look into it in more detail. Either way though you do need something on the site to back it up. Being able to filter case studies based on criteria that might be appealing to larger customers would be a start, as would the idea of a developer directory. I know there are more devs than those who post on the forums so a directory along with which country they're in would be a relatively easy and reassuring indicator to a company performing some sort of due diligence to make sure that if one dev vanishes they've got alternatives.
    3 points
  5. Just for the record, since it's closely related to this thread, there's a pull request in GitHub about SQLite support (opened back in May). There are quite a few changes and most likely it isn't in sync with current dev branch (it's based on the master branch), but still works as a nice proof of concept for SQLite support. If any SQLite user here is able to get that one running and could run a few tests to see how well it behaves (the questions Ryan asked in his comment to the PR, like how well selectors work etc.) it would be interesting to hear.
    2 points
  6. I think it would be rather $products = $pages->find("template=product, (product_name=computer), (product_category=electronics)");
    2 points
  7. @uprightbass360 You ask for a tool that could deal with the problematic formatting. That's still difficult, seeing the formatting. Developing a script that can deal with all the differences takes, I think, more time then to go over the lines in Excel. In Excel you have a clear view over a big number of columns and rows and it's easy to select multiple columns/rows at once and move them around. My experience with this is that you will be finished before a scripter can develop, test and finish a clear solution that will fit all the discrepancies in the formatting. And, in Excel, if you recognize a clear repeating discrepancy, it's easy to correct it with a simple formula. Good luck anyhow with this. Hope also that there is somebody would could give an explanation how to import the cleaned data when using pagefields. I'm curious.
    2 points
  8. This is a little module that allows you to put your site into maintenance mode should you ever wish to. It basically checks to see if you're a superuser and if you're not then every page on the site which you try and load will send you to the login page with an appropriate maintenance message. The styles are hardcoded into the module at present, so changing the default style of the front-end EDIT button could well have a knock-on effect. Ideas for the future: I was also thinking about expanding this in future to allow chooseable roles in the configuration that can access the site whilst it's in maintenance mode, as well as adding the messages to the config so they can be translated. It might also be nice to specify another page to send the user to so that if you want to keep your admin login page hidden you can do. Thanks to adamkiss whose ListAfterSave module this was written over the top of Thanks to ryan for solving the last piece of the puzzle and helping me display the message in the top-left of every page. EDIT: And my particular usage scenario is that I'm building a site on a live server. It's a brand new site so nobody would really know the URL so I thought I'd build it in the root of the site rather than a subfolder and this module lets me do that without letting folks see it until it's finished. Other usage scenarios could include major template file updates or... whatever else you think it might be good for You can fined the module in the directory here: http://modules.processwire.com/modules/maintenance-mode/ v1.0.6 adds ability to bypass maintenance mode for certain user roles.
    1 point
  9. Hi! Just currently using this on our proof of concept and on a hackaton. It's like ServicePage module but the difference is it return data without the need of extra programming (Image field for example). Also it only coded on the template. It primary used template URL segment to identify what page should be returned. All output is generated in JSON format. You can view it here.
    1 point
  10. @Marinus, Thanks for testing Blog. Sorry for your pain in respect of manually removing leftovers. I personally don't like to remove leftovers manually! Before I get into details why that is an intentional feature, from your post I can observe that despite clear instructions in the first post in this thread as well as notes both in the GitHub project home and the module directory, and despite the fact that these are either typed in coloured or bold font, you did not (at least not entirely) read the instructions and/or notes . Just in case others miss them, this is what I am referring to: From the first post in this thread: From the modules directory and GitHub 'notes' sections. If you'd read the instructions and the notes, not uninstalling 'much' would not have come as a surprise .. Yes, I know my reason for not removing everything was not explicitly explained in the notes. Maybe I should add this to the first post but back to your question.... A module like Blog is a complex application. No matter how smart it is there is no way it can second-guess the various ways in which it will be used by the client. For instance, the module installs various fields. What if the user decided to reuse the Blog fields in their other templates? What if they decided to reuse some of the templates or add other code in the template files? What if they'd built their Blog content over time and down the road decided they no longer needed the full Blog experience but wanted to keep some or all of the Blog pages? If uninstalling Blog uninstalled everything.....well, you get the picture. This is something I thought long and hard about and also consulted on before making the call that "rather a painful manual uninstall than potentially destroying a user's data on uninstall!". . There's good news though..(OK, maybe not for you but others since you've already uninstalled Blog... )....... I already have a script that will remove all traces of Blog - fields, templates, template files, pages. The script was written before I released Blog. I was reluctant to post it but maybe now I should (as a Gist). I would like to package it better though rather than something that will run immediately the file is loaded. I am thinking of packaging this with prompts (are you sure you want to delete?!!), maybe even make it configurable to allow selection of what you want to remove from your current Blog install. Now that I mention this, I might follow up on an idea a friend suggested a while back. Maybe something for Blog 2.0 (if we ever get there ) - make the whole Blog install configurable - i.e. on install, the user decides what aspects of Blog they want to install. They don't want comments? Fine. They want to call Blog Posts 'News'? Fine, we can do that...etc, etc... Anyway, I hope I have answered your question somewhere in there UPDATE: Blog version 2 now removes its path of trash (rather than leave them behind ). It also allows you NOT to install commenting feature plus other stuff.
    1 point
  11. marcus thankyou! i think you missed out a $ sign thought, but i got it to work using: url: '<?php echo $pages->get('/logincode/')->url ?>' finally! Thank you so much. I should really have posted in here 8 hours ago although i wanted to figure it out myself, and learnt a hell of a lot by trying Thanks mate!
    1 point
  12. You could create this functionality yourself without too much work. I am not a form builder expert, but I have integrated PayPal into a manually created front-end form in PW. If you want to use FormBuilder I think you want to hook into: FormBuilderProcessor::formSubmitSuccess Do you already have form builder and access to the VIP support board for it? There are a lot of posts over there about hooking into it and adding functionality. Here is some info I posted about paypal integration with PW: https://processwire.com/talk/topic/5281-paypal-payment-method-for-processwire-shop/?p=67670 Using the IPN feature of PayPal to return payment success and then publish the page should be pretty straight-forward. Let us know if you have any more specific questions once you get started.
    1 point
  13. <link rel="stylesheet" href="<?php echo $config->urls->assets; ?>scripts/foundation/css/foundation.css"> Although the convention is to put them under templates/scripts etc, in which case you'd want: <link rel="stylesheet" href="<?php echo $config->urls->templates; ?>scripts/foundation/css/foundation.css"> This way you will always have the full url to each resource. You could also just do: <link rel="stylesheet" href="/site/templates/scripts/foundation/css/foundation.css"> These root relative paths will always work no matter what page you are on.
    1 point
  14. Googled some bit on the pagefield and I think you're right about this. I was thinking that the reference would be a page id, but it seems to be the title. So, that makes it indeed easier then I thought. I'm going to test it on one of my PW sites .
    1 point
  15. Suddenly had a bright idea. The missing pages were set to "hidden". I needed to use: $results = $pages->find("url_old!='',include=hidden"); I'm leaving this page as a monument to my own stupidity.
    1 point
  16. Thanks again reems I really appreciate you stickin with me on this one. I think I may have a little reprise as I am first going to send the data out to a fellow student of mine who is pretty talented with scripting and sql and see if he can find any patterns in it. If he can then I'm just going to buy him pizzas until he's done, if not then I get to set a couple days out with excel and see if I can get it all dealt with. In reference to the page field stuff I have a feeling it will actually be pretty straight forward, page fields just hold a string with the page path. So if this is the case then all I will need to do is format the text as if it were the page path itself. Then when you upload just make sure that the string is correct and it hopefully should map. I wonder if anyone reading this knows, I know I will very soon.
    1 point
  17. Hi! Just create some WebServiceTemplate which enhance the functionality of the snippet. You can view it here
    1 point
  18. Totally loving that this module exists, I am about to push a ton of new data to a site that I am live developing and I really dont want it to get picked up by any nosey search engines. I have to say though the first thing I did to make it usable was delete the line of code that said "This site is in maintenance mode" as it was sitting right over the top of my navigation. I would say if you are going to have fixed positioning I personally would like it at the bottom, or even the ability to change the code via a field. Maybe even a custom code box or something along those lines. All in all though this module is a life saver and thank you for releasing it
    1 point
  19. Without checking, I would guess it's locked down on purpose. If you could easily access other user's sessions you are reducing security in some way.What you really want is something like these forums I'm guessing and even that is a bit of a cheat. Because no web server can possibly know if you're still there or not until you interact with it (like click a link or something) the forums store a last active time for each user and the "users online" list shows everyone with a last active time within the last 15 minutes. It sounds like Adrian's solution should work though if that ts field in the database is updated with every action. I would change 60 to 30 or 15 though personally to get users who actually navigated to a different page more recently.
    1 point
  20. You've not really explained why though. Comparing to another CMS isn't an explanation of the benefits. In fact, the topic linked to above states positives and negatives of SQLite and I'm personally not a fan of some of the negatives. It would be nice to have support for other databases but is there really the demand for it yet? I'm just asking an innocent question
    1 point
  21. I think this should help with what you are trying to achieve: function isUserOnline($userid, $mins=1){ $table = SessionHandlerDB::dbTableName; $sql = "SELECT COUNT(*) FROM $table " . "WHERE ts > '" . date('Y-m-d H:i:s', (time() - ($mins * 60))) . "' " . "AND user_id=" . $userid . " ORDER BY ts DESC LIMIT 1000"; $result = wire('db')->query($sql); $row = $result->fetch_array(); return $row[0]==1 ? true : false; } $whois = $pages->get("template=user,name={$page->name}"); if(isUserOnline($whois->id)) { echo 'true'; } else{ echo 'false'; } With this function you can pass the id of your $whois user to the function and have it return true or false as to whether they are logged in or not. You can pass a second argument to increase the time from 1 minute if you'd prefer. eg: if(isUserOnline($whois->id, 5)) { // 5minutes Hope that helps.
    1 point
  22. Ok, no need to use SQL here. Also not sure why you're foreach($languages as $language)? You can uncache the user and load it again via API, so it will load it fresh with language stored on user page. try{ $u = $session->login($username, $pass); if($u && $u->id){ $pages->uncache($user); // make sure it doesn't get user from cache $langID = $users->get($u->id)->language->id; // now load the user page $profileUrl = $pages->get(1003)->localUrl($langID); $session->redirect($profileUrl); } else { $loginError = "Login failed"; } } catch(Exception $e){ $loginError = $e->getMessage(); } I posted it in various login threads already, because all example login code posted in the forums has some flaws in that it doesn't catch errors when login failed multiple times (login throttle). To catch that you need to use a try catch method like in my example.
    1 point
  23. Bootstrap use, presumably? In that case output formatting is off and field value is returned in array format. You'll need to call wire('pages')->get($id)->file->first()->url etc.
    1 point
  24. Dear All, If one defines "Enterprise" as an environment of mission-critical websites that make money for a corporation, then I am already using ProcessWire in that fashion. My day job is as a Web Director for a New York magazine publisher that owns around fifty+ magazines. We have over 25 Linux and Windows servers, which I manage. I also write custom web database applications for the company, and recently wrote a "Web Help Ticket System" using ProcessWire. The ticket system receives its initial input via email, which gets piped to a PHP script, parsed, and then input into the ProcessWire help database. The script then emails the responses to various individuals that are in the database. I've created a front-end staff interface, with usernames and passwords, that displays the tickets and allows editing, searching etc. It's been running for a number of months, with tickets sent in from Editors, etc. So far, it's proven to be very robust. This is just one example of what I would call an Enterprise level web application, built using ProcessWire as the CMF. Of course, someone else may define it differently. I want to note that I had initially looked at Drupal for this purpose. I'm not yet a "Drupal developer" -- I just haven't spent enough time with it. But after spending *some* time with Drupal, and after seeing that many magazine sites that use Drupal seem over-heavy and bloated, I have to say that ProcessWire is lean and mean and fast and a complete joy to work with. It does have a learning curve, but I think it's less than Drupal's learning curve. (That would be a good survey.) I say that because once you wrap your head around PW's method of one data table per field and its "virtual data tables" (aka templates or field sets), then it becomes a piece of cake to use the API and PHP as the template language. The sky's the limit in terms of ProcessWire's power and flexibility. PW might seem arcane at first, but I don't really think it is, except for the table structure, and that ends up making sense after one digests it. I also built a complex, formula-based business app with PW, at http://thepivotstartup.com (in the members section). It allows entrepreneurs to plug in numbers about their business ideas and vet them, to see if they might work in the real world. Finally, I use ProcessWire as my own CMS, at http://significatojournal.com. My wife, who is a writer, but non-technical, does most of the article posting, using PW's admin back end. She finds it very simple to use. I don't need ProCache yet, but when I do, it seems to me to be a brilliant caching mechanism, since it dynamically writes each generated page to flat HTML files, and then uses clever .htaccess rules to serve them up. Because of all of the above, I would recommend ProcessWire for mega websites, and in fact, if it was "my do", I would build and/or convert many of the magazine sites that I manage in my day job to ProcessWire. I'm completely confident that PW would do as good a job as WordPress and Drupal, which the company currently uses. I believe that the reason that PW hasn't been adopted in the enterprise isn't support, but rather the lack of market share, mind-share, and enough usage for Big-Iron websites to prove to companies that they'll be safe using PW. I don't think Enterprise support is really the issue. We had one CMS, called "Nstein" and another called "Ekron" that both had expensive support packages. We left both behind with great sighs of relief. We use Drupal, WordPress and DotNetNuke, without any support contracts. All that matters is the confidence that: a) we can find developers who use it, and b) there are enough examples of high-powered, high-volume, Big-Iron sites that use it successfully. I think "B" is the real kicker. I read a Fast Company article about Drupal serving up hundreds of thousands of pages, and then recommended it to our VP. But, I wish PW had been around back then. That's the PW challenge, I think. Convince some VERY high-level, well know companies to make huge, heavily trafficked websites with PW, and then other folks will say, "Hey! Look at that! Let's use ProcessWire!" And then it shall be done. Peter
    1 point
  25. I think you should take a look at PayPal's IPN (https://developer.paypal.com/webapps/developer/docs/classic/products/instant-payment-notification/) Setting this up will allow you to set a field in PW to confirm that the user has definitely paid, then you could safely make use of their order-id by sending them an email with the order-id as a get variable in the URL. Your download script would then check the order-id and make sure the paid flag was set before initiating the download. I use this script as a starting point for my ipn.php file https://github.com/paypal/ipn-code-samples/blob/master/paypal_ipn.php Just add: include("./index.php"); at the top to bootstrap in PW and then inside: if (strcmp ($res, "VERIFIED") == 0) { you can use the PW API to set the paid flag to true etc.
    1 point
  26. This sounds a bit shizophren to me: clients want to have a powerful and great website but are not willing to pay 10$ per month for a good working shared host? This is similar to people that buy a big windows machine for 2.000+ with viodeoadapter(s) that cost 500 per unit. Buy games that cost (I don't know) but want to save 29,95 for a commercial Antivirus-App. --- And also with this sluggish shared hosts you will run into other serious problems like not enough memory for php (when it comes to image manipulation), very restrictive settings or using a not well configured apache with php as fastcgi (wath is in fact the opposite of fast), etc. etc. It doesn't depend on the DB alone, so what will be next that would be great to build into PW to _help_ the clients save 5$ per month?
    1 point
  27. I don't have a static IP and I use a special string within the UserAgent, for example: RewriteCond %{HTTP_USER_AGENT} !^.*(b346a0b6fe9d440d68e07c9619c0ba0a).*$ This way (with switching UserAgent of the browser) I am able to look to the site as admin and like the public from the same IP.
    1 point
  28. U I often use $field = $modules->get("InputfieldMarkup"); $field->value = "<label><input type='checkbox' name='newsletter'>Ja, ich möchte per E-Mail über Neuheiten informiert werden</label>"; $form->append($field); Also you could use InputfieldCheckboxes and use addOptions(key, value) so you can set to not display header, but it will make the checkbox name an array $field = $modules->get("InputfieldCheckboxes"); $field->skipLabel = Inputfield::skipLabelHeader; $field->addOption("newsletter", "Ja, ich möchte per E-Mail über Neuheiten informiert werden"); $form->append($field);
    1 point
  29. One other immediate solution is to use Ryan's Hanna Code. I adapted the module to Hanna code, and it seems to be working pretty well, although the tags are a bit different: {fieldname:2} and [[images f="fieldname" n=2]] It looks a bit more complicated at first, but it's not really. Here is a resumed explanation: defaults: [[images p="0" f="0" n="0"]] where p is the page number, f is the field name and n is the image position on that field. The above is equivalent to simply: [[images]] And it will get all the images from the first field of the "image" type on the same page of this Hanna Code field. Because: if $p="0"; // $p will hold the $page object if $f="0"; // $f will hold the first images field found on $p if $n="0"; // $n will echo all the images from $f From here you can have any combination: [[images n="4"]] // echoes the image on the forth position of the first image field of this page [[images p="1" f="myimages"]] // echoes all the images of the field "myimages" in the homepage That's it. Here is the string to import this Hanna Code: !HannaCode:images:eyJuYW1lIjoiaW1hZ2VzIiwidHlwZSI6IjIiLCJjb2RlIjoiXC8qaGNfYXR0clxucD1cIjBcIlxuZj1cIjBcIlxubj1cIjBcIlxuaGNfYXR0cipcL1xuJG15UGFnZSA9ICRwID8gJHBhZ2VzLT5nZXQoJHApIDogJHBhZ2U7XHJcbiRmaWVsZE5hbWUgPSAkbXlQYWdlLT5maWVsZHMtPmdldCgndHlwZT1GaWVsZHR5cGVJbWFnZScpO1xyXG4kbXlGaWVsZCA9ICRmID8gJG15UGFnZS0+JGYgOiAkbXlQYWdlLT4kZmllbGROYW1lO1xyXG5cclxuJGluZGV4ID0gJG4tMTtcclxuXHJcbmlmKCRteUZpZWxkIGluc3RhbmNlb2YgUGFnZWltYWdlcyl7XHJcbiAgICBpZigkbil7XHJcbiAgICAgICAgJGltYWdlID0gJG15RmllbGQtPmVxKCRpbmRleCk7XHJcbiAgICAgICAgJGltYWdlID0gXCI8aW1nIGNsYXNzPSdJbWFnZVRhZ3MnIHNyYz0nJGltYWdlLT51cmwnIGFsdD0nJGltYWdlLT5kZXNjcmlwdGlvbic+XCI7XHJcbiAgICB9IGVsc2Uge1xyXG4gICAgICAgICRpbWFnZSA9IFwiXCI7XHJcbiAgICAgICAgZm9yZWFjaCgkbXlGaWVsZCBhcyAkaW1nKXtcclxuICAgICAgICAgICAgJGltYWdlIC49IFwiPGltZyBjbGFzcz0nSW1hZ2VUYWdzJyBzcmM9JyRpbWctPnVybCcgYWx0PSckaW1nLT5kZXNjcmlwdGlvbic+XCI7XHJcbiAgICAgICAgfVxyXG4gICAgfVxyXG4gICAgXHJcbn0gZWxzZSBpZigkbXlGaWVsZCBpbnN0YW5jZW9mIFBhZ2VpbWFnZSl7XHJcbiAgICAkaW1hZ2UgPSBcIjxpbWcgY2xhc3M9J0ltYWdlVGFncycgc3JjPSckZmllbGQtPnVybCcgYWx0PSckZmllbGQtPmRlc2NyaXB0aW9uJz5cIjtcclxufSBlbHNlIHtcclxuICAgICRpbWFnZSA9IFwiXCI7XHJcbn1cclxuXHJcbmVjaG8gJGltYWdlOyJ9/!HannaCode
    1 point
  30. Greetings, Hey Beluga! First, welcome, and glad to see you here. I seem to recall many Joomla/Seblod conversations with you in the Seblod forums. Now, to your question... How much data are you talking about here? If it's a "reasonable" amount, it may be easier to just re-build the pages. ProcessWire has a terrific import feature that lets you take a csv file and pull the columns directly into ProcessWire fields, creating new pages. I have used it to pull in thousands of listings for a project I'm doing for a TV station (with 58 custom fields). Here are the general steps to follow: 1. Install the csv import module (http://modules.processwire.com/modules/import-pages-csv/) 2. Create your "content type" in ProcessWire with all the fields you need 3. Export the relevant tables from your Seblod database 4. Create a csv file from the data in step 3 5. Give your csv file a header row, the top cell of every column containing the exact name of your ProcessWire field 6. Go to admin > setup and run the csv import module (directions are very clear from there) It's really easy -- and fast. After you run this, you will have a set of pages in ProcessWire with the fields and data you need. I can provide more details if you need it. Thans, Matthew
    1 point
  31. I've not tested this code but it's a first guess at how I might try this. It assumes $email and $pass hold sanitized input from a custom login form. $who = wire()->users->get("email=$email")->name; if($who) $user = wire()->session->login($who, $pass); if($user) { // they authenticated ok... } else { // they didn't }
    1 point
  32. SQLite has some advantages over MySQL, such as: 1. Lower memory footprint 2. No need to have a dedicated server process running. 3. Easier deployment: no need to install additional software besides PHP and Apache. 4. Great for local development (easier setup). 5. Easier to migrate content from the local machine / staging server to the production server and vice-versa (you only have to FTP one file, no need for data migration tools and SSH tunnels). 6. Easier to backup/restore. 7. Easier to configure and maintain (less knobs and dials to finetune). 8. More flexible schema (columns are not statically bound to a specific type) and simpler data types. 9. Has good read concurrency (enough for small/medium websites). And SQLite does support triggers, foreign keys, multi-column and multi-datatype (per column) indexes, constraints, cascade updates/deletions, transactions, and other features (much more than people usually assume). It also has decent performance, if the database is correctly indexed and if the SQL queries follow some optimization rules. Weak points: 1. It's not good for write-heavy applications, as tables are locked when writing. (note 1: most websites are usually read-heavy, and write to the database much less frequently). (note 2: there is a new operational mode for SQLite that allows for simultaneous read and write but I'm not sure if it can be enabled in PHP). 2. Join performance is not as good as with other, more powerful, databases. As for the level of demand for SQLite support, let's see what the community has to say ;-) I just wanted to bring this possibility (of SQLite as an alternative) to your awareness, so that if the community starts asking for SQLite, you will be able to reply "Perhaps" instead of "Not possible". Regards
    1 point
×
×
  • Create New...