Posts by stefanyoungs

    Since installing Sonoma, the Redactor edit menu no longer works for Bold or Italic using Safari or Chrome browser. Works fine in Firefox. Any ideas?

    Perch: 3.1.7,

    More granular control over the Roles function. At a minimum we need to assign an Editor to be able to access ONLY pages he/she has created.


    we have several editors around the world creating content and our nightmare scenario is where someone modifies or deletes content created by someone else. If we could restrict this, we could have more content creators beavering away.


    we would like an editor to only see the pages he/she created… we have over 5000 pages on our site, which makes finding the one you are looking for more difficult than it should be

    Thanks. It's a shame the documentation is in many cases neither clear nor comprehensive enough for the average user to be able to use reliably. Here's hoping the new owners will adopt a more embracing attitude towards providing directly usable information for the averagely technical person.

    We are trying to change the way our Perch 3 installation handles Assets which are not being used.


    Currently the box 'Mark as library asset' is ticked for every new asset entered. We want the default to NOT have the box ticked.


    Looking at the config.php file I see this:


    <?php define('PERCH_LICENSE_KEY', 'xxxxxxxxxxxx'); switch($_SERVER['SERVER_NAME']) { case 'aircrew-remembered.test':

    include(__DIR__.'/config.local.php');

    break; default:

    include('config.production.php');

    break;

    } define('PERCH_EMAIL_FROM', 'xxxxxxxxxx');

    define('PERCH_EMAIL_FROM_NAME', 'Stefan Youngs'); define('PERCH_LOGINPATH', '/editorial');

    define('PERCH_PATH', str_replace(DIRECTORY_SEPARATOR.'config', '', dirname(__FILE__)));

    define('PERCH_CORE', PERCH_PATH.DIRECTORY_SEPARATOR.'core'); define('PERCH_RESFILEPATH', PERCH_PATH . DIRECTORY_SEPARATOR . 'resources');

    define('PERCH_RESPATH', PERCH_LOGINPATH . '/resources');    


    define('PERCH_HTML5', true);

    define('PERCH_CLEAN_RESOURCES', false);  


    define('PERCH_DEFAULT_EXT', '.html');

    define('PERCH_CUSTOM_EDITOR_CONFIGS', true);

    ?>


    Is our problem at define('PERCH_CLEAN_RESOURCES', false); ?


    Should I make that define('PERCH_CLEAN_RESOURCES', true); ?? (edited)

    After years of successful creation and editing, we now see this every time we attempt to edit a page


    Above our Content

    Warning: Invalid argument supplied for foreach() in /home4/kelstef/public_html/editorial/core/apps/content/modes/edit.form.pre.php on line 119



    Warning: Cannot modify header information - headers already sent by (output started at /home4/kelstef/public_html/editorial/core/apps/content/modes/edit.form.pre.php:119) in /home4/kelstef/public_html/editorial/core/lib/PerchUtil.class.php on line 1405



    Warning: Cannot modify header information - headers already sent by (output started at /home4/kelstef/public_html/editorial/core/apps/content/modes/edit.form.pre.php:119) in /home4/kelstef/public_html/editorial/core/lib/PerchUtil.class.php on line 1406



    Warning: Cannot modify header information - headers already sent by (output started at /home4/kelstef/public_html/editorial/core/apps/content/modes/edit.form.pre.php:119) in /home4/kelstef/public_html/editorial/core/lib/PerchUtil.class.php on line 1407



    Warning: Cannot modify header information - headers already sent by (output started at /home4/kelstef/public_html/editorial/core/apps/content/modes/edit.form.pre.php:119) in /home4/kelstef/public_html/editorial/core/lib/PerchUtil.class.php on line 1415



    Warning: Cannot modify header information - headers already sent by (output started at /home4/kelstef/public_html/editorial/core/apps/content/modes/edit.form.pre.php:119) in /home4/kelstef/public_html/editorial/core/inc/top.php on line 17


    Immediately below The Regions Headline Regiions Options menu



    Warning: Invalid argument supplied for foreach() in /home4/kelstef/public_html/editorial/core/apps/content/modes/edit.form.post.php on line 165


    Our info


    • PHP 5.4.45 version is okay, but a little out of date. Consider updating soon.
    • MySQL 5.6.41-84.1 is up to date
    • Image processing available

    Summary information

    • Perch: 3.1.5, PHP: 5.4.45, MySQL: 5.6.41-84.1, with PDO
    • Server OS: Linux, cgi-fcgi
    • Installed apps: content (3.1.5), assets (3.1.5), categories (3.1.5), perch_comments (1.0.1)
    • App runtimes: <?php $apps_list = [];
    • PERCH_LOGINPATH: /editorial
    • PERCH_PATH: /home4/kelstef/public_html/editorial
    • PERCH_CORE: /home4/kelstef/public_html/editorial/core
    • PERCH_RESFILEPATH: /home4/kelstef/public_html/editorial/resources
    • Image manipulation: GD Imagick
    • PHP limits: Max upload 256M, Max POST 260M, Memory: 256M, Total max file upload: 256M
    • F1: 3b606135b33e6a102526838f4152a807
    • Resource folder writeable: Yes
    • DOCUMENT_ROOT: /home4/kelstef/public_html
    • HTTP_HOST: aircrewremembered.com
    • REQUEST_URI: /editorial/core/settings/diagnostics/
    • SCRIPT_NAME: /editorial/core/settings/diagnostics/index.php


    Any ideas of the problem?


    The only difference I can think of is we were forced to implement Cloudflare to eliminate a Denial of Service attack which was flooding our hosting service. Cloudflare routes all requests via their servers before the customer can reach our site.

    We've found the Navigation feature extremely useful in automatically creating Lists for our content. When we examine our user behaviour in various Analytics we see many users going to our cross-reference lists rather than using the Search option we provide. We've currently got 34 individual Cross Reference Lists driven off a 'Master' reference list


    http://aircrewremembered.com/lists-to-explore.html


    As a page is created it is assigned one or more Navigation Group(s) by the Editor and Perch then adds it to the correct Cross Reference List(s) automatically. It's a thing of beauty for a site with many hundreds of pages.

    When we first came to Perch Version 1, one of the aspects that attracted us was that Perch would generate php content but allow it to be suffixed .html There was an instruction in the Docs at the time telling us how to get Perch to suffix our pages .html and not .php, though I can't find that instruction today.


    This was (and remains) a big deal for us. Back then we already had 250+ non-Perch legacy pages which were all suffixed .html of course. The idea of new content being suffixed .php simply would have driven our readers nuts.


    So big kudos to Perch for allowing all our pages to be .html


    We followed the instructions for making Master Pages and these were all created with .html suffix at the time.


    So now we have maybe 2000 pages created in Perch, all using about 15 Master Pages suffixed .html


    Thus:


    php include(str_replace('/', DIRECTORY_SEPARATOR, 'editorial/templates/pages/LossTemplateAncient.html')); ( where LossTemplateAncient.html is a Master Page)


    All went swimmingly till about 3 years ago when suddenly we were unable to create new Master Pages. I raised this in the forums but no progress was made and we have just made do with the Master Pages we had in existence.


    But now we do need new Master Pages. Our experienced developer-friend confirmed that .html Master Pages were not making themselves visible in Perch on our system, but when he tried the same Master Page but suffixed it .php then it appeared.


    We can certainly work with new Master Pages being suffixed .php BUT there seems to be a problem.


    When I tried to create a page using a .php Master Page it always ends up with a page suffixed .php


    I cannot find a way to create a page suffixed .html from a Master Page suffixed .php


    This is unworkable for us as explained earlier.


    (1) can pages be created with suffix .html from Master Pages suffixed with .php ?


    (2) will all our content at any time in the future become unreadable because it is all suffixed .html and was all created from Master Pages suffixed .html. Currently everything is working fine and has been for the past 3 years, but the future concerns me: if suddenly all our Master Pages suffixed .html stopped working that would be a disaster for us.


    Thanks for any guidance you can provide

    Drew... we are in serious trouble. The new hosting service shows we have exactly the same problem: php files are being parsed as flat html and hence nothing in Perch is being seen by users.


    Do you know of a competent consultant/developer familiar with php files using .html suffix with the appropriate .htaccess instruction. I need help urgently and we expect to pay.


    We made no changes before our CMS material vanished - material that has been working fine for 5 years - but we have the same problem on 2 different hosts.

    Hopefully we can get a quick site transfer to a more competent hosting service. They will suck the site over to their servers and let us try things out before we commit. Usually this is via a private link as we will not have performed a Nameserver change at this time. Do I have to do anything in the Perch config file to make this all work during our testing phase?


    THANKS

    Never a truer word. I'll contact another hosting service ASAP. THANKYOU for digging around... I appreciate it. I know dealing with a non-programmer can be a pain, but I've built a huge and impressive site using Perch which we're very proud of. We couldn't have done it without you.


    Thanks for finding that link... 5 hours on Chat with their support people today and nobody mentioned that page! I tried it and it didn't work. I read somewhere there's something they have to do in the config file for their server to allow this to work. My thinking is they did something to the config file overnight which nobody in support knows about.


    But if I did go the renaming route, can I change the .html extensions in the 'pages' and 'contents' folders using renaming in my FTP program?


    We originally went the .html route as we have thousands of users with zero computer knowledge and we thought it would be simpler for them if our files kept the .html names they had in our original non-Perch site, and I think I picked up the idea from the Perch forum. It worked perfectly for 4 years... until today

    I got nowhere with HostGator.


    If we undertake the large manual task of converting all our Perch files to .php, and we convert our Master Pages and Content to .php will everything return to normal without any further work?


    Is it permissible to change the file extensions from .html to .php in the Contents and Pages folders direct on the server using my FTP program or must I create new versions inside Perch? I ask because we've had an unresolved problem for the past few years of not being able to create new Master Pages... they show up on the server but do not appear in the Master Pages listing. I think I might have created this problem by deleting a few Master Pages directly via FTP during a general server clean-up rather than by doing so through the Perch mechanism, before I realized what I was doing. We would really liked to correct that situation and get back to being able to create new Master Pages and I hoped periodic updates would accomplish this, but they didn't.

    I apologize for continuing with this. I need help.


    The page that produces the Page Source php <?php include(str_replace('/', DIRECTORY_SEPARATOR, 'editorial/templates/pages/ListsPagesTemplateObituaries.html')); ?> which you correctly say should not be shown is suffixed .html


    http://aircrewremembered.com/all-about-us.html


    I made a duplicate of this page and suffixed this with .php (the code is identical to that on the .html page <?php include(str_replace('/', DIRECTORY_SEPARATOR, 'editorial/templates/pages/AboutUsTemplate.html')); ?>


    http://aircrewremembered.com/all-about-us.php


    THIS page outputs correctly (except for the content which the AboutUsTemplate.html is not delivering, I imagine for the same reason)


    The point being HostGator's server IS correctly parsing the identical coding on the .php suffix page, Page Source shows no php commands as expected for the .php suffix page.


    Any further insights will be MUCH appreciated. If there are fees to get this resolved, we will provide, as our site is dead in the water.

    I really need your help here. Our entire Editorial System is offline. If I dupe a html file that no longer works and suffix the dupe with .php then it works except for the content (because the template generating the content is in html and I can't easily change the template to php). But no html pages produce anything at all. Everything worked yesterday and has done so for 4 years, and we made no changes. check our site http://aircrewremembered.com and select Obituaries from the menu... white screen. Show PAGE Source showes greyed out <?php include(str_replace('/', DIRECTORY_SEPARATOR, 'editorial/templates/pages/ListsPagesTemplateObituaries.html')); ?>

    The hosting service says this is a Perch issue. I think this is a rewrite issue. Can you please tell me your recommended rewrite instructions to be added to htaccess so that pages created in Perch with the html suffix (with the php headers etc) will be handled correctly by Perch

    Drew... I think the problem is that our hosting service changed our rewrite instruction on our htaccess... which says to rewrite html as php. All our Perch pages are suffixed html as are our the templates. I am onto the hosting service right now... hopefully this fixes things. If not I'm off to make several prayers