controvi

For possible future reference.
Link to bug report: https://github.com/Yoast/wordpress-seo/issues/21165

That’s fine ??
I could make it work for my case with a small change so it is no problem.

Will update when I see it come in ^_^

Ow and I just thought of something but haven’t checked so sorry if I am wrong.
But the site you used as example has a trailing slash. Could be that that is what is causing the issue.
The site I work on doesn’t have that. Could be that that causes your check for the simple_url to fail for me.

Ah ok, good point.
I did not take into account that you were thinking of file names as well.

Then maybe you could testing for file extension in the url. Some regex to see if the url ends with “(dot)[something]” and if so don’t lowercase it.
For normal WordPress pages there won’t be a file to browse to as it will always be loaded through the index.php.
And as far as I know, WordPress doesn’t do extension at the end of url’s.

But that is just a, from the top of my head, idea.
thanks for the reply ^_^

@bcworkz thank you for your reply.
Like I state, I have moved wordpress to its own subfolder.
I did the changes to the htaccess and moved the wp-content folder to the root directory.
And everything is working fine.

It is just surprising to see that the the WP_CONTENT_DIR is being checked if it is set or not and based on those URL’s something happens.
I would have thought that the WP_CONTENT_DIR and WP_CONTENT_URL would also be used when setting the UPLOADS folder name.
Especially as that uses the $site_url var instead of the WP_CONTENT_DIR that I expected it to do.

As I saw this as not being a bug but just something that was not implemented I didn’t want to make it a bug report but did wonder if I was perhaps missing something.

It is pretty weird to be able to change the name of the upload folder but than being limited to only using the wordpress core directory.
That is not something I would have expected. to be honest.

I did get everything to work by creating a media folder in the /wp-content/ folder and symlinking it to /wordpress/wp-content/media, but it isn’t my preferred route to take.

Well there is just some htnl I want to add to the post_content so it shows up.

The textual content that I laid out on my page is as follows:

summary (custom field text)
Youtube shortcode (custom field text)
post content (wordpress post_content)

What I see on the amp page is just the post_content part.

I would agree with you were it not that the mail server doesn’t even see any email arriving except that 1 that does work.
Also, nothing changed on the mailserver for quite some time.

The logs on our exchange server never show any other email going out.

I will keep trying to find out if i can find the issue on my side but i did a pretty big test round of different scenario’s.

I also checked the to and from email but didn’t see anything weird at the moment

Any progres on this?
Or any reply at all?

Is there an update on this.

Hello Alex,

Sorry for the very late reply.
I have been very busy with other parts of the project where this issue was a part of but other things got priority.

I have been up-to-date with the latest version and today I did a test.

I used 5 images of different and equal resolutions and file sizes.
Here is what I used and what happened when replacing.
Hope this helps figure out what is going on.

So I have 5 images.
1) 269kb – 2000*1497
2) 2,54MB – 4640*2610
3) 2,70MB – 4640*2610
4) 3,08MB – 4640*2610
5) 1,56MB – 1920*1200

I replaced image 1 with 2 and like expected it replaced everything.

Then when I replaced image 2 with image 1 you would expect the same result but for some reason only the images that were created with a different resolution were replaced.
And for some reason the full image wasn’t replaced either
At first.
After a min or 2 they were replaced as well.

I noted down what happened when I first tried replacing image 2 with 1.
the “V” showing which images were replaced correctly

image 1 —-> image 2
Full image —– Full image
100*100 —– 100*100
1024*674 –V– 1024*766
150*150 —– 150*150
2000*1200 —– 2000*1200
300*169 –V– 300*225
768*432 –V– 768*575

This shows that only the default resolutions of 100*100, 150*150 and 2000*1200 that stayed the same weren’t replaced, at first.
When I was writing everything down I started to go through the images again and found they were replaced.

I did the same test as above with a image 2 and 3 and found that that did replace everything.
Thought I did not expect that as they were all the same resolution.

Then I replaced image 3 with 4 and I got the same results as earlier.
only the different resolution images that were created were replaced and I had to wait a min or 2 before the others were replaced as well.

My guess here is that the issue resides in the delayed replacement.
Please correct me if I am wrong or if you have another idea why this happens.

But my guess is that when I replace an image and it for some reason doesn’t replace some of the images immediately, it gets locked somehow when you replace the image again withing that delayed time frame.

When I did test 1 again I got the same results that makes me to believe that my above idea is most likely the issue.
The only thing is why would there be a delay.

Hope you guys can help me figure out what is happening ??

Cheers guys

• This reply was modified 6 years, 10 months ago by controvi.

I have been trying to get everything to the bottom by force and it seems to have worked finally.
Hope that this keeps working.

Still curious about the question just don’t need a solution right now.
Taking to much time already.

Ok well that somewhat looks like an answer.
I can derive from your comment that indeed all the javascript code for the plugin is loaded in the header by default.

What I don’t really understand is why you would put plugin scripts in the header while it is known that more and more websites are putting the javascript all in the footer.
Besides that it is now a best practice to have you website header so much as javascript free.

For a plugin as big and popular as this I would think you guys would be jumping on this so webdevs can enjoy the advantages of up-to-date code fitting to current standards and best practices.

So again.
Is the following true?

I quote myself:
“It seems that by removing the jquery from the registered scripts the dependency is gone and wpdiscuz doesn’t load its javascripts.

I would like to know if this assesement is correct and if there is anything to do about it our if you can build in a selection to tell the plugin to look for the registered or use a custom script.”

I will go do that again on another development envirement.
Will get back to you when I finish my testing.

That explains a lot and has let us to the answer that it was probably someone here in the office when setting up the project.

We never knew that that file was keeping the post types in wordpress and we thought that once the code was run it was added to the database.

So that is the issue here.
Nothing wrong with the plugin in the end.
Glad even that it was just us.

Thank you for taking the time to help out and set us on the correct path.
Cheers

NEW UPDATE:
I found out why all the post types were still registered somewhere.
As you said in your first reply you mentioned that the post types should be registered somewhere else because cpt ui doesn’t see them anymore.
But I just found out that there apparently is a bug or something happened that made the database different from the cpt_ui.php file that (I guess) is generated by cpt ui.

When I opened that file all the register functions where there.

So it seems something happened after adding the the 10th cpt last week.

Any idea how this can happen, apart form editing the database manually ?