Leaderboard
Popular Content
Showing content with the highest reputation on 02/14/2013 in all areas
-
Luis makes it sound easier than it is , but if you have the time it's certainly possible. Here are two examples of how to implement "adding friends" and "articles wall" just to give you an idea (written in the browser from my mind and very very very over simplified): //adding a friend $new_friend = $pages->get("template=user, name=$input->post->new_friend"); //assumes that a friends field of page type with all other users was already added to the users template $user->friends = $new_friend; $user->save; //outputing a wall of articles only from the user and his friends //creating a string with all the friends separated by a pipe character (OR) to put in the selector $friends = ""; foreach($user->friends as $f){ $friends .= "|" . $f; } //find the articles from the user ($user) and his friends ($friends) and render them echo "<div id='wall'>"; foreach($pages->find("template=article, created_users_id=$user$friends") as $a){ $a->render(); } echo "</div>"; edit: modified the second example to use the buit in selector "created_users_id".3 points
-
3 points
-
Whenever I'm stumped on a particular piece of code, I usually end up having a nightmare/eureka moment with them in my dreams. It's either I get stuck in a loop, or when I'm lucky, I get an idea about the solution. Particularly in college, I remember being chased by a transmuting binary snake while I was working on an experimental improvement on the Lempel-Ziv algorithm! It took me days to solve the problem and each night the snake would eat me whole in my dream.3 points
-
Hey, guys. After much reading, learning, and experimenting with ProcessWire, I finally have something to show: humblebump.com It's not totally finished - there are some features I want to add - but I feel good shipping it as is and adding as I go. ProcessWire is great because I can add things as I learn. It's really flexible. Thanks for checking it out. Let me know what you think or if anything looks/works strangely.2 points
-
I have nice module to share to make users list more manageable with 1000+ users. I don't remember if I have released it yet though (and on mobile now).2 points
-
Hi Matthew, Welcome to the forums. I believe you could build it with PW since just about anything is possible given coding effort. However just because you could does not necessarily mean you should. There would be much to work out. Just as there would be in EE (unless you already built something similar). Big factors in development effort here would be related to the level of automation required. Your specs bring up more questions than I care to ask at the moment. Posting a big scope for review and feedback is usually asking alot in a forum. Best to approach it one bite at at time. ProcessWire is a great CMF/CMS and can accomplish much of what you can with EE, without the expense of third party modules. I have not built a site in EE that mimics the functionality you require, so I won't comment on its fitness to the task. You just might want to take a look at moodle and evaluate it for this particular project. It is a learning management system that might have many of the features you need built in or available in a plugin already. Since your here, I will say this. ProcessWire has good docs and the api is easy to follow. You can quickly be very productive. The community here is helpful and friendly. Come on down and kick the tires. Might not be a match for every project, but it is for most I am working on.2 points
-
First there was an object. It was so lonely and had no home so we gave him an url. It was very happy and lived long until someone came and deleted it.2 points
-
http://processwire.com/api/cheatsheet/#page 5th entry in that list. $page->url is something so basic and covered all over the place on processwire.com. It's all under API, as it's the only thing you need to know to build templates/pages http://processwire.com/api/what/ http://processwire.com/api/templates/ http://processwire.com/api/variables/page/ http://processwire.com/tutorials/quick-start/navigation/ Or of course http://wiki.processwire.com/index.php/Main_Page. If not, there's even a basic site when you install PW which also is something you want to study first when starting with PW and come ask question if you don't understand something here. I think that's quite good and there's many people think PW has exceptional documentation for a OS project. For some strange reason we still have to figure out why some people think the opposite. There's also the forum which has tons of examples (might use google search to search) and simple questions get answered here mostly immediately.2 points
-
You can detect whether the current page was loaded from ajax by checking the value of $config->ajax from your template file: <?php if($config->ajax) { // page was requested from ajax } Following that, you will likely want to render the page differently to accommodate whatever you are doing from the javascript side. For instance, you might want do one of these: 1. Deliver alternate or reduced markup when loaded from ajax 2. Deliver a JSON or XML string for parsing from javascript Below are examples of each of these scenarios. 1. Deliver alternate or reduced markup when loaded from ajax You might find checking for ajax helpful when you want portions of pages to load in your site without re-rendering the entire page for each request. As a simple example, we'll use the default ProcessWire site and make it repopulate it's #bodycopy area when you click a page in the top navigation. (To use this example, you'll need the default ProcessWire site templates, though you can easily adapt the example to another situation.) To accomplish this, we'll update our main page template to only include the header and footer markup if the page is NOT being loaded from ajax: /site/templates/page.php <?php if(!$config->ajax) include("./head.inc"); echo $page->body; if(!$config->ajax) include("./foot.inc"); Next we'll update the top navigation to do ajax loads of the pages when the client has javascript (and leave as-is when they don't). Paste this javascript snippet before the closing </head> tag in the header markup file: /site/templates/head.inc: <script type="text/javascript"> $(document).ready(function() { $("#topnav a").click(function() { $("#topnav a.on").removeClass('on'); // unhighlight selected nav item... $(this).addClass('on'); // ...and highlight new nav item $("#bodycopy").html("<p>Loading...</p>"); $.get($(this).attr('href'), function(data) { $("#bodycopy").html(data); }); return false; }); }); </script> Now when you click on any page in the top navigation, it pops into the bodycopy area without a page load visible from your browser. And all pages remain accessible from their URL as well. Note that this is just a test scenario, and I probably wouldn't use this approach for the entire bodycopy area on a production site (it would make bookmarking difficult). But this approach can be very useful in the right places. 2. Deliver a JSON or XML string for parsing from javascript Lets say that you want pages in your site to return a JSON string with the page's id, title, and number of children when it is requested from ajax. When not requested from ajax, they will return their content as normal. To handle the ajax requests, you'd want to add something like this at the top of your template file before any other output. <?php if($config->ajax) { // this is an ajax request, return basic page information in a JSON string $json = array( 'id' => $page->id, 'title' => $page->title, 'numChildren' => $page->numChildren ); echo json_encode($json); return; } // not ajax, continue with regular page output And here is some markup and inline javascript you might use to test the ajax call on some other page (or the same one if you prefer). You would paste this snippet right in your site's markup where you want that info to appear. <ul id='info'></ul> <script type='text/javascript'> var url = '/'; // this is homepage, so replace '/' with page URL you want to load JSON from $(document).ready(function() { $.getJSON(url, function(data) { $.each(data, function(key, value) { $("#info").append("<li>" + key + ": " + value + "</li>"); }); }); }); </script> The above snippet would output something like this: • id: 1 • title: Home • numChildren: 5 To take this example further, you could build an ajax-driven sitemap or any number of web services. Conclusion Hope this helps you to see how simple it is to use ProcessWire to deliver output for ajax. These are just contrived examples, but hopefully examples that might lead to more ideas. In addition, much of what you see in these examples is also applicable to building web services in ProcessWire.1 point
-
Greetings Everyone, Literally... I have been having code dreams lately. In the dreams, I get some new idea and I work out the logic. Then I actually see -- and hear -- the code. Of course, it always seems so brilliant in the dream! Anyone else have this kind of experience? Off to bed, Matthew1 point
-
It took me a while tonight but I think I understand option "pages" now. The affordance for flowing checkboxes into multiple columns is the cherry on top. I want to buy someone a drink. I am *thrilled* with this software.1 point
-
You have to click first on the title, then click on "move". Now you can drag the page somewhere else. If you want to change the parent, you have to click on the new parent first and open its children. Now you can drag a site under this parent. Also make sure that your user has the right to sort / drag children and that the parent template has no sort settings for children defined.1 point
-
Ah! Easy-breezy. For anyone looking for an answer to this, there is a variable in the $config->urls for root! So the above image tag can look like this: <img src="<?php echo $config->urls->root ?>assets/images/russellbits-logo-small.png" alt="Russellbits"/> Nice.1 point
-
Must be on the template file because the echos are not inside a function edit: actually they are . But still it must be on the template file1 point
-
I am having one little problem, which may be unrelated, to do with the Thumbnails module. For me uploading images breaks with 2.2.13 See here: http://processwire.com/talk/topic/643-release-thumbnails/page-8#entry27367 Just in case something has changed that might affect other modules too...1 point
-
We've got pages and tags. Pages use template "company" and the template has a Page-field called "tags" (input method is checkboxes, template restricted to "tag"). Like this: c1 (tags: "t1") c2 (tags: "t1", "t2") c3 (tags: "t2", "t3") c4 (tags: none) Finding companies having (at least) one of the tags t2 or t3 would be: $pages->find("template=company, tags.title=t2|t3"); This returns pages c2 and c3 as expected. So far so good. But when we're trying to find pages without certain tag(s) selected, results aren't what we expected them to be. Like this: $pages->find("template=company, tags.title!=t1"); This gives again pages c2 and c3. There's obviously at least two things wrong with the resultset: - page c2 does have tag t1 --> should not be included - page c4 does not have tag t1 --> should be included And finally, what we were actually trying to achieve was finding pages with tag t3 but without tag t2: $pages->find("template=company, tags.title=t3, tags.title!=t2"); And this gives page c3, which is more or less understandable given the previous example of != not working the way it's supposed to be. Still it's wrong. It seems to me that != operator does not work correctly with fields having more (or less!) than one row per page in their database table. This just isn't covered with the way JOINs are used at the moment (and once again I'm not skilled enough to say how it should be done). I'm going to be away from the forums for a few days but I'm sure teppo will take over the conversation if there's any details missing regarding the way we're trying to do this. And yes, we're aware using filter() for the != -part would probably solve this, partly. Still the selectors don't work as expected and pagination would have to be handled somehow. (Edit: fixed a typo 'page t3' -> 'page c3' so that it wouldn't be misleading)1 point
-
@nik these should now all be working with the latest version of the test suite and latest commit to ProcessWire dev. Thanks for your help in tracking down these issues.1 point
-
Hi Crownofthorns Depending on what your experience level is, you may want to try one of these tutorials (or both!) http://wiki.processwire.com/index.php/Small_Project_Walkthrough http://wiki.processwire.com/index.php/Basic_Website_Tutorial The first is a really good introduction to the system, the second is more about getting you started.1 point
-
Ah I found the error: $name = $u->name; $pass = $u->pass; if ($session->login($name, $pass)) { $session->redirect("../"); } This cannot work because $u->pass is already encrypted by Pw. You need the Password in plain-text for the login: $pass = $input->post->pass; $message = "Congratulations! You have successfully registered and have been logged in"; echo "<h5 class='success'>$message</h5>"; This message will never appear because you do a redirect after creating the user.1 point
-
Hmmmmmm, i just deleted exactly what u wanna achieve 2hours ago because i needed an email verification before first login. Its definitve possbile to Login a User after registraton. My Script was something like this: Registry Page. Vailidate Input. Create User Dashboard as Page. Create User. Redirect to Dashboard and Login. Im back in my office in 20minutes. I'll take a look if i could restore the Script.1 point
-
Than you should use soma's solution if(!$users->get($username)){ // go ahead, add the guy } edit: but it's good that you learned the array stuff1 point
-
1 point
-
$userNames = array(); foreach ($users->find("start=0") as $u) { array_push($userNames, $u->name); } This should place all the usernames in an array.1 point
-
This should also output the names foreach ($users as $u) { echo $u->name; } And you can put them in an array like this $names = array(); foreach ($users as $u) { $names[] = $u->name; } print_r($names);1 point
-
Maybe still no the best, but you can also use this great module by Nico to add a delete action to page tree. http://modules.processwire.com/modules/process-page-delete/ Open admin tree and browse to users, delete one after another. BTW I think this module doesn't belong to Process module but Admin Helpers, Nico?1 point
-
1 point
-
Thanks for correcting me soma. That was a basic error, I should be more careful. shouldn't we make it obvious and just implement google search alongside the forum search?1 point
-
You should check out the ImportPagesCSV. It can import users too. I've not done it myself, but read through the forum thread for more info!1 point
-
Jennifer, I once wrote a little something about pages http://processwire.com/talk/topic/2296-confused-by-pages/ You may appreciate it.1 point
-
Buy Ryan one, but if he is not available you can join me for a round on you. It does rock!1 point
-
I actually find some of my best problem solving occurs while I sleep. I push the tough ones into the night shift and wake up and implement the solution. Now if I can figure out how many hours to bill the client for actual sleep work, I will be all set.1 point
-
Okay, Soma just gave an answer that was almost as silly as the one I was going to give! I think the logic is: $page - that is the current page $page->image_field - that is the name of our image field belonging to the current page $page->image_field->url - that is the url belonging to the image field belonging to the current page and of course $page->image_field->description - that is the description belonging to the image field belonging to the current page where we started the conversation. So, there is a logic to it!1 point
-
I am also in a need for a feature like that to convince a customer to do the switch. I got used to it with Drupal 7 ("diff"-module) and did not experience it slowing down things, or to be über-complex. http://drupal.org/project/diff Cool stuff. It wasn't too complicated so, a.f.a.i.k. it is limited on node text and title fields. You could easily navigate the versions, see all (text) differences highlighted and could roll back (which means that a new version is created with the content of the selected older version, so you could even revert that change later). Anyone knowing this module? Maybe this is a route a processwire module could go as well.1 point
-
If I remember correctly the input->whitelist is adding those get variables. So tweak your code so that $input->whitelist doesn't get set at all when empty values.1 point
-
That conversion function is not in the PW API (SEE http://processwire.com/apigen/class-ImageSizer.html), but PW does use GD. GD has functions that can do this. So you can accomplish what you want. See imagecreatefrompng http://php.net/manual/en/book.image.php Take a look at this http://stackoverflow.com/questions/1201798/use-php-to-convert-png-to-jpg-with-compression1 point
-
This should all be sorted now and, although you won't spot any cosmetic changes, some of those bugs people were encountering should be gone as well (fingers crossed!).1 point
-
sounds like the same I got, when trying to install PW with 'ProcessWire Blank Profile'. This was fixed in the newest dev version.1 point
-
1 point
-
This is the normal behaviour if you want search options via GET. Adding your get vars to the whitelist makes the pagination work with those vars. If you don't want to see the variables, use POST for your search form.1 point
-
Hi pwusr Basically it is much as Soma said a couple of posts up. You create your menu/site structure using pages that represent categories (as Ryan has said before, because of the page structure of PW, they can be seen as a hierarchical category structure) But then you need to add products to each of these categories. You can either make those child pages of the categories, or you can store them completely separately and add a Page field to them to select your "category" For example. Create a page field (call it category) Set it to the third option - single - on the details tab. On the input tab, set Home as the parent (remembering all your categories are going to be children of the home page) and set the template as what ever your category template is. At the end of the input tab, set the field type to "select" - you don't need anything more clever. Now, add this field to your product template. Now, when you create a product you can use this page field to select a "category" Those product pages can be stored anywhere. However, you probably don't want them to appear on the main menu - you just want your category pages and any info pages there. So, create a template called "product-list" that has no file. Once you have saved that, go to the Family tab and where it says "Allowed templates for children" choose you product template. Go to pages and create a new page under Home. Choose the product-list template. Save and then under settings make sure this page is Published and Hidden. Now, any children of this page will not display on the main menu. So you can create all your products as children here. You can leave them as one long list, or split them up into manageable sub levels - up to you. It wont affect what is displayed on the front of the site since it is the category pages field that will do that job. On your category template, you can now use the $pages->find (see cheat sheet) to bring up all the pages that have the template "product" and where their category pages field matches the current page, and then loop through them. The final result is that the structure of the front end of the site is based around the category pages and how you have organised those, and the products are simply displayed because of the category they are related to. As you can imagine, using the same principle, you can associate your pages in all kinds of ways - using tags, is a good example. Sorry if I wasn't clear before - hopefully this is better! Joss1 point
-
First confirm that you can resolve localhost. From a shell prompt, ping localhost. If you don't resolve the name, confirm that there is an entry in /etc/hosts If localhost resolves, and the MySQL server is running, validate a db connection by simply using the mySQL command line client. $> mysql -h host -u user -p Where host is localhost and user is a valid user account. Can you connect? If you can connect, can you use the DB you created for ProcessWire? Following this procedure would isolate the issue.1 point
-
hi Ryan you can add also the transliteration of greek language if you want it. there is also a drupal transliteration module with (i think) all languages, i do not know if this can help you http://drupal.org/project/transliteration thanks. 'α' => 'a', 'ά' => 'a', 'αι' => 'ai', 'αί' => 'ai', 'αϊ' => 'aï', 'αυ' => 'ay', 'αύ' => 'ay', 'β' => 'v', 'γ' => 'g', 'γγ' => 'gg', 'γκ' => 'gk', 'γχ' => 'gch', 'δ' => 'd', 'ε' => 'e', 'έ' => 'e', 'ει' => 'ei', 'εί' => 'ei', 'έι' => 'ei', 'ευ' => 'ef', 'εϊ' => 'eï', 'ζ' => 'z', 'η' => 'i', 'ή' => 'i', 'θ' => 'th', 'ι' => 'i', 'ί' => 'i', 'κ' => 'k', 'λ' => 'l', 'μ' => 'm', 'μπ' => 'mp', 'ν' => 'n', 'ντ' => 'nt', 'ξ' => 'x', 'ο' => 'o', 'ό' => 'o', 'οι' => 'oi', 'οϊ' => 'oi', 'οί' => 'oi', 'ου' => 'oy', 'οϋ' => 'oy', 'ού' => 'oy', 'π' => 'p', 'ρ' => 'r', 'σ' => 's', 'ς' => 's', 'τ' => 't', 'υ' => 'y', 'ύ' => 'y', 'φ' => 'f', 'χ' => 'ch', 'ψ' => 'ps', 'ω' => 'o', 'ώ' => 'o',1 point
-
Just for interest, I have just finished the cartkeeper site. You can read about it here complete with before and after shots: http://stonywebsites.co.uk/news-articles/stony-company-get-website-facelift/1 point
-
Also, shameless self-plug here: for even easier way to install, use & manage your Flourish install, checkout my new micro-module: http://processwire.com/talk/topic/2756-libflourish-%E2%80%93-flourish-auto-loader-for-processwire/1 point
-
There is something about working with PW that seems to be encouraging people towards nice clean design. A great example!1 point
-
Järjestelmä - System Epäjärjestelmä - Unsystem Epäjärjestelmällisyys - Unsystematicality Epäjärjestelmällisyydellinen - Something that is seen as unsystematicality Epäjärjestelmällisyydellistyttää - To make something/-one be seen as unsystematicality Epäjärjestelmällisyydellistyttämätön - One that hasn't made something be seen as unsystematicality / Something that hasn't been made be seen as unsystematicality Epäjärjestelmällisyydellistyttämättömyys - The act of not having made something be seen as unsystematicality Epäjärjestelmällisyydellistyttämättömyydellä - With the act of not having made something be seen as unsystematicality Epäjärjestelmällisyydellistyttämättömyydellänsä - With his/her act of not having made something be seen as unsystematicality. Epäjärjestelmällisyydellistyttämättömyydellänsäkään - Not even with his act of not having made something be seen as unsystematicality. Epäjärjestelmällisyydellistyttämättömyydellänsäkäänkö - Is it not even with his act of not having made something be seen as unsystematicality. Epäjärjestelmällisyydellistyttämättömyydellänsäkäänköhän - I wonder if it's not with his act of not having made something be seen as unsystematicality. source: http://www.finlandforum.org/viewtopic.php?f=9&t=91721 point
-
Just thought I'd share an idea that has popped into my head a few times by now, while working with PW. The purity of the central tree data-structure that powers the ProcessWire data-model, is very elegant, and for the most part works really well for me. One instance where it does not always work well, is in terms of optimizing URLs. Most of the time, simply having items grouped under other items works quite well, but at other times, you can end up with URLs that are littered with keywords that aren't really relevant. Not great for SEO, and not always great for URLs you intend to share via various channels. (Twitter, printed material, etc.) This happens with deeply nested menu structures in particular. On one site, I ended up with a URL like this: "/articles/some-topic/some-page/" - the keyword "articles" has no particular relevance here, it's just a logical grouping, not something you expect people to search for. And "some-topic", in this particular case, was unwanted. The client was asking for a short, user-friendly URL, e.g. "/some-page", and in order to do that, he would have to place the actual page in the root of the site, which was not appropriate in this case. So this brings me back to an idea I've been kicking around (for my own CMS) for some years - the idea of having more than one hierarchy. Actually, an arbitrary number of user-defined hierarchies - with the ability for the user to place a given page in either one or more of these hierarchies. I've had various versions of this idea over the years, but in the simplest version, one of these hierarchies is the designated URL hierarchy - so this would be the hierarchy ProcessWire has now. Other hierarchies are just logical (taxonomic) hierarchies that could be used for whatever purposes you like. So as an example, "product categories" might be a dedicated arbitrary hierarchy, in which "product" pages can be organized logically, independently of the hierarchy that drives the URLs. If somebody is selling iPads, for example, you can place the product in the "product categories" hierarchy, e.g. "tablets/apple/ipad/32gb", which might determine where the product appears on a menu, but does not affect it's URL. This particular product might be placed in the URL hierarchy as simply "/apple-ipad-32gb", for example. (maybe not the best example, as in this particular case, it might make sense to include all the keywords from the category - it's just an example.) This problem could also be addressed, apparently, by allowing a page to be referenced more than once in the tree, or by introducing an "alias" template, so that you can "optimize" URLs by creating "aliases" for pages in the tree. Mathematically, this solution doesn't speak to me - in a real tree, a node should have precisely one parent, otherwise you introduce the potential for things like circular references or circular queries, e.g. traversals like A->B->C->A->B->C->... Or, in the case of aliases (as opposed to references), you introduce "dead" nodes from which you cannot traverse or find subpages, because the "alias" node is a leaf-node, even if the page it references has children. (otherwise, mathematically, it would be a reference and not an alias.) Another possible solution would be to simply allow a custom URL alias for any page. This would probably be relatively simpler to implement, perhaps as simple as adding a "URL alias" text-field to templates that need it, adding a very simple module that does a query for the exact value of that text-field prior to PW doing it's normal traversal and dispatch. (This might not be great for SEO though, as you end up with two URLs for the same page.) Clearly that's a much simpler solution than introducing multiple hierarchies, but for other reasons, the idea of multiple, user-defined hierarchies has always appealed to me. For one, it's not uncommon for the same page to appear under two different menus. As an example, on a site I'm building right now, some blog-posts double as articles that also appear organized somewhere in a category on the main menu. It's the same logical page, and it should have the same URL, regardless of whether you found it in the blog-roll or on the main menu. But because the logical and URL hierarchies are one and the same, there is no simple way to accomplish that. Perhaps the best real-world example I can give, is a product catalog - for one company we worked with, their products were organized by two entirely different hierarchies, because their products are used in two entirely different industries. So you have two independent logical hierarchies, but the pages (and URLs) are the same. I could provide more examples, but I think I've made my point, so I'll leave it at that. Is multiple hierarchies a good solution, or is there another, simpler, more direct solution to these issues?1 point
-
While I'm not in the camp that wants my URLs to go outside my site structure, I can see that it's a need some may have. And you've brought up a very good solution here--we could accomplish this pretty easily. SEO would not be a problem because the module that would implement the solution would hook into the Page::path function to ensure that it's reflecting the alias rather than the original. It would also not be a stretch to have the module perform a 301 to the alias when the page is accessed at the original URL.1 point
-
I like these posts, clear titles, quick answers.1 point
-
That's not far off from what I'd been working on with versioning, which was to store page versions in flat JSON encoded strings in a DB table (though could just as easily be stored as text files). Any ProcessWire page can be reduced to a PHP array of basic types (strings, integers, floats, arrays), which means it can be reduced to a JSON string really easily. This lends itself well to version storage, except for assets where only references are encoded (like files and page references). But I have to admit that the more I think about Antti's proposal to store this at the field-level, the more Iike it. I would create another interface that could optionally be added to a Fieldtype's implements section in the class definition (FieldtypeWithVersions or something like that), and give the individual fieldtypes responsibility for if, how and where they store their versions. That would enable us to get up and running with versions quickly (for text fields at least). It would also seem to provide a nicer level of control to the user, as you don't have to keep track of what is changing in multiple fields at once. And, it would let you to enable versions on fields that you want it, omitting on field where you don't, making things more efficient. Lastly, it would leave the page-structure out of versions completely (where the page lives in the tree), which struck me as a potentially dangerous problem with versions. It could work something roughly like this: You hover over the revisions label and get a summary of recent revisions. You click on one, it could pop up a modal showing you the revision (maybe with a compare tool) and a button to revert to it or cancel. It just seems like a really easy-to-use solution for the user.1 point