Jump to content

ceberlin

Members
  • Posts

    533
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by ceberlin

  1. I think too, that actually a general maintenance module would be great.

    There are some maintenance tips and pieces spread over this forum. About cleaning unneeded assets dirs, and so on, cleaning up databases, there even is some extendable monitoring + maintenance module already there - without much functionality yet, but anyway.

    (For WordPress there is a modle that can force rebuilding image variations/thumbs. I found that useful in some situations. I am missing this sort of technology here, too.)

    some examples:

    https://processwire.com/talk/topic/4437-delete-orphaned-filesimages-from-siteassetsfiles/

    https://processwire.com/talk/topic/9383-search-and-replace/?hl=search

    http://modules.processwire.com/modules/process-diagnostics/ (can cleanup databases)

    • Like 4
  2. Now it is possible to uninstall the PageLinkAbstractor" (if using PW 2.6 and newer, this is a good idea) without ending with broken internal links.

    Please follow those hints on GitHub - there is a useful code snippet by Ryan Cramer:

    https://github.com/ryancramerdesign/ProcessWire/issues/1283

    In my cases the provided script did not catch every single link, but most of them - the few remaining could be searched for with a 404 Link Checker Tool and then repaired manually.

    • Like 1
  3. A conversation from the GITHUB issues which I thought to be useful to have in this Forum's knowledge base.

    Ryan Cramer put some valuable information there, which should be searchable in this forum, i.m.h.o.

    My Summary:

    Use the "autojoin" option on pagefield (when allowing multiple pages) with care. 

    There could be unwanted side effects especially if you use more than one of these fields with that setup on a single template.

    Original conversation:

    tbba asked:

    I have 2 page fields (one is the clone of the other - so they are unique apart from the name).

    Both are used on a template.
    The first field DOES remember the (dragged) sort order of the pages, the second does NOT.

    Has anyone else have the problem too?
    Is this a cache problem, or corrupt indexes?

    PW latest dev / php 5.6 fastcgi / Safari+Firefox

    Update: If I change the display order of those 2 fields in the template, both fields behave the opposite:
    So the first (whatever the first field is in the template when editing the page) always WORKS the second NOT. (The 2nd field lets me still adding or deleting a page - just the order is corrupt there.)

     

    Update: On localhost everything works (same php version but has opcache off in MAMP - maybe this info is important)

    Update: If I switch "autojoin" off for those page fields, everything works everywhere. 
    This is my workaround for now.

    (I remember that "autojoin" has been a problem for me with page fields already in much earlier versions of PW on many sites so it is not a temporary phenomena.)

    ryancramerdesign commented

    If you need to retain a sort order, you'd only want to autojoin one of the page fields. Autojoin causes everything to be loaded in one query, and there can't be two different sorted result sets included in that query as far as I know. Though it's interesting it works on your localhost and not on the other server. There are some MySQL versions known to have issues with sorting and certain queries, and you may be hitting up against that on one server and not the other. Though I can definitely see how auto joining two Page fields in one query would pose challenges to retaining the sort order. So in either case, I would limit your autojoin to just one Page field, or simply not use Autojoin for page fields at all. There's not a major benefit in doing so.  

    tbba commented

    MYSQL on the live server is 5.6 and on localhost/MAMP it is still 5.5.

    I am very glad you can confirm that this issue is not a phantom of a defect system and can be 100% nailed down to "Autojoin". 

    I used Autojoin under the assumption that it indexes a field and makes certain searches (menu building) quicker. (Since the new cache options, I am not worried with speed on certain searches any more.)

    If Autojoin has, in the best case, no "major" effect with page fields and in the worst case totally confuses the system, why is the option nor switched off and deactivated for this field type? 

    Is Autojoin only bad for page arrays or even if the page field is set to accept only one page? 
    Are there other fields that also have a problem with "Autojoin"?

    (I must say this "mystery bug" - which sometimes happens and sometimes not - was quite a debugging nightmare and other users should be warned/hindered to set-up such a combination, i.m.h.o.)

    ryancramerdesign commented

    I am very glad you can confirm that this issue is not a phantom of a defect system and can be 100% nailed down to "Autojoin".

     

    Actually I can't nail it down to autojoin, but outside of using it with a simple text or number field, autojoin is an advanced option that can be affected by a lot of different factors. It's one of those things we suggest using when you find it helps, and don't use when you find it interferes. When you autojoin a multi-value field, MySQL is performing what's called a group_concat, and is at the mercy of certain MySQL memory buffers and configuration settings. It's very possible you are hitting up against that too, which is made all the more likely by auto joining two multi-value fields. That would explain why you see it on one server and not another.

    I used Autojoin under the assumption that it indexes a field and makes certain searches (menu building) quicker. (Since the new cache options, I am not worried with speed on certain searches any more.)

    It can make things quicker but it can also slow them down. It really depends on the case. The only way to tell for certain in a given instance is by testing and timing it. I do know for certain that auto-joining one or two text fields (like title and summary, for example) does provide a performance benefit to large navigation lists that use the autojoined fields, though not likely one that you would feel unless loading hundreds of thousands of pages. 

    If Autojoin has, in the best case, no "major" effect with page fields and in the worst case totally confuses the system, why is the option nor switched off and deactivated for this field type? 

    Because it is an advanced option that may be beneficial. If auto joining one multi-value field, like a small list of category page references, you may find it beneficial when outputting a 100 item navigation list. Or you may not. It really does come down to installation specific configuration, so it's one of those things you want to test when you use it to make sure it's working and worthwhile for your case. I wouldn't want to disable the option for this Fieldtype, because I think it can be worthwhile. But it's on the advanced tab for a reason. 

    Is Autojoin only bad for page arrays or even if the page field is set to accept only one page? 
    Are there other fields that also have a problem with "Autojoin"?

    Autojoin should be fine for Page fields, especially single page fields. What I would avoid is giving several multi-value Page fields autojoin on the same template. You are more likely to run into issues there, but again, the only way to know for certain if it's going to be an issue on your installation is to test it. If you need something guaranteed to be portable across systems, then limit autojoin use to single-value text fields and such. Any multi-value Fieldtype has potential to run into installation-specific limits that could cause issues, so always treat it as an advanced option and test.

    • Like 4
  4. The good thing of having it here intead of GitHub is that there could be it's own fine grained system for flagging, like in a project management system, so the people know the current status and where a voting would have an effect. 

    - planned for this dev version cycle

    - panned for after next mayor update

    - Maybe sometimes

    - Not currently planned

    - Not planned (never)

    - Done/Closed (hidden?)

    (Maybe closed/done requests could be hidden and only shown on request)

    Just thinking...

    • Like 3
  5. Hi, after looking at the 300 open "issues" on Github, it turns out that a lot of them, including some of mine, are labeled "enhancement" / "feature request".

    To get the increasing number of issues down there (which might give a wrong impression on how well maintained PW is), and to do sort of a cleanup I was planning to set all of my "issues" which are labeled "enhancement"/"feature request" as closed.

    I am assuming that the idea was either good enough and had been recognized for an enhancement consideration and thus stored in a to-do list somewhere else, or the the idea was not good enough and did not survive.

    In either case, an "issue" like this,does not need to be open forever, imho. Is closing it the best way to deal with it - or should we leave the step to Ryan (or anyone maintaining this)?

    (Also there are many "fixed" / "completed" issues that could be closed eventually.)

    • Like 6
  6. Version 2 is online now, after client agreed to the extra features. :-)

    • Now is fully responsive
    • Some fancy effects built in
    • Adobe Edge player interacting withPW
    • a separate, reduced English version (because the English clients have different demands)
    • a iphone alternate mobile version (German only) which only present the essential information
    • using the fancy new pro forms and the new pro cache.
  7. Hi Mike, the 404 log starts showing lots of request from Google starting like so:

    index.php.pwpj/…

    I think the "pwpj" extension is from this module. I have no clue how this fake extension(?) made its way into Google, what the reason is for it, and how to handle it when creating a jumplink.

    Can you update the documentation to give a litte insight?

    And by the way, a feature request: Is it possible to set a "410 gone" also?

    I have a bunch of links to non-existing images that I do not plan to redirect.

  8. Ok I tried this:

    go to Users/roles and make a note what was set there for the fields with a permission,

    set those same permissions in the new field settings for each field

    delete the permission entries from Users/Permissions

    and finally uninstall the old module

    • Like 1
  9. I love the new Field Rights Feature in the core. Thank you very much.

    I would like to migrate older installations, which use the Page Edit Field Permission Module with some fields. From what I think the new core is 100% replacing that module's features.

    How does the new core plays with the module and what is the best way to migrate? Just uninstalling the module and update the field settings in question?

    Or would a simple uninstalling of that module leave unclear rights settings remaining somewere in the system?

  10. @alan I run PW also with CodeKit and MAMP PRO and I am using an extra long very unique extension: ".tbadev" (6 chars). Have you tried something different than ".local" ?

    Maybe "local" is reserved and conflicting with something else on the Mac (maybe Bonjour)?

    • Like 1
  11. There is a small glitch with the version number that leads to a version mismatch in ModuleManager, which interprets it as 0.0.2 and 2.0 and permanently wants me to update. I am not a module coder but I think that 

     'version' => 200, 

    would fix this.

    • Like 2
  12. Since I discovered PageTableExtended I love PageTable. Now I can give editors the possibility to assemble new content from "building block" elements. That makes my setup very flexible.

    With the growing number of edits, things start to become messy and I am thinking of clean-up strategies

     
    A. Storing blocks at a central location
    I chose the option to store all blocks at a central location. Because having the blocks stored in the page tree makes the page tree messy.
     
    Now after having set 15 pages with approx. 3-5 PageTable pages each, I already ended up with abt. 280 PageTable pages. A lot of them are unpublished.
     
    Questions:
    1. Is it possible to identify the related parents to PageTable-Page easily, so I can sort out those with none?
    2. Is it possible to clean up the not needed PageTable pages automatically (which not linked to a PageTable field somewhere)?
     
    B. Storing blocks with the page that holds the PageTable field?
    If I would love to use the alternative option to store PageTable pages with a page instead (which has benefits):
     
    Questions:
    1. Is it possible to make those  items optionally hidden in the PageTree? So they do not get mixed with real children-pages (which would look messy and be confusing for editors)?
    2. Is it easy to switch the storage option in the PageTree module settings without making a lot of mess?
  13. In the context of dates, what I really would find useful, is a date for the latest hit.

    So I could, after a period of time, delete those redirects, which had no hits since that period, so those links don't seem to matter any more. That helps to keep my list short. :-)

  14. Tonight I restored the database to get JumpLinks back and tried a bit further.

    To get some traffic on the site, I used a dead link checker with some threats (not to many) to challenge it. Then the trouble started.

    The problem I got indicated an unnormal behavior like a loop. Too many requests.

    I found out that it is not the links.

    I had an entry in the module's Legacy Domain field. Example: http://domain.de/drupal/.

    There might have been a loop, maybe simply because the new site is https://domain.de only.

    Or there is some other problem with that field (or a misunderstanding from my side, what it does).

    Removing that entry (I forgot about that entry this morning - since the field is always collapsed) cured the issue, I think.

    Site and server are up to speed, regardless of running the link-checker again.

  15. I actually had to uninstall the module - it was causing excessive mysql database connections (not usage) and my webserver nearly stalled.

    Maybe I run into a loop or something?

    I was redirecting from an old Drupal website to PW and used about 70 simple type redirects, such as sources  /drupal/page1/   

    Got this (on the latest PW dev)

    Error:

    Exception: SQLSTATE[HY000]: General error: 1116 Too many tables; MySQL can only use 61 tables in a join (in /wire/core/PageFinder.php line 300)

    Error:

    Exception: DB connect error 1203 - User already has more than 'max_user_connections' active connections (in /wire/core/Database.php line 68)

    I cannot say 100% that this was Jumplinks. I just noted that the performance was back to normal after I uninstalled the module.

    So this is just for information in case anyone else can confirm this.

  16. I use Apple Safari, PW latest dev:

     
    I find it tricky at times using the pagetable field.
     
    When a modal opens with the "child" page, the modal itself is scrollable and can easily scroll out of view. (The window should not be scrollabe, if the modal is open. I think.)
     
    Inside of the modal there is the page which is scollabe and inside of that are CKE fields which are also scrollable. That is not easily manageable, there's not much space then, the CKE menu is out if focus quickly and if I scroll up to fast, Safari shows that bounce effect and scrolls the outer scrollable elements up too and I end with a black modal content.
     
    Now I have a site where I have to put in very long texts with many images from an images field below the CKE field. That means scolling and scrolling and navigation is very distracting. The maximize button in CKE does not really help.
     
    I just finished a couple of Wordpress pages and in that respect it was much easier to handle. Choose maximize and use the full screen, not a scrollable box in a scrollable box in a scrollable box.
     
    What do you think?
  17. Yes, confusing and not how things should be, I agree. :-)

    What I did (somewhere in that workflow the trouble started):

    1. installing with ModuleManager, as usual -> did not work. Showed no error but acted as if I never had tried and still offered the "download" link (instead of "install" or "edit").

    2. Read in the forum that a manual installation was needed. -> that did not work because the previous attempt left something in the database.

    3. Deleted that info from the database -> now the manual installation worked successfully.

    -> The module works fine now and I am very happy about it.

×
×
  • Create New...