Jump to content

Recommended Posts

How can I change the category name on the bottom. I've installed 2.3.0., the changed names show up correctly but only on the bottom of the message the name didn't change. 

I've included an image

voorbeeld.jpg

Share this post


Link to post
Share on other sites

@toothpaste, until I update the Blog docs, it's all here in post #207. What you want is to pass 'post_categories_text' as part of an array (e.g. $options) as the third argument in renderPosts(). Here's a quick one line example - you would probably do it differently depending on your needs, e.g. create the array with all your options first then pass it to renderPosts(). We replace 'Categories: ' with 'Groups: '

echo $modules->get('MarkupBlog')->renderPosts($pages->get('/blog/posts/material-design/'), '', array('post_categories_text'=>'Groups: '));

Share this post


Link to post
Share on other sites

Thank you Kongondo!

By the way. Your tutorials on Kongondo.com are very useful. Even I can understand:-)

  • Like 1

Share this post


Link to post
Share on other sites

I've added a field called Content_Type to the Blog Post template. I tag *some* posts with as Content_Type=Studio Watch to differentiate them from "regular" bog posts.

There's nothing special about these pages. I simply use the Blog as a central publishing platform but pages marked Content_Type=Studio Watch are special and pulled onto a stand alone section of the site.

Here's how the field looks in the Blog_Post template.

post-1166-0-60360500-1416949775_thumb.pn

Is there a way on the Blog Posts page (front end) to filter out any posts marked with this tag/category.

OR

Maybe I'm trying to do something here which will get me in knots. 

These particular pages shouldn't be listed in the front end under Posts, Categories, Tags, Comments, Authors or Archives.

Hmmm, perhaps I need to not use the blog for this particular task. What do you think?

Share this post


Link to post
Share on other sites

@Peter

Btw, if all you are using the field 'Content_Type' for is to differentiate those Blog Posts from other Posts, remember you can also use a checkbox.  A checked checkbox could denote 'special' posts. Alternatively, if you still want to use the page field 'Content_Type', unless there are other special tags, there is no need for that field to be a Multiple Page field.

There are a number of options. One that would work right across the board (but may not be easy/possible for your editors?) is, instead of adding the extra 'Content_Type' field, just set the page status of your 'special' Posts to 'hidden'. They won't show up in Posts, Tags, Categories, Archives and Authors pages. For Comments and Recent Comments and also to show them in your stand-alone section of the site you would need to do something like below...

Show only special posts in stand-alone section

//find only hidden posts
//$posts = $pages->find("template=blog-post, status>1024");//similar to below but less readable
$posts = $pages->find("template=blog-post, status>".Page::statusHidden);
echo $modules->get('MarkupBlog')->renderPosts($posts);

Remove hidden (special) posts from the output from the demo blog-comments.php, i.e. /blog/comments/

//modified code excerpt. See the file blog-comments.php
$comments = $blog->findRecentComments($limit, $start);
foreach($comments as $comment) {
   //remove comments from blog posts with hidden status
   if($comment->page->isHidden()) $comments->remove($comment);
}
$content .= $page->blog_body . $blog->renderComments($comments, $limit);

Remove special posts from the Recent Comments in the right sidebar of the demo blog (blog-side-bar.inc)

//excerpted and modified from blog-side-bar.inc
foreach($comments as $comment) {

        if($comment->page->isHidden()) continue;//ignore comments from hidden posts
        $cite = htmlentities($comment->cite, ENT_QUOTES, "UTF-8");
        $date = $blog->formatDate($comment->created); 
        $out .= "<li><span class='date'>$date</span><br />" . 
                    "<a href='{$comment->page->url}#comment{$comment->id}'>$cite » {$comment->page->title}</a>" . 
                "</li>";
}
  • Like 1

Share this post


Link to post
Share on other sites

@Peter

Btw, if all you are using the field 'Content_Type' for is to differentiate those Blog Posts from other Posts, remember you can also use a checkbox.  A checked checkbox could denote 'special' posts. Alternatively, if you still want to use the page field 'Content_Type', unless there are other special tags, there is no need for that field to be a Multiple Page field.

Good advice. I was using a PageSelect because in the future I'll have 3 different types of posts all generated from the blogging module.

And thanks for the code samples and explanations too. I've had a bit of a rethink about this. If I'm not using 90% of the Blogs features (Categories, Comments, Athors) etc then I may be better off disconnecting my special posts from the blog. Otherwise I'm trying to adapt and rewire the Blog when it's perfectly suited to it's task and should probably be left alone.

Sorry about the back tracking. Appreciate the examples though. 

Share this post


Link to post
Share on other sites

Version 2.3.0 Installed? 2.2.2

This is themessage we get after we ran the upgrade to Version 2.3.0?

The BlogInstallWizard.php shows

* @author Kongondo

* @version 2.3.0

Andi

Share this post


Link to post
Share on other sites

@Andi, I am not sure I get your question but I think you mean in the modules list PW is listing Blog as 2.2.2 despite having updated to 2.3.0? Maybe PW's module cache didn't clear. In that case, hit the refresh button in PW Module list page. Otherwise, check the other module files, they should all be version 2.3.0.

Share this post


Link to post
Share on other sites

I built some very basic Gravatar functionality into a bigger (site-specific) module recently - please feel to use it: Gravatar.module gist on Github

Thanks for this. I've saved the code to the desktop, zipped it and loaded as a module and get the following error

Parse Error: syntax error, unexpected 'public' (T_PUBLIC) (line 20 of /Users/peterknight/Sites/EdenWeb/site/modules/Gravatar/Gravatar.module) 

 

Any ideas what the issue is there?

Happy to move this to a different forum or a PM if kongondo wishes.

This error message was shown because you are logged in as a Superuser. Error has been logged.

Share this post


Link to post
Share on other sites

Most likely a not closed braces } or something.

Seems fine in terms of opening and closed braces.

I don't know much about Modules but having looked at some other code, it seems like the opening statement

public function init() {
		$this->addHook('User::gravatar', $this, 'methodGravatar');
	}

needs to be preceeded by something like this

class MODULENAME extends WireData implements Module {

Share this post


Link to post
Share on other sites

Have this wierd select box issue.

Anytime I have a list of Related Categories or Related Tags, I get a stray selectbox repeating the Categories or Tags

post-1166-0-10136600-1417195378_thumb.pn

Not sure if it's my browser or the module or Zurb Foundation auto inserting some accessibility thing.

Does it happen to anyone else using the Blog Module?

Share this post


Link to post
Share on other sites

Hi there,

I've tried to install the Blog module for the first time. I have no other related blog pages of any kind. When I try to run the installation wizard, I get the errors below. Any ideas what I should do?

Many thanks.

  •  BlogInstallWizard: Cannot install Blog pages. Some page names already in use. These are: Blog.

  •  BlogInstallWizard: Cannot install Blog fields. Some field names already in use. These are: blog_body, blog_categories, blog_comments, blog_comments_view, blog_comments_max, blog_quantity, blog_date, blog_files, blog_headline, blog_href, blog_images, blog_links, blog_note, blog_summary, blog_tags, blog_small.

  •  BlogInstallWizard: Cannot install Blog templates. Some template names already in use. These are: blog, blog-archives, blog-authors, blog-categories, blog-category, blog-comments, blog-links, blog-post, blog-posts, blog-recent-comments, blog-recent-posts, blog-recent-tweets, blog-tag, blog-tags, blog-widgets, blog-widget-basic, blog-settings, blog-basic, repeater_blog-links.

  •  BlogInstallWizard: A role called 'blog-author' already exists!

  •  BlogInstallWizard: Due to the above errors, the install wizard did not run. Make necessary changes and try again.

  •  TemplateFile: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'blog-author-30' for key 'name_parent_id'<pre>#0 /Applications/MAMP/htdocs/ew/ProcessWire/wire/core/Pages.php(922): PDOStatement->execute() #1 /Applications/MAMP/htdocs/ew/ProcessWire/wire/core/Pages.php(827): Pages->savePageQuery(Object(Role), Array) #2 [internal function]: Pages->___save(Object(Role), Array) #3 /Applications/MAMP/htdocs/ew/ProcessWire/wire/core/Wire.php(389): call_user_func_array(Array, Array) #4 /Applications/MAMP/htdocs/ew/ProcessWire/wire/core/Wire.php(344): Wire->runHooks('save', Array) #5 /Applications/MAMP/htdocs/ew/ProcessWire/wire/core/Page.php(1180): Wire->__call('save', Array) #6 /Applications/MAMP/htdocs/ew/ProcessWire/wire/core/Page.php(1180): Pages->save(Object(Role), Array) #7 /Applications/MAMP/htdocs/ew/ProcessWire/site/modules/ProcessBlog/BlogInstallWizard.php(324): Page->save() #8 /Applications/MAMP/htdocs/ew/ProcessWire/site/modules/ProcessBlog/BlogInstallWizard.php(304): BlogInstallWizard->createRole() #9 /Applications/MAMP/htdocs/ew/ProcessWire/site/modules/ProcessBlog/ProcessBlog.module(2847): BlogInstallWizard->verifyInstall(Object(InputfieldForm)) #10 /Applications/MAMP/htdocs/ew/ProcessWire/site/modules/ProcessBlog/ProcessBlog.module(677): ProcessBlog->installWizard(Object(InputfieldForm)) #11 /Applications/MAMP/htdocs/ew/ProcessWire/site/modules/ProcessBlog/ProcessBlog.module(715): ProcessBlog->firstAccess(Array) #12 /Applications/MAMP/htdocs/ew/ProcessWire/wire/core/ProcessController.php(204): ProcessBlog->execute() #13 [internal function]: ProcessController->___execute() #14 /Applications/MAMP/htdocs/ew/ProcessWire/wire/core/Wire.php(389): call_user_func_array(Array, Array) #15 /Applications/MAMP/htdocs/ew/ProcessWire/wire/core/Wire.php(344): Wire->runHooks('execute', Array) #16 /Applications/MAMP/htdocs/ew/ProcessWire/wire/core/admin.php(85): Wire->__call('execute', Array) #17 /Applications/MAMP/htdocs/ew/ProcessWire/wire/core/admin.php(85): ProcessController->execute() #18 /Applications/MAMP/htdocs/ew/ProcessWire/wire/modules/AdminTheme/AdminThemeDefault/controller.php(13): require('/Applications/M...') #19 /Applications/MAMP/htdocs/ew/ProcessWire/site/templates/admin.php(15): require('/Applications/M...') #20 /Applications/MAMP/htdocs/ew/ProcessWire/wire/core/TemplateFile.php(169): require('/Applications/M...') #21 [internal function]: TemplateFile->___render() #22 /Applications/MAMP/htdocs/ew/ProcessWire/wire/core/Wire.php(389): call_user_func_array(Array, Array) #23 /Applications/MAMP/htdocs/ew/ProcessWire/wire/core/Wire.php(344): Wire->runHooks('render', Array) #24 /Applications/MAMP/htdocs/ew/ProcessWire/wire/modules/PageRender.module(356): Wire->__call('render', Array) #25 /Applications/MAMP/htdocs/ew/ProcessWire/wire/modules/PageRender.module(356): TemplateFile->render() #26 [internal function]: PageRender->___renderPage(Object(HookEvent)) #27 /Applications/MAMP/htdocs/ew/ProcessWire/wire/core/Wire.php(389): call_user_func_array(Array, Array) #28 /Applications/MAMP/htdocs/ew/ProcessWire/wire/core/Wire.php(344): Wire->runHooks('renderPage', Array) #29 /Applications/MAMP/htdocs/ew/ProcessWire/wire/core/Wire.php(411): Wire->__call('renderPage', Array) #30 /Applications/MAMP/htdocs/ew/ProcessWire/wire/core/Wire.php(411): PageRender->renderPage(Object(HookEvent)) #31 /Applications/MAMP/htdocs/ew/ProcessWire/wire/core/Wire.php(344): Wire->runHooks('render', Array) #32 /Applications/MAMP/htdocs/ew/ProcessWire/wire/modules/Process/ProcessPageView.module(171): Wire->__call('render', Array) #33 /Applications/MAMP/htdocs/ew/ProcessWire/wire/modules/Process/ProcessPageView.module(171): Page->render() #34 [internal function]: ProcessPageView->___execute(true) #35 /Applications/MAMP/htdocs/ew/ProcessWire/wire/core/Wire.php(389): call_user_func_array(Array, Array) #36 /Applications/MAMP/htdocs/ew/ProcessWire/wire/core/Wire.php(344): Wire->runHooks('execute', Array) #37 /Applications/MAMP/htdocs/ew/ProcessWire/index.php(214): Wire->__call('execute', Array) #38 /Applications/MAMP/htdocs/ew/ProcessWire/index.php(214): ProcessPageView->execute(true) #39 {main}</pre>

Edited by kongondo
Gazley: I moved this here to Blog's support thread

Share this post


Link to post
Share on other sites

I reverted to backups of my development environment and the DB. I installed the Blog Module again, from scratch and got the following errors:

 TemplateFile: SQLSTATE[42S01]: Base table or view already exists: 1050 Table 'field_blog_categories' already exists<pre>#0 /Applications/MAMP/htdocs/ew/ProcessWire/wire/core/Fieldtype.php(440): PDOStatement->execute() #1 [internal function]: Fieldtype->___createField(Object(Field)) #2 /Applications/MAMP/htdocs/ew/ProcessWire/wire/core/Wire.php(389): call_user_func_array(Array, Array) #3 /Applications/MAMP/htdocs/ew/ProcessWire/wire/core/Wire.php(344): Wire->runHooks('createField', Array) #4 /Applications/MAMP/htdocs/ew/ProcessWire/wire/core/Fields.php(207): Wire->__call('createField', Array) #5 /Applications/MAMP/htdocs/ew/ProcessWire/wire/core/Fields.php(207): FieldtypePage->createField(Object(Field)) #6 [internal function]: Fields->___save(Object(Field)) #7 /Applications/MAMP/htdocs/ew/ProcessWire/wire/core/Wire.php(389): call_user_func_array(Array, Array) #8 /Applications/MAMP/htdocs/ew/ProcessWire/wire/core/Wire.php(344): Wire->runHooks('save', Array) #9 /Applications/MAMP/htdocs/ew/ProcessWire/wire/core/Field.php(392): Wire->__call('save', Array) #10 /Applications/MAMP/htdocs/ew/ProcessWire/wire/core/Field.php(392): Fields->save(Object(Field)) #11 /Applications/MAMP/htdocs/ew/ProcessWire/site/modules/ProcessBlog/BlogInstallWizard.php(436): Field->save() #12 /Applications/MAMP/htdocs/ew/ProcessWire/site/modules/ProcessBlog/BlogInstallWizard.php(334): BlogInstallWizard->createFields() #13 /Applications/MAMP/htdocs/ew/ProcessWire/site/modules/ProcessBlog/BlogInstallWizard.php(304): BlogInstallWizard->createRole() #14 /Applications/MAMP/htdocs/ew/ProcessWire/site/modules/ProcessBlog/ProcessBlog.module(2847): BlogInstallWizard->verifyInstall(Object(InputfieldForm)) #15 /Applications/MAMP/htdocs/ew/ProcessWire/site/modules/ProcessBlog/ProcessBlog.module(677): ProcessBlog->installWizard(Object(InputfieldForm)) #16 /Applications/MAMP/htdocs/ew/ProcessWire/site/modules/ProcessBlog/ProcessBlog.module(715): ProcessBlog->firstAccess(Array) #17 /Applications/MAMP/htdocs/ew/ProcessWire/wire/core/ProcessController.php(204): ProcessBlog->execute() #18 [internal function]: ProcessController->___execute() #19 /Applications/MAMP/htdocs/ew/ProcessWire/wire/core/Wire.php(389): call_user_func_array(Array, Array) #20 /Applications/MAMP/htdocs/ew/ProcessWire/wire/core/Wire.php(344): Wire->runHooks('execute', Array) #21 /Applications/MAMP/htdocs/ew/ProcessWire/wire/core/admin.php(85): Wire->__call('execute', Array) #22 /Applications/MAMP/htdocs/ew/ProcessWire/wire/core/admin.php(85): ProcessController->execute() #23 /Applications/MAMP/htdocs/ew/ProcessWire/wire/modules/AdminTheme/AdminThemeDefault/controller.php(13): require('/Applications/M...') #24 /Applications/MAMP/htdocs/ew/ProcessWire/site/templates/admin.php(15): require('/Applications/M...') #25 /Applications/MAMP/htdocs/ew/ProcessWire/wire/core/TemplateFile.php(169): require('/Applications/M...') #26 [internal function]: TemplateFile->___render() #27 /Applications/MAMP/htdocs/ew/ProcessWire/wire/core/Wire.php(389): call_user_func_array(Array, Array) #28 /Applications/MAMP/htdocs/ew/ProcessWire/wire/core/Wire.php(344): Wire->runHooks('render', Array) #29 /Applications/MAMP/htdocs/ew/ProcessWire/wire/modules/PageRender.module(356): Wire->__call('render', Array) #30 /Applications/MAMP/htdocs/ew/ProcessWire/wire/modules/PageRender.module(356): TemplateFile->render() #31 [internal function]: PageRender->___renderPage(Object(HookEvent)) #32 /Applications/MAMP/htdocs/ew/ProcessWire/wire/core/Wire.php(389): call_user_func_array(Array, Array) #33 /Applications/MAMP/htdocs/ew/ProcessWire/wire/core/Wire.php(344): Wire->runHooks('renderPage', Array) #34 /Applications/MAMP/htdocs/ew/ProcessWire/wire/core/Wire.php(411): Wire->__call('renderPage', Array) #35 /Applications/MAMP/htdocs/ew/ProcessWire/wire/core/Wire.php(411): PageRender->renderPage(Object(HookEvent)) #36 /Applications/MAMP/htdocs/ew/ProcessWire/wire/core/Wire.php(344): Wire->runHooks('render', Array) #37 /Applications/MAMP/htdocs/ew/ProcessWire/wire/modules/Process/ProcessPageView.module(171): Wire->__call('render', Array) #38 /Applications/MAMP/htdocs/ew/ProcessWire/wire/modules/Process/ProcessPageView.module(171): Page->render() #39 [internal function]: ProcessPageView->___execute(true) #40 /Applications/MAMP/htdocs/ew/ProcessWire/wire/core/Wire.php(389): call_user_func_array(Array, Array) #41 /Applications/MAMP/htdocs/ew/ProcessWire/wire/core/Wire.php(344): Wire->runHooks('execute', Array) #42 /Applications/MAMP/htdocs/ew/ProcessWire/index.php(214): Wire->__call('execute', Array) #43 /Applications/MAMP/htdocs/ew/ProcessWire/index.php(214): ProcessPageView->execute(true) #44 {main}</pre>

Share this post


Link to post
Share on other sites

Gazley,

I am not sure what version of blog you are using but I know that kongondo made some relatively recent changes to help with clean up of pages when uninstalling. But it sounds like you might need to do some cleanup anyway at this point. 

Did you use the PW backup module to do your backup and restore? Unfortunately there is a bit of a limitation with that backup module at the moment in that it doesn't start with a blank DB when restoring so you can get that situation with existing tables.

At this point I would suggest uninstalling the blog again and then manually removing the DB tables - all that start with "field_blog_*". Also check to make sure there is no entry for the blog module in the "modules" DB table.

Hopefully with a clean start it should install fine.

  • Like 1

Share this post


Link to post
Share on other sites

@Peter,

The select box is coming from the 4th argument of renderNav() $mobile. The default value is 'true'. Used in conjunction with CSS @media queries, the select box provides an easier navigation of your Blog for mobile devices. If you wish not to use it, just set $mobile=false. See below:

renderNav() tutorial - I'll need to update this to be more explicit about this feature.. :-)

renderNav() code

use with media queries example in blog.css demo file

  • Like 1

Share this post


Link to post
Share on other sites

@Gazley,

Thanks for trying out Blog. Nothing much to add to what Adrian has said. I can tell that you are using Blog version 2.x.x. As the error shows, it seems you installed Blog, then uninstalled it without first 'cleaning up', then tried to install it again. That's the only way that error could occur based on your explanation... :-)

Let us know if we can help further.. :-)

Edited by kongondo

Share this post


Link to post
Share on other sites

@Peter,

The select box is coming from the 4th argument of renderNav() $mobile. The default value is 'true'. Used in conjunction with CSS @media queries, the select box provides an easier navigation of your Blog for mobile devices. If you wish not to use it, just set $mobile=false. See below:

renderNav() tutorial - I'll need to update this to be more explicit about this feature.. :-)

renderNav() code

use with media queries example in blog.css demo file

Thanks a mill. For what it's worth, I found your blog docs yesterday. Missed that particular setting but self-fixed another issue :)

Share this post


Link to post
Share on other sites

Actually I PM'ed you about the 'problem' on 5 November  :P. Found out about Blog docs only yesterday?! I need to up my game! :lol:

  • Like 1

Share this post


Link to post
Share on other sites

Sorry Kongondo. Must have missed the notification and I see you've replied to something else too. Will pickup on the PM channel.

Share this post


Link to post
Share on other sites

Hi,

I installed it once and hit the error. I manually uninstalled it and tried again and hit the error. As a result, I reverted to a backup from days ago, before I even downloaded the Blog module. I installed clean and still hit the error presented in my second error listing.

I haven't installed and uninstalled or anything like that. I just hit the error right away.

Share this post


Link to post
Share on other sites

Well that's strange. Can you please confirm:

  • That you run the 'Cleanup' wizard before uninstalling the module itself?
  • That after uninstall you do not have a field called blog_categories in your install/DB?
  • That the uninstaller finished running - i.e. it did not hang and not complete?
  • Your PW version? 

Share this post


Link to post
Share on other sites

Hi Kongondo,

I've resolved the issue and this was the problem:

xdebug.max_nesting_level=100

I use Xdebug and your installation had originally crashed because the PHP program nesting level had hit this limit. I've no idea why this Xdebug setting should impact on PHP when not debugging but for whatever reason, it was. I extended this to 200 and voila - it installed just fine! :)

I couldn't ever run Cleanup because it never (I presume) got far enough along in the install before it crashed due to the nesting limit. In any event, I reverted to backup (again) with the higher nesting limit and it all functioned perfectly!

Now, all I have to do is learn to use the MarkupBlog module :)

Anyway, thanks for being calm and patient and making this work available. The dashboard and utilities look really great and I'm glad I don't have to code up another half-baked, home-made blog yet again!

Cheers. 

  • Like 1

Share this post


Link to post
Share on other sites

Glad you got it sorted. Now that I think about it, this nesting level issue has come up before in respect of installing Blog. 

MarkupBlog docs are on my site here:

I will need to update them soon with the latest changes as shown on post #207 and #244 here in the forums which you might want to read as well.

  • Like 1

Share this post


Link to post
Share on other sites

When i create a user with roles guest and blog-author, as soon they log in to the manager the only thing shown is a continue link, redirecting them to the home page of the site.

How can they create a new blog entry? I do not want to give them superuser privileges.

I'm running PW 2.5.10 dev with ProcessBlog 2.3.0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By Gadgetto
      SnipWire - Snipcart integration for ProcessWire
      Snipcart is a powerful 3rd party, developer-first HTML/JavaScript shopping cart platform. SnipWire is the missing link between Snipcart and the content management framework ProcessWire.
      With SnipWire, you can quickly turn any ProcessWire site into a Snipcart online shop. The SnipWire plugin helps you to get your store up and running in no time. Detailed knowledge of the Snipcart system is not required.
      SnipWire is free and open source licensed under Mozilla Public License 2.0! A lot of work and effort has gone into development. It would be nice if you could donate an amount to support further development:

      Status update links (inside this thread) for SnipWire development
      2020-04-06 -- SnipWire 0.8.6 (beta) released! Adds support for Snipcart subscriptions and also fixes some problems 2020-03-21 -- SnipWire 0.8.5 (beta) released! Improves SnipWires webhooks interface and provides some other fixes and additions 2020-03-03 -- SnipWire 0.8.4 (beta) released! Improves compatibility for Windows based Systems. 2020-03-01 -- SnipWire 0.8.3 (beta) released! The installation and uninstallation process has been heavily revised. 2020-02-08 -- SnipWire 0.8.2 (beta) released! Added a feature to change the cart and catalogue currency by GET, POST or SESSION param 2020-02-03 -- SnipWire 0.8.1 (beta) released! All custom classes moved into their own namespaces. 2020-02-01 -- SnipWire is now available via ProcessWire's module directory! 2020-01-30 -- SnipWire 0.8.0 (beta) first public release! (module just submitted to the PW modules directory) 2020-01-28 -- added Custom Order Fields feature (first SnipWire release version is near!) 2020-01-21 -- Snipcart v3 - when will the new cart system be implemented? 2020-01-19 -- integrated taxes provider finished (+ very flexible shipping taxes handling) 2020-01-14 -- new date range picker, discount editor, order notifiactions, order statuses, and more ... 2019-11-15 -- orders filter, order details, download + resend invoices, refunds 2019-10-18 -- list filters, REST API improvements, new docs platform, and more ... 2019-08-08 -- dashboard interface, currency selector, managing Orders, Customers and Products, Added a WireTabs, refinded caching behavior 2019-06-15 -- taxes provider, shop templates update, multiCURL implementation, and more ... 2019-06-02 -- FieldtypeSnipWireTaxSelector 2019-05-25 -- SnipWire will be free and open source Plugin Key Features
      Fast and simple store setup Full integration of the Snipcart dashboard into the ProcessWire backend (no need to leave the ProcessWire admin area) Browse and manage orders, customers, discounts, abandoned carts, and more Multi currency support Custom order and cart fields Process refunds and send customer notifications from within the ProcessWire backend Process Abandoned Carts + sending messages to customers from within the ProcessWire backend Complete Snipcart webhooks integration (all events are hookable via ProcessWire hooks) Integrated taxes provider (which is more flexible then Snipcart own provider) Useful Links
      SnipWire in PW modules directory SnipWire Docs (please note that the documentation is a work in progress) SnipWire @GitHub (feature requests and suggestions for improvement are welcome - I also accept pull requests) Snipcart Website  
      ---- INITIAL POST FROM 2019-05-25 ----
       
    • By bernhard
      #######################
      Please use the new RockFinder2
      #######################
      WHY?
      This module was built to fill the gap between simple $pages->find() operations and complex SQL queries.
      The problem with $pages->find() is that it loads all pages into memory and that can be a problem when querying multiple thousands of pages. Even $pages->findMany() loads all pages into memory and therefore is a lot slower than regular SQL.
      The problem with SQL on the other hand is, that the queries are quite complex to build. All fields are separate tables, some repeatable fields use multiple rows for their content that belong to only one single page, you always need to check for the page status (which is not necessary on regular find() operations and therefore nobody is used to that).
      In short: It is far too much work to efficiently and easily get an array of data based on PW pages and fields and I need that a lot for my RockGrid module to build all kinds of tabular data.

      Basic Usage

       
      Docs & Download
      https://modules.processwire.com/modules/rock-finder/
      https://github.com/BernhardBaumrock/RockFinder
       
      Changelog
      180817, v1.0.6, support for joining multiple finders 180810, v1.0.5, basic support for options fields 180528, v1.0.4, add custom select statement option 180516, change sql query method, bump version to 1.0.0 180515, multilang bugfix 180513, beta release <180513, preview/discussion took place here: https://processwire.com/talk/topic/18983-rocksqlfinder-highly-efficient-and-flexible-sql-finder-module/
    • By MoritzLost
      TrelloWire
      This is a module that allows you to automatically create Trello cards for ProcessWire pages and update them when the pages are updated. This allows you to setup connected workflows. Card properties and change handling behaviour can be customized through the extensive module configuration. Every action the module performs is hookable, so you can modify when and how cards are created as much as you need to. The module also contains an API-component that makes it easy to make requests to the Trello API and build your own connected ProcessWire-Trello workflows.
      Features
      All the things the module can do for you without any custom code: Create a new card on Trello whenever a page is added or published (you can select applicable templates). Configure the target board, target list, name and description for new cards. Add default labels and checklists to the card. Update the card whenever the page is updated (optional). When the status of the card changes (published / unpublished, hidden / unhidden, trashed / restored or deleted), move the card to a different list or archive or delete it (configurable). You can extend this through hooks in many ways: Modifiy when and how cards are created. Modify the card properties (Target board & list, title, description, et c.) before they are sent to Trello. Create your own workflows by utilizing an API helper class with many convenient utility methods to access the Trello API directly. Feedback & Future Plans
      Let me know what you think! In particular:
      If you find any bugs report them here or on Github, I'll try to fix them. This module was born out of a use-case for a client project where we manage new form submissions through Trello. I'm not sure how many use-cases there are for this module. If you do use it, tell me about it! The Trello API is pretty extensive, I'll try to add some more helper methods to the TrelloWireApi class (let me know if you need anything in particular). I'll think about how the module can support different workflows that include Twig – talk to me if you have a use-case! Next steps could be a dashboard to manage pages that are connected to a Trello card, or a new section in the settings tab to manage the Trello connection. But it depends on whether there is any interest in this 🙂 Links
      Repository on Github Complete module documentation (getting started, configuration & API documentation) [Module directory pending approval] Module configuration

    • By MoritzLost
      Process Cache Control
      This module provides a simple solution to clearing all your cache layers at once, and an extensible interface to perform various cache-related actions.
      The simple motivation behind this module was that I was tired of manually clearing caches in several places after deploying a change on a live site. The basic purpose of this module is a simple Clear all caches link in the Setup menu which clears out all caches, no matter where they hide. You can customize what exactly the module does through it's configuration menu:
      Expire or delete all cache entries in the database, or selectively clear caches by namespace ($cache API) Clear the the template render cache. Clear out specific folders inside your site's cache directory (/site/assets/cache) Clear the ProCache page render cache (if your site is using ProCache) Refresh version strings for static assets to bust client-side browser caches (this requires some setup, see the full documentation for details). This is the basic function of the module. However, you can also add different cache management action through the API and execute them through the module's interface. For this advanced usage, the module provides:
      An interface to see all available cache actions and execute them. A system log and logging output on the module page to see verify what the module is doing. A CacheControlTools class with utility functions to clear out different caches. An API to add cache actions, execute them programmatically and even modify the default action. Permission management, allowing you granular control over which user roles can execute which actions. The complete documentation can be found in the module's README.
      Plans for improvements
      If there is some interest in this, I plan to expand this to a more general cache management solution. I particular, I would like to add additional cache actions. Some ideas that came to mind:
      Warming up the template render cache for publicly accessible pages. Removing all active user sessions. Let me know if you have more suggestions!
      Links
      https://github.com/MoritzLost/ProcessCacheControl ProcessCacheControl in the Module directory CHANGELOG in the repository Screenshots


    • By Macrura
      PrevNextTabs Module
      Github: https://github.com/outflux3/PrevNextTabs
      Processwire helper modules for adding page navigation within the editor.
      Overview
      This is a very simple module that adds Previous and Next links inline with the tabs on the page editor. Hovering over the tab shows the title of the previous or next page (using the admin's built in jqueryUI tooltips.)
      Usage
      This module is typically used during development where you or your editors need to traverse through pages for the purpose of proofing, flagging and/or commenting. Rather than returning to the page tree or lister, they can navigate with these links.
      Warnings
      If you are using PW version 2.6.1 or later, the system will prevent you from leaving the page if you have unsaved edits.
      For earlier versions, to avoid accidentally losing changes made to a page that might occur if a user accidentally clicks on one of these, make sure to have the Form Save Reminder module installed.
      http://modules.processwire.com/modules/prev-next-tabs/
×
×
  • Create New...