Leaderboard

Jumplinks for ProcessWire Latest Release: 1.5.63 Composer: rockett/jumplinks ⚠️ NEW MAINTAINER NEEDED: Jumplinks is in need of a new maintainer, as I’m simply unable to commit to continued development. Jumplinks is an enhanced version of the original ProcessRedirects by Antti Peisa. The Process module manages your permanent and temporary redirects (we'll call these "jumplinks" from now on, unless in reference to redirects from another module), useful for when you're migrating over to ProcessWire from another system/platform. Each jumplink supports wildcards, shortening the time needed to create them. Unlike similar modules for other platforms, wildcards in Jumplinks are much easier to work with, as Regular Expressions are not fully exposed. Instead, parameters wrapped in curly braces are used - these are described in the documentation. As of version 1.5.0, Jumplinks requires at least ProcessWire 2.6.1 to run. Documentation View on GitLab Download via the Modules Directory Read the docs Features The most prominent features include: Basic jumplinks (from one fixed route to another) Parameter-based wildcards with "Smart" equivalents Mapping Collections (for converting ID-based routes to their named-equivalents without the need to create multiple jumplinks) Destination Selectors (for finding and redirecting to pages containing legacy location information) Timed Activation (activate and/or deactivate jumplinks at specific times) 404-Monitor (for creating jumplinks based on 404 hits) Additionally, the following features may come in handy: Stale jumplink management Legacy domain support for slow migrations An importer (from CSV or ProcessRedirects) Open Source Jumplinks is an open-source project, and is free to use. In fact, Jumplinks will always be open-source, and will always remain free to use. Forever. If you would like to support the development of Jumplinks, please consider making a small donation via PayPal.

(Removed)

Hi @paulbrause, Lots of great suggestions above regarding PageTable fields etc, but I just put together a quick module that I think does exactly what you are looking for. https://gist.github.com/adrianbj/2b3b6b40f64a816d397f To make it work as is, you will need these: Templates: album (for the album parent pages) image (used for the automatically created child pages) Fields: images (for the album template) image (for the image template)

From my point of view this has less to do with html5 and more to do with SEO. The general thought is that you should have one H1, then a group of H2s, more H3 and so on. Though there are arguments against that as well. It is all about second guessing Google and Bing When it comes to HTML5 and SEO, however, it is probably more important to look at structural elements such as <article> and <section> and then the relevant attributes from Schema.org: <article role="article" itemtype="http://schema.org/BlogPosting" itemscope> And so on

Just thought I'd share my git hook (post-receive) that I've been successfully using for a few months now to update my beta site and production site via git (no more ftp!). Might help someone else. As you can see, I only have the "site" folder under version control. But now when I'm thinking about it, site/templates should probably be enough. #!/bin/bash while read oldrev newrev ref do if [[ $ref =~ .*/master$ ]]; then echo -e "Master ref received. \e[42mDeploying master branch to production site...\e[0m" WORKTREE=../site # define your work tree, where you want to push the files cd $WORKTREE # navigate to the work tree GITDIR=../mysite.git # in relation to the "cd" command above # update the working tree git --work-tree=./ --git-dir=$GITDIR checkout -f master git --work-tree=./ --git-dir=$GITDIR clean -fd master # return to git directory cd $GITDIR else echo -e "Ref $ref received. \e[104mDeploying $ref branch to beta site\e[0m" WORKTREE=../beta/site cd $WORKTREE GITDIR=../../mysite.git # in relation to the "cd" command above # update the working tree git --work-tree=./ --git-dir=$GITDIR checkout -f stage git --work-tree=./ --git-dir=$GITDIR clean -fd stage # return to git directory cd $GITDIR fi done

@Gazley, Yes, you are right about what elements can be nested in what. Thanks for helping me rethink this. For the benefit of others, below is a lengthy explanation + the solution I propose (you can skip right to it ) Resources: http://www.w3.org/TR/html401/struct/text.html#h-9.3.1 http://stackoverflow.com/questions/12015804/nesting-p-wont-work-while-nesting-div-will http://ckeditor.com/forums/Support/Nested-paragraph-tags. http://webtips.dan.info/nesting.html - old but good http://www.iamchristinabot.com/blog/20110519/why-do-nested-html-paragraphs-break-css/ http://stackoverflow.com/questions/4291467/nesting-block-level-elements-inside-the-p-tag-right-or-wrong Explanation: First the code in MarkupBlog.module //MarkupBlog Line #933 //notice the surrounding '<p></p>' tags if($small) $out .= "<p>" . $page->summary . "… <a class='more' href='{$page->url}'>" . $options['post_more_text'] . "</a></p>"; In your template file e.g. 'blog-posts.php', assuming you have this code: $options = array( 'post_small_image' => 3,//here for array illustration only 'post_small_image_width' => 250,//ditto 'post_small_allowable_tags' => '<h2>', ); //render a limited number of summarised posts $content .= $blog->renderPosts("limit=5", true, $options);//passed $options to renderPosts() Example content entered in your 'blog_body' <p>This is my paragraph that I am going to test.</p> <p>Here comes a second paragraph.</p> <h2>And here comes a h2 we will allow through.</h2> <p>This is another paragraph.</p> <p>Our final paragraph.</p> <h2>A second h2 to allow.</h2> 1. Output without 'post_small_allowable_tags' <p>This is my paragraph that I am going to test. Here comes a second paragraph. And here comes a h2 we will allow through. This is another paragraph. Our final paragraph. A second h2 to allow</p> 2. Output with 'post_small_allowable_tags' In the second output, since you have allowed <h2> (it doesn't matter whether they came first or in-between other text in your content), this is what line #933 will send to the browser: <p>.....<h2>........</h2>..........<h2>........</h2>..</p>; As stated, that is invalid code and the browser will remedy it. The next block level element will be used to close the first <p> or the browser will self-close it (empty <p></p>). So, what you will end up with in the browser is: <p></p><h2>....</h2>some free untagged text<h2>....</h2></p>. Although the browser (view source) will seemingly also place an empty <p></p> at the end of the text, in fact, it will just be a closing </p> without an opening <p>. The W3C validator will then give you the error 'No p element in scope but a p end tag seen.' For comparison, if you allowed an inline element, e.g. <img> tag instead $options = array('post_small_allowable_tags' => '<img>'); This would be output correctly since an <img> is an inline element. The output would be: <p>Some text<img>More text<a>Read More</a></p>. Hopefully this long explanation will help inform decisions about how to use the solution I envisage. Solution I will make what HTML element (or not) to surround a blog excerpt (blop post small) with configurable (add to $options). So: Let user decide whether to surround post excerpt with <span>,<p>, nothing, etc. since they know what tags they will be making 'allowable' (inline vs block level). The option will apply whether using 'post_small_allowable_tags' or not. Default will be to surround with <p>. An empty value passed to the option will mean 'do not surround the excerpt with anything'. I will also add a class to that tag, e.g. <p class='post-excerpt'>...</p> to aid with more specific style-targeting. Hope to update this soon. The update should not break any existing installs since it will default to the current use of <p></p> tags.

Introducing ProcessWire ProFields: Table – it lets you literally define your own Fieldtype! This is one of the most exciting ProFields and it's something very different than any other Fieldtypes. I think it is best described by this screencast (be sure your sound is on): Special thanks to Joss for his great voiceover on this screencast. Please view the video at 720p and full screen if possible. Read more about the Table Field Table is part of the ProcessWire ProFields package now available for purchase in the ProcessWire store.

I have been spending some long evenings building PadLoper. It is my personal project to challenge myself as a developer, but also something I believe ProcessWire really misses: a solid eCommerce platform. I am happy to announce, that I am not very far away from public release, so I did create a little teaser site and email list for all of you that are interested: https://www.padloper.pw/ As many of you now, I also have bunch of eCommerce modules called "shop for processwire". Those remain open source modules, but I am not actively maintaining them (like I really haven't since 2012). All the code in PadLoper is new and it's totally build from ground up. If someone wants to maintain or develop shop for processwire further, I am more than happy for that. There will be some open source components coming from PadLoper also: at least payment modules, but I might also open source the shopping cart module. Padloper released 4th October, 2015: https://www.padloper.pw/

That is really cool Adrian! Super simple approach, and elegant to boot. Do you think that this could use a field for image description though, other than the image title I mean?

OK thanks Soma. After a lot of digging around I worked out that it was a foundation 5 javascript option being mis-applied by default. In case anyone else is having the same problem with topbar in foundation 5, then add data-options="mobile_show_parent_link: false" to the nav element

That may be because you switched these two rules around when you were encountering problems: # ----------------------------------------------------------------------------------------------- # Pass control to ProcessWire if all the above directives allow us to this point. # For regular VirtualHosts (most installs) # ----------------------------------------------------------------------------------------------- # RewriteRule ^(.*)$ index.php?it=$1 [L,QSA] # ----------------------------------------------------------------------------------------------- # 500 NOTE: If using VirtualDocumentRoot: comment out the one above and use this one instead. # ----------------------------------------------------------------------------------------------- RewriteRule ^(.*)$ /index.php?it=$1 [L,QSA] As such, it's looking for index.php in the root of domain, not the root of the installation. If you swap them around again (comment the second one, uncomment the first one), it should work. Please let me know if it doesn't...

@renobird -- Glad you like it! Yeah, please; I'll appreciate that very much.

Wow! Nice work Mike! I'll try to carve some time later in the week to give this a thorough test run.

You could always create an "issue" for this feature over on github. Might be a while before it happens but at least it will be more obvious on Ryan's radar over there.

Interesting, I wrote a little function to handle this for a email success form message. Well at least I learned a little bit more about post in the process .

I like the dual approach, he gets the way that takes 1/10th the time, and his mum and dad get to click, drag, type . Also he gets to use one of the coolest modules in the processwire arsenal.

I thought this was meant to be user friendly for someone without much tech skills? If you want to go for the one at a time approach, Page Table will probably be better than repeater, by the way. That way, you get to choose where all the new pages are created (you define a parent as part of the field). But as I said, if you want them to be able to just drag and drop a pile of images in one go, then you need to use an image field.

I haven't used it, but you might want to look at this module: http://modules.processwire.com/modules/fieldtype-image-extra/ The trouble with the page per image approach is that you wont be able to do multiple uploads in the way you suggest. Using this module looks like you can add extra info while still having all the advantages of the image field array

Yes, would be nice if upload of the images & creation of the pages could be automated. I thought of setting the maximum of photos per album to 48. Not sure, how often this maximum will be reached, mostly there will be ~20 pics. I guess there will be a new album 3-4 times a month. The workflow should be like this: - user logs in admin-panel - creates under "photos" new page like "my wedding". fields under this template should be "title", "date" & "cover image"... - uploads photos (perhaps possibility of rearranging, deleting and tagging of uploaded photos) - one click and the magic will happen (creating separate page for every uploaded photo, setting title of page to image-name and so on) This should be as simple as possible, cause my father and my mother will use this system too... Hope this answers your question.

Can you please answer the following: What is the structure of your site? Describe what fields you are searching on? Give a few examples of situations where the search fails. Are you able to get any search results at all? What program you are saving your edited copy of the search.php file in? Versions of PHP, MySQL and PW. Is this a Local install or an online instance? Platform where you are having this problem. Have you tested this on any other platform? Have you tested this on any other install besides the Blank profile? It would also be informative if you can state in what file are you calling the search form? In the site default profile, the search form is listed as <form class='search' action='<?php echo $pages->get('template=search')->url; ?>' method='get'> <input type='text' name='q' placeholder='Search' value='<?php echo $sanitizer->entities($input->whitelist('q')); ?>' /> <button type='submit' name='submit'>Search</button> </form> in the _main.php file. Have you used the same form syntax to call up the search in your install? If not, could you please list your code. I know these are a lot of questions, however answering them will help someone to help you find a solution to your problem. Best Regards, Charles

could it be a server issue? I had a problem with a server blocking certain combinations of words, it was really strange; turned out to be a mod security issue..

From what I know, you need to have the correct fields you want to search on listed in the search criteria to be successful. I believe the default criteria in search.php for the site-default profile is: $selector = "title|body~=$q, limit=50"; This works great if you are only searching for words in the Title or Body fields. However, If you have any other fields that you want to search on, they need to be added to the search criteria. $selector = "title|requestor_name|requestor_comments|summary|body~=$q, limit=50"; When I first started with PW, I didn't understand this and hence could never get the search results I was looking for. One day the light went on and I haven't had a problem with searching since. I don't know if this is the issue that you are having, however I just thought I would mention it as the default search file works like a charm.

Stripe seems like an interesting alternative to PayPal. Pete worked on a module some time ago: https://processwire.com/talk/topic/4363-stripe-arrives-to-continental-europe/

@Mike, Another example here from FieldtypeComments. PS: Please post all module related development stuff to the Module/Plugins sub-forum/board: Module/Plugin Development https://processwire.com/talk/forum/19-moduleplugin-development/ This board is for 'Questions, answers and support for ProcessWire modules.' . Moving this thread there...

I have seen this, but it's specific to message. I need it for processing decisions.

Paypal is clearly on the side of the buyers for their own popularity. I stopped with paypal because of too many buyers changing their address after placing an order. The goods never arrived and paypal refunds their money, even in case where I could prove the change in address after the order was placed. Paypal don't care about the sellers. They even stopped replying on my emails. Since then I only work with direct bank transfers. Funny that with bank transfers buyers don't seem to change their address after placing an order. I use an extension that automatically sends an email to the buyer each time the state of his order changes, until the order is closed: 1. in process, 2. payment received 3. prepared for shipping 4. send 5. arrived 6. closed. Works perfectly with an online tracking system. All automated emails also include the clients sales history. I am not telling you not to use paypal, use it by all means and see how it works for you.

To start with, payments should always be handled by a payment provider like Pay Pal or worldpay or sage or one of that lot. You should NEVER be keeping payment information on the server with the website. Next, there is an argument that ALL new websites should have certificated now - Google has said they would prefer such sites in results to give users more confidence, which makes sense. All hosting providers supply certificates with many of them doing free offers. It is just a question of following the wizards through when you set up the account, to be honest.

That sounds like something VERY cool!!!

For sure, would like to do this. After we try adding some modules we can check to see if changes are reflected in the remote as they are in the local environments. For now the database is working marvelously and Amazon has a simple code push that we have perfected and this process would be valuable to pw fans.

The clients can be non-technical to use PW, but you have to do some work. There are plugins for PW but the majority of them are not for frontend features. For this all you have to understand is how you can organize things in the PW backend, and how to get those things in your html. Anyway, to be clear I will give you the gallery example: To create a gallery you can have many approaches to collect the images. 1. You can create a parent page called "gallery" and allow for children pages with a single image field on each and any other fields that you need to have info on each image. 2. You can create a page called "gallery" (for example) dedicated only to the gallery where you have a multiple images field that will hold all the images with their descriptions. 3. You can create a multiple images field (or many) along with others fields in that template and use the to make the gallery (or galleries) It's all about flexibility and making your own decisions. search for gallery here in the forums and you will find multiple approaches. Second part is to choose a javascript gallery. There are loads of them, and all you have to do is go to their documentation to know what kind of HTML they expect you to create. Third part is to create that HTML and put the images dynamically to it in your template file. For example, if the JS gallery plugin asks for a list of images in the format "<ul><li><img/></li><li><img/></li><li><img/></li><li><img/></li></ul>": 1. ( where the ("/gallery/") page holds a holds a single image field "image" ) <ul> <? foreach($pages-get("/gallery/")->children() as $imagePage): ?> <li><img src="<?=$imagePage->image->url?>" description="<?=$imagePage->image->description?>"/></li> <? endforeach ?> </ul> 2. ( where the ("/gallery/") page holds a multiple images field "images" ) <ul> <? foreach($pages-get("/gallery/")->images as $image): ?> <li><img src="<?=$image->url?>" description="<?=$image->description?>"/></li> <? endforeach ?> </ul> 3. ( where the page being viewed holds a multiple images field "images" ) <ul> <? foreach($page->images as $image): ?> <li><img src="<?=$image->url?>" description="<?=$image->description?>"/></li> <? endforeach ?> </ul> Edit: while I was writing you had already a very long conversation. I'm still going to submit this

Call me overly cautious, but I'd advice against self-managed VPS if this service needs to be highly secure and especially if you need a high level of availability. Anyone can manage a server when things go smooth -- install updates, add a few rules to a firewall and tweak Apache/PHP/MySQL settings. The real question is how well can you handle things going wrong; someone attacking your server, hardware or software failures (hardware issues are still very real even in this age of cloud computing, I'm afraid), restoring corrupted data etc. What about availability requirements -- do you need high availability and 24/7/365 support.. and if, can you really provide and guarantee that? A lot of time I'd recommend going with managed solution in one form or another rather than trying to do everything yourself. It depends a lot on the requirements and the nature of the service you're running, but the bottom line here is that unless you can guarantee that you're able to handle everything yourself, don't make any promises to the client you'll end up regretting.

Alchime, I actually have not tried out that tutorial yet, so need to take a closer look at that. However, attached is a template file (basic-form.php) that is ready to use as a basic contact form with the default site profile. Let me know if this is helpful? basic-form.php.txt Note that you'll have to rename this to basic-form.php, place in /site/templates/. If you want it to email to a specific address (rather than the superuser) than edit the file and enter your email address in at the top where it says to.